Hatena::Diary

r-weblife このページをアンテナに追加 RSSフィード

2010/08/30

■SocialWeb Conference vol.6で発表しました！ #swj

発表で使ったスライドはこちらです。

OAuth 2.0 Dance School #swj
View more presentations from ritou.

自分の発表内容について

こんな感じで考えていました。

  • ターゲットをOAuth 2.0の中心のみに絞り、２つのProfileをまずは紹介。gdgdになることは予想済。
  • WGで議論中の多少マニアックな内容は含まない。ここはidconではないのだ。

結局こうなりました。

  • デモサイトのロースペックがgdgdな展開を演出
  • 時間なくなって尻すぼみ。でも後半はあんまりいい話用意できてなかった。

打ち合わせなしでやった割に。。。

思ったよりも、先に出しておいてほしいキーワードが出てきたのでびっくりでした。

  • Facebook Graph API
  • Twitter @Anywhere
  • ブラウザとアプリケーション立ち上げの関係

「○○さんが話されたように」が多発した件は、自分の中では"衝突"じゃなくて"良い意味の引用"なのですが、私のべしゃりが下手くそなのでうざく感じられていたらスミマセン。

反省点

  • そもそも、若干ターゲットつかみきれてなかったかも？

簡単に説明したかったけど、1.0,2.0×2個のフロー(Profile)紹介は多少きつかったかもですね。

もう少しユースケースやOpenIDとの関係とか時間かけたほうが良かったのかも。

Socialなイベントなのでたくさんのフィードバックが欲しいですね。少しでも気になったことは言ってください！

  • "Dance"の意味を説明し忘れた

OAuthのフローで、ユーザーがClient(Consumer)とAuthorization Provider(SP)の間を行ったり来たりすることがOAuth Danceと呼ばれているようです。

今回は２つのフローを紹介したかったので、Dance Schoolなんてタイトルにしたわけですが、発表のときにすっかり飛びました。

補足！

デモ用URL

Facebook Graph APIとTwitter ＠Anywhereのエントリポイントを用いて、OAuth 2.0の２つのProfileを体験してもらえたらと思い用意しました。

OAuth 2.0仕様とはパラメータなど細かい内容は異なりますが、データの流れはこんな感じだということを理解してもらえたら幸せです。

URL長問題が起こるかも？な件について

この件については、OAuth 2.0の仕様にまだ含まれていないようですが、Client IDやredirect_uriなどのリクエストの内容をまとめておいてそれを参照できるrequest_urlパラメータのみをリダイレクト時に利用するというアイディアがあり、提案されています。

日本における実装で気になる点をoauth.jpでまとめて、誰かがMLにぶんなげるのもアリかもしれませんね。

OpenIDとOAuth

OpenIDとOAuthの立ち位置などの説明は今回はしょってしまいましたが、やはりニーズはあるんですよね。

OpenID Tech Nightで話された内容のOAuth 2.0版をするイメージですが、OAuth 2.0/OpenID v.Nextの仕様が決まって整理できたタイミングとかでできたら良いですね。

OAuth + Socialで話すなら

例えばこういう話題も良いですね。

「OAuthでソーシャルグラフ（友達一覧）を出そうと思っているが、"友達の友達"や"友達の友達の友達"はどう扱うべき？」

「JSでOAuth、普及のための施策とリスクについて（外部JSインクルード or JSジェネレータコピペで自サイトで完結？、iframeと外部Cookieあたりの実装の真実など）」

ちょーっとマニアックな話になりそうなので、続編としてはありかなーと思っています。

では、またお誘いがあるように勉強しておきます。

追記：私がpptで利用している英字フォントはCentury Gothicです

Permalink | コメント(0) | トラックバック(0) | 07:26 SocialWeb Conference vol.6で発表しました！ #swj - r-weblife を含むブックマーク SocialWeb Conference vol.6で発表しました！ #swj - r-weblife のブックマークコメント

idトラックバック

2010/08/15

■OAuth 2.0周りの仕様ドキュメントについて

気になってる方々、最新のSpecはこの辺ですよ。Internet-Draft Archive Tool

http://tools.ietf.org/html/draft-ietf-oauth-v2 : The OAuth 2.0 Protocol

こいつの説明はやめときます。

http://tools.ietf.org/html/draft-recordon-oauth-v2-device : OAuth 2.0 Device Profile

OAuth Core 1.0a で定義されているフローはwebとclientの２つなわけです。

1.0aのClientのフローなんて手動のToken入力なんかが必要なので、まぁ使われないだろうなーとおもいつつ[Yahoo! JAPANではしの仕様に対応している|http://techblog.yahoo.co.jp/web/openid/oauth/わけだったりしますが、最近までOAuth 2.0のSpecの中にdevice flowってのが入ってました。

が途中でSpecから抜かれました。

もっとも一般的なWeb Server ProfileやUser-Agent Profileに比べて、もっと検討ないと使われないよなーとか思っていましたが、D. Recordonが引き続きまとめていくようです。

   +----------+                                +----------------+
   |          |>---(A)-- Client Identifier --->|                |
   |          |                                |                |
   |          |<---(B)-- Verification Code, --<|                |
   |          |              User Code,        |                |
   |          |         & Verification URI     |                |
   |  Device  |                                |                |
   |  Client  |         Client Identifier &    |                |
   |          |>---(E)-- Verification Code --->|                |
   |          |    ...                         |                |
   |          |>---(E)--->                     |                |
   |          |                                |  Authorization |
   |          |<---(F)-- Access Token --------<|     Server     |
   +----------+  (w/ Optional Refresh Token)   |                |
         v                                     |                |
         :                                     |                |
        (C) User Code & Verification URI       |                |
         :                                     |                |
         v                                     |                |
   +----------+                                |                |
   | End-user |                                |                |
   |    at    |<---(D)-- User authenticates -->|                |
   |  Browser |                                |                |
   +----------+                                +----------------+


                           Figure 1: Device Flow

流れはほぼ1.0aのままですね。

http://tools.ietf.org/html/draft-recordon-oauth-v2-ux : OAuth 2.0 User Experience Extension

Facebookの最近のしくみがOAuth 2.0を意識して作ってある（Specが変わったので準拠ではなくなってしもた）のはドキュメントを読まれた方はわかるかと思いますが、

Facebook独自のテンプレ出しわけパラメータってのがあることを知ってる方もいるでしょう。

こいつをUser Experience向上のための拡張としてまとめようとしているような動きも見られます。

OpenID UI Extensionと同様に、Language Preferenceなどと、テンプレ出しわけがセットになっています。

3. Display


   OAuth 2.0 user delegation flows are designed to work across a wide
   variety of screen sizes, device types, and contexts.  The client MAY
   request a specific form factor of dialog from the authorization
   server based on what they feel is most appropriate.  The client
   includes the following URI query parameter when constructing its
   request to the end-user authorization endpoint URI:

   display
      OPTIONAL.  The most appropriate form factor for the authorization
      dialog.  If the parameter is included in the request, the value
      MUST be set to one of the following:

      page
         A full-page authorization screen (the default).

      popup
         A compact dialog optimized for modern web browser popup
         windows.

      touch
         A mobile-optimized dialog designed for modern smartphones such
         as Android and iPhone.

      wap
         An extremely compact dialog optimized for older mobile web
         browsers.

ClientがProviderにテンプレを指定してやるって感じですね。

まぁ、popupかどうかの判定はそれで良いと思いますが、iPhone/AndroidについてはProvider側でも出しわけをデフォでやると思うので、優先度とかをどう定義するかってとこが気になりますね。

OpenIDのときに、Langの方は拡張で指定された値が最優先みたいにかいてありました。OAuthでもそうかな？あとで読んでみます。

あとは、FB仕様そのまま過ぎてパラメータにoauth_やxoauth_がつかないのかとかも微妙に気になります。別にシンプルな方がいいですが。

http://tools.ietf.org/html/draft-recordon-oauth-v2-upgrade : OAuth 2.0 Token Upgrade Extension


D. Recordonが書いてるSpec、もう一つありました。

OAuth 1.0系のTokenからOAuth 2.0のTokenへのUpgradeについての仕様みたいです。

これは、GoogleがOAuth WRAP対応を開始するっていう記事にあった「Bridge Profile」と呼ばれるものに近い気がします。

http://tools.ietf.org/html/draft-oauth-dyn-reg : OAuth Dynamic Client Registration Protocol

UMAがらみなのか。

6. Client Registration with Pushed Metadata


   This registration flow works as follows:

   1.  The client sends its metadata in JSON form to the client
       registration endpoint.  The client MUST send its name,
       description, and redirection URI and MAY send a URI for its icon.
       The client MAY sign the metadata as a JSON Token issuer, using
       the mechanisms defined in [OAuth-Sig].

   2.  The authorization server checks the data, verifying the signature
       as necessary, and returns a client identifier and an optional
       client secret.



     +--------+                                  +---------------+
     | Client |--(A)--- Registration Request --->| Authorization |
     |        |         with Metadata            |     Server    |
     |        |                                  |               |
     |        |<-(B)----Registration Response ---|               |
     |        |         with Client ID Info      |               |
     +--------+                                  +---------------+


          Figure 1: Client Registration Flow with Pushed Metadata

詳細まで読んでませんが、レスポンスにOptionalでexpires_inとかも使えるってことは、一時的なClientIDなんてのも作れそうですね。

さらに拡張して、前に聞いたClientIDから子供のClientIDをつくるみたいなこともできそう。。。

ちなみに、OAuthでもXRDを用いたDiscoveryはもっと使っていくべきだと思う。

http://tools.ietf.org/html/draft-campbell-oauth-saml : SAML 2.0 Bearer Assertion Profile for OAuth 2.0

Autonomous Profileに含まれるSAML-OAuth連携あたりのところをkwskまとめようとしてるもの？がこちらかも。

http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth : A SASL Mechanism for OAuth

初めてみたのが、SASL。「さする」って読んで良いのかしら。

                                                              ----+
   +--------+                                  +---------------+  |
   |        |--(C)-- Authorization Request --->|   Resource    |  |
   |        |                                  |     Owner     |  |Plain
   |        |<-(D)------ Access Grant ---------|               |  |OAuth
   |        |                                  +---------------+  |2.0
   |        |                                                     |(1)
   |        |         Client Credentials &     +---------------+  |
   |        |--(E)------ Access Grant -------->| Authorization |  |
   | Client |                                  |     Server    |  |
   |        |<-(F)------ Access Token ---------|               |  |
   |        |      (w/ Optional Refresh Token) +---------------+  |
   |        |                                                 ----+
   |        |
   |        |                                                 ----+
   |        |        (Optional discovery)      +---------------+  |
   |        |--(A)------- User Name  --------->|               |  |
   | Client |                                  |               |  |
   |        |<-(B)------ Authentication -------|               |  |
   |        |          endpoint information    |    Resource   |  |OAuth

   |        |                                  |     Server    |  |over
   |        |--(G)------ Access Token -------->|               |  |SASL
   |        |                                  |               |  |
   |        |<-(H)---- Protected Resource -----|               |  |(2)
   +--------+                                  +---------------+  |
                                                              ----+

                    Figure 1: Interworking Architecture

いろいろありますねぇ。

http://tools.ietf.org/html/draft-sakimura-oauth-requrl : Request by Reference ver.1.0 for OAuth 2.0

これも忘れてはいけない。

せっかくいろんな拡張かんがえてるんだし、こういうの使ってURL長に影響ないようにしとくべきだと思う。

とりあえずOAuth 2.0の最新Draft新しいめのやつらを紹介しました。

もっと最新の状況が気になる方はこちら！

oauth Discussion Archive - Date Index

ではまたー。

Permalink | コメント(0) | トラックバック(0) | 01:04 OAuth 2.0周りの仕様ドキュメントについて - r-weblife を含むブックマーク OAuth 2.0周りの仕様ドキュメントについて - r-weblife のブックマークコメント

idトラックバック

2010/06/28

■OpenID Usecase : Social Bookmark Service

Twitter のつぶやきからブックマークできる、Twitter との連携機能をリリースしました - はてなブックマーク日記 - 機能変更、お知らせなど

はてブからtwitterにPOSTとか、それ以前から相性が良いのでActivityに垂れ流されぎみのSocial Bookmark Service(以下、SBM≠ソフトバンクモバイル)ですが、

ずっと前から思っていたことがあります。

今回言いたいこと

「SBMはOpenIDのRPになってみても良いかも」

それでは、ダラダラと今日もはじめましょう。

前置き

どっかのブログの記事見ていて、ふと思いました。

  • 大量のブクマリンクが張ってあるブログはうざい

良い過ぎたかも。やっぱり、うざくない。気持ち悪い。いや、そうでもない、ちょっと気になるってことにします。

これってID以前からNASCAR Problemやってるように見えます。

最近は増えたら選ぶのめんどくさいですし、いつも使ってるのがないと不便です。最後にはFireFoxのアドオンとか使うわけですが。

この辺のUXをOpenID使ってなんとかできないものかと。

twitterでつぶやくボタンからOAuthへという流れ

で、思い出すのがtwitterの例。

  • "twitterでつぶやく"的な画像やリンクは最初はみんな、投稿画面へのリンクばっかりでしたよね
  • 最近はtwitterのOAuth使って同時POSTしちゃうとこ増えてきてますね
  • でもあーゆーのは設定めんどくさいですよね
  • まぁ、だから両方残ってるんですかね

SBMについても同じことが言えるのかなーと。

OpenIDでいうと、Social BookmarkってOPなの？RPなの？

現状は「OP」だと思っている人が多いのではないでしょうか？

それはそうですよね。

ブクマの管理はユーザ単位ですし、Socialと言ってる以上、他のユーザーとのつながりを用いたサービスだったりするのですからID体系持ってます。

というか、OAuthのSPって感じですね。

  • ほら、やっぱりSBM側がOAuthのSP実装してるならブログ/記事側がConsumerになればいい
  • いや、SBM側がOAuthのSP実装してるとはかぎらない
  • むしろ、SBM側がRPやConsumerかもしれない
  • はてなやY!やGとかはブログ側がOpenIDのOPだったりするから、SBMはRPの方がいいかも？

と誘導したところで、今回はSBMがOpenIDのRPのパターンを考えてみます。

ここから一気に行きます。

(忘れてきたところなので、SBM＝Social Bookmark≠ソフトバンクモバイル)

実装提案

  • SBMはOpenIDのRP実装を行う
  • OPやってるY!やGやはてななどは記事を見ているユーザーがログイン状態ならばそのユーザーのOpenIDをUnsolicited Positive AssertionでSBMに送り込む(OP Initiated)
  • 送り込んだ履歴を保存しておいて、次回からは強調してみたりする(RPXがやってるように)
  • 未ログインユーザーにはなんもしない

メリット

  • 今よりちょっと便利かも。利便性低下まではいかないかも
  • OPは自分たちのユーザーに紐づいたActivityが生まれる可能性があるので、まんざらでもない
  • 大御所のブログに採用されれば、新規参入SBMでもアイディア次第ではなんとかなるかもしれない

デメリット

  • 裏返し。複数ID利用者は本来使いたくないIDで自動ログインされて、あたふたするかも
  • そりゃあ、追加実装はめんどい罠

最後に

今まで何度もOP Initiatedの話してますが、なんでかというと

OPのトラフィックってまだまだ使い道があると思ってるからです。

OP→RP→OPと効率的にユーザーが巡回するようになれば、両方幸せになれるのですが、流行ってるのってtwitter/facebookぐらいじゃないですか？

ポータルサイトってのはたくさんのサービス持ってるんだからそれを細かくトラヒックの発信元にするべきです。

ではまた、他のユースケース考えてみます。

Permalink | コメント(0) | トラックバック(0) | 01:07 OpenID Usecase : Social Bookmark Service - r-weblife を含むブックマーク OpenID Usecase : Social Bookmark Service - r-weblife のブックマークコメント

idトラックバック

2010/06/22

■OpenID OAuth Extension(hybrid)についての情報は少ない？

idcon#7参加者の方からリクエストをいただいていましたが、けっこういろんなところで話されているのではないかと思い、調べなおしてみました。

=daisuke(OAuthハイブリッド、CX関連のお話を聞かせていただければ。よろしくお願いします。)

仕様

これがGoogle,Yahoo!Inc,MySpaceなどで採用しているHybridの仕様です。

http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html

2009年1月なので、けっこう前の話です。

そういえば、OAuth Core 1.0のセキュリティのお話があったときも、「Hybridは問題ない」のでそのままですし、1.0aになってhybridとの仕様が離れた感じからくる違和感は今でも覚えています。

世の中に出回っているスライド

OpenIDのExtensionを紹介したときのスライド @ idcon#6

091009 Identity Conference #6 ritou

またけさんのスライド + ustream @ OpenID Tech Night Vol.6

OpenID TechNight #6 - OpenID OAuth Hybrid

OpenID Tech Night Vol.6 #9, OpenID Tech Night Vol.6 #9 oidfj on USTREAM. Conference

PlaxoがGoogleのHybrid使い始めたときの説明スライド

What an "RP" Wants

Y!Incのひとのスライド

http://www.slideshare.net/erikeldridge/hybrid-auth-openid-oauth

関連blog

最初の仕様のときの訳ですが、lyokatoさんのエントリ

OpenIDとOAuthを同時に扱う拡張仕様 OpenID OAuth Extension - Codin’ In The Free World

自分でもユースケースについてたくさん書いてました。。。長すぎて読みたくないですね。

The Introduction of OpenID OAuth Hybrid Protocol Vol.1 - r-weblife

The Introduction of OpenID OAuth Hybrid Protocol Vol.2 - r-weblife

結論「資料をざっと見てもらって、質問はidconで！」

少し、フリーディスカッション or LTの時間を設けるかもしれません。

そのあたりでテーマをあげてもらって詳しい人が答えるようなことができれば良いのではないかと思ったりしています。

Permalink | コメント(0) | トラックバック(0) | 01:40 OpenID OAuth Extension(hybrid)についての情報は少ない？ - r-weblife を含むブックマーク OpenID OAuth Extension(hybrid)についての情報は少ない？ - r-weblife のブックマークコメント

idトラックバック

2010/06/09

■OpenIDでPPIDの実装方法を確認した。

前回、コメントで教えていただいたいただいたICAMのドキュメントをみたら、さくっと書いてありました。

http://www.idmanagement.gov/documents/ICAM_OpenID20Profile.pdf

Final: OpenID Provider Authentication Policy Extension 1.0

OpenID Auth Request

RPはPAPE拡張を使ってこんな感じのパラメータをRequestに含んでOPに送ります。

openid.ns.pape : http://specs.openid.net/extensions/pape/1.0

openid.pape.preferred_auth_policies : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier

OpenID Auth Response(Assertion)

OPからRPに返されるレスポンスはこんな感じなのがついて、realm単位で分けれらたclaimed_idとidentityが返される。

openid.ns.pape : http://specs.openid.net/extensions/pape/1.0

openid.pape.auth_policies : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier

PPIDについて気になる点

なんだかんだいって、パートナー企業とはRPのドメイン、URLが変わったときのPPIDの移行処理を考慮する必要ありかも

WASForumの時に、@_nat さんが「OPがいなくなったときのユーザーデータ移行」の話を少しされていたと思いますが、PPIDについてはRP側の話をしましょう。

例えばiknowからsmart.fmに変わったようにRPのURL変更が起こったときに、ドメインまで変わったらさすがにrealmも変わっちゃうんでしょと。

PPIDのポリシーからいくとしょうがないので、もう一度０からOpenIDとのひも付けを行っていくか事前にユニークなメアドなどでユーザーを移行する必要性がでてきます。

もし、パートナー限定なOPをしていてPPIDを使っていたら、、、

そのあたりも考えてPPIDを実装するなら、いざというときのユーザー移行の手段も考慮してなければいけないかもしれません。

ユーザーへの見せ方

「PPIDの場合、同意画面などでユーザーにIDさらすべきですか？」

せっかくPPIDにして文字列自体の関連性を隠しているので、表示しないほうがいい気がします。

Googleはユーザーに見せていませんね。

どこまで隠す？

上の見せ方とも絡みますが、ユーザーに名寄せしたいRPが「（別のRP）さんのサイトに行ったときの同意画面に表示されるURLを教えてください」なんてことを言えば紐づけ可能になるかもしれません。気にしすぎかもしれませんが、これはユーザーがやることだからしょうがないのでしょうか？

って考えていくと、GETであれPOSTであれ、今のOpenIDではAssertionがIndirectCommなので、そこも隠した方がいい気がしてきました。

ではどうしましょうか？

「ArtifactBindingならDirectCommだし、SSLでも納得されないならAssertionをEncryptしてやりとりすればわりと隠せそうですよ。」

ということで、PPIDってよっぽど頑張らないとPPにならないんじゃないかとちょっと思った今日この頃です。

Permalink | コメント(2) | トラックバック(0) | 02:59 OpenIDでPPIDの実装方法を確認した。 - r-weblife を含むブックマーク OpenIDでPPIDの実装方法を確認した。 - r-weblife のブックマークコメント

idトラックバック
プロフィール

ritou

ritou

社会人5年生になりました。

最新タイトル
最近言及したキーワード
ページビュー
69597
日記の検索