OpenID OAuth WRAP Extension : OpenID + OAuth WRAP

全てはあの人のtweetから始まりました。

OpenIDのOAuth Hybrid ProtocolとOAuth WRAPの相性ってどうなんだろ。ぜんぜん問題ないのか
Taizo Matsuoka  on Twitter: "OpenIDのOAuth Hybrid ProtocolとOAuth WRAPの相性ってどうなんだろ。ぜんぜん問題ないのか"

Consumer Key送るだけだし、大丈夫なんじゃ？
nov matake on Twitter: "@tzmtk Consumer Key送るだけだし、大丈夫なんじゃ？"

OpenIDのRequestに関する部分は今と変わんなくて、そのあとのOAuthの処理が簡単になると思います。
http://twitter.com/ritou/status/7270275593

仕様決めてる人じゃないのでどうなるかわかりませんが、たぶんまだ話されてないと思います。
なので、ここでどうなるか想像してみます。
リダイレクトでユーザーを行き来させてAccess Token取得するまであたりの仕様を簡単に並べてみます。

■ OAuth WRAP

(1) Client : 認可要求(AuthZ URLへのリダイレクト)にClient Identifier,Callback URLを含める
(2) AuthZ Server : 認可応答(Callback URLへのリダイレクト)にVerification Codeを含む
(3) Client : Client Identifier,Callback URL,Verification Codeを用いてAccess Tokenを取得

■ OpenID OAuth Extension

(1) Consumer : OpenIDのAuthN Request(Providerへのリダイレクト)にConsumer Keyを含める
(2) Provider : OpenIDのAuthN Response(Consumerへのリダイレクト)に認可済みのRequest Tokenを含む
(3) Consumer : Consumer Key,認可済みのRequest Token+その他いろいろを用いてAccess Tokenを取得

細かい話をするとRequest TokenとVerification Codeの違いとか・・・いろいろあると思いますが、Access Token取得までに必要なパラメータの流れという点においては、現在のHybridとOAuth WRAPは似ています。

■ OAuth WRAPとOAuth 1.0aとの違い

Request Tokenのくだりイラネ
Signatureイラネ。HTTPS使う

詳しくはここ見てください。The Introduction of OAuth WRAP vol.1 : Web App Profile on FriendFeed - r-weblife
で、結局Hybridはどうなりそうかというと、、、

■ OpenID OAuth WRAP Extension

現在の仕様の「認可済みのRequest Token」の部分を「Verification Code」にreplaceしてやりましょう。

(1) Consumer : OpenIDのAuthN Request(Providerへのリダイレクト)にClient Identifier(=Consumer Key)を含める
(2) Provider : OpenIDのAuthN Response(Consumerへのリダイレクト)にVerification Codeを含む
(3) Consumer : Client Identifier,Verification Code,Callback URL(=OpenIDのreturn_to)を用いてAccess Tokenを取得

そうすると、(3)のアクセスがOAuth WRAPのみのときとHybridのときで同じパラメータになります。
そのほうが実装するほうも楽ですよね？

■ 結局、相性は？

(・∀・)イイ！！

■ (おまけ)Hybridについていまさらながら思ったこと

細かい話なので、興味がある人はどうぞ。

現在のOpenID OAuth ExtensionはOAuth Core 1.0をベースに書かれています。
なので、