いつものごとく前段の話が長ったらしいので、斜め読みの方は「■ 本題」 からどうぞ。
■ まえがき
OpenID RP側のメリットとして「新規登録のしきいが下がる」なんてことが言われていますが、国内OPのOpenID認証ではそうでもないと思っているので、少し考えてみました。
■ OpenID Providerと利用可能な属性情報の現状
Google,myOpenIDなどはSregかAXに対応しているはずです。最近使ってないので忘れましたが。
mixiではSreg,AXでNNを取得できるけどYahoo! JAPANはSreg,AXの利用を要求しても、無視される。
ということで、認証はできるけどとても新規ユーザー登録時の属性情報補完などには使えないというのが現状なのではないかと。
個人的には、新規登録時に一番欲しいと思われる「確認済のメールアドレス」に関する意識がUSとJPでは違うのではないかと考えています。
■ OAuthを用いたUser情報提供APIの現状
Profile情報を持っているOAuthのSPは、プロフィールAPIなどをOAuth対応させていたりします。
また、今後はOpenSocialのRESTful APIが普及してくると、よりいっそうユーザーデータにアクセスできるAPIが増えてくることも考えられます。
- Yahoo! Social Directory API ( Profile - YDN )
- Digital Cable TV, Internet and Home Phone | XFINITY
- MySpace http://developer.myspace.com/community/RestfulAPIs/intro.aspx
これらのAPIを利用することで、小さなSNSの初期登録情報程度の情報は取得できるのではないでしょうか。
■ 話が長くなるのでいったん整理
今、外部のアカウントを利用して新規ユーザー登録をするためには、以下のようなやり方があると思います。
1が最もシンプルなのは明白です。Sregはこのための拡張ですよねと。
しかし、OPとしては世の中のRP全てに対してSreg,AXの範囲のユーザーデータを出せない事情もあるかと思います。
「見ず知らずのやつに簡単にうちのユーザーの登録情報は渡せん」的な考えがあったりします。
考えられるのは、「契約を結んだ相手ならばOK」的なやりかた。
Yahoo!Incは、plaxoに対してはWhite List対応でSregのデータを提供しているような気がします。
今のところ、Yahoo!(米)でSregは使えません - r-weblife
では、「新規ユーザー登録にOpenID使いたいときにはそこそこのOPに声かけて交渉してください。」でいいのでしょうか？
ここで終わってもいいのですが、個人的には納得いきません。
技術っぽくないかもしれませんが、「なんか、Openじゃないよね」と。
OP側の立場で考えるとWhite List対応ってどのように実現すべきなのでしょうか？
return_toかrealmを使った制限？
いくつかやり方はあると思いますが、OpenID Auth 2.0やSreg,AXの仕様にWhite List対応の実装方法なんて載ってません。
そもそも、White List対応って「せざるを得ないよね」程度のもので、「想定されていない」のです。
この部分を独自に実装して、RPにシェアするというのは、、、よろしくないのではないでしょうか？
では、2のOAuth Onlyの方法ではどうでしょうか？
OAuthでは、Consumer Keyによって、Consumerの管理を行っているため、White List対応とほぼイコールです。
登録時に必要なデータは揃うかもしれません。
しかし、毎回の認証にOAuthを使うのは反対です。やっぱり認証はOpenID使いましょうよと。
ではでは、3のHybridではどうでしょうか？
認証はOpenID、White ListingはConsumer Keyで実現できます。
2よりはましになるものの、各OP=SPのProfile APIの仕様が揃っていないという問題が出てくるかもしれません。
それぞれのOPに対してProfile APIの仕様を調べて実装、これまた工数が膨らみOpenIDの良さも消えてるような。
どうでしょうか、こんなに長文で提案しておいてイチオシがない最悪の状況です。
ここで終わるわけにはいきません。
■ 本題
いつも長くなってしまい申し訳ないです。
やっと本題です。
上述の方法のいいとこどりした要件を考えます。
- 取得方法 : 仕様が定められているSreg,AX(+いずれはCX)
- WhiteList方法 : 契約しばりなどによるConsumer Key発行
この要件を満たすには、既存の仕様を組み合わせるしかありません。
- RPはOPと連絡をとりあって、利用したい機能(Sreg,AX)をOPに連絡【契約】
- OPはOAuthのAPIにはアクセスできない、特別なConsumer Keyを発行。
- RPはOpenID OAuth ExtensionにのっとってOpenIDの認証要求にNamespaceとConsumer Keyを含む
- OPはNamespaceとConsumer Keyを確認。RPが有効かどうか、Sreg,AXを利用できるかどうか判定【White List対応】
- OPは許可されている範囲でSreg,AXのレスポンスを返す。ここで、Hybrid Protocolの仕様の都合上、ダミーのRequest Token発行してもいいかも
- RPはSreg,AXのデータを利用可能
【契約】の部分は、OAuthのアプリ登録のページを改修することでオンラインで対応できるかもしれません。
※ Hybrid ProtocolについてはThe Introduction of OpenID OAuth Hybrid Protocol Vol.1 - r-weblifeを参照してください。
- OPのメリット : 全体の仕様がHybrid Protocolに合わせた少しの改修だけで済む
- OPのデメリット : バックエンドで複数の拡張にまたがったロジックを作りこむ必要アリ
- RPのメリット : 全体の仕様がHybrid Protocolに合わせた少しの改修だけで済む
- RPのデメリット : 契約などのやりとりが発生するかも(しょうがない)
文章にしてみるとこの対応が難しいのかどうか見えないかと思いますが、絵の才能がないのでご了承ください。
ただ、一言いたいのは、Hybrid ProtocolへのRP=Consumer側の対応って、そんなに難しくないのです。
■ あとがき
以上、全て私の妄想ですので、実現するかどうかはわかりません。
有識者の皆様、ご意見お待ちいたしております。
