カオスなID業界でこれから増えるかもしれない仲介業社のために

久々にIDのこと考えてるので何か抜けてるかもしれません。
最初に言いたいことはこれです。

ID連携のしくみって、今更一つにまとめられるものではない
RPとOPを仲介するひとたちを想定した拡張を考えてもいいのでは？

ここから現状をダラダラと書き連ねてみます。

  • OpenIDもこれからもっと使いやすいものになるでしょう
  • OAuthもまだまだこれからですよ
  • SAMLはなくならないですよ

なぜOPというかIdP達は使う仕様をそろえないのでしょうか？
世の中には、（いい意味でも）たくさんいいしくみがあるからでしょう。

  • WebならやっぱりOpenID。Y!やGならHybridで！
  • APIとセットで出すなら、twitterのようにOAuthで！
  • 独自でも使われるFacebook
  • 昔からSAMLでやってます！

もしかしたら、古い独自ID連携は実装も大変だけど、OpenID or OAuthのどちらに移行すればいいんだろう、なんて話もあるのではないでしょうか？
こんな状況では、当然ながら

RPが個別に実装するのはしんどい

ですよね。
「要件：ユーザー認証には外部サイトの認証を使う」
って言われた時、どう考えますか？

  • OpenIDでしょ。OP Identifierぐらいなら！
  • twitterのOAuthもかなりメジャーですね
  • ユーザー数の多いfacebookも捨てがたい

うわー、こいつら全部実装しようと思ったら、ロジック何個も調べて作ってテストして。。。
ということで、

RPとOPのID関連の処理を仲介する人たちが出てきた

素晴らしいと思うのですが、

こういうProxyみたいなのがいる場合、OPはUserにほんとうのRPを示すことはできるのだろうか？

RPサイトを使いたいUserは、こんな画面を目にするかもしれません。

  • あなたは「ProxyのURLや名前」にログインします
  • 同意してログインすると、あなたは(ProxyのURL)に遷移します

これが、気持ち悪い。
あ、似たような話を聞いたことがありますね。

OpenSocialでは、ContainerがConsumerKeyを１つ持っていて、その中で細かくGadget単位でOAuthのTokenなどを分ける実装も想定されています。
OAuthの拡張として定義されているのが、OAuth Gadgets Extensionですね。
OAuth Gadgets Extension - r-weblife

これと同じことを、OpenIDの拡張で考えてみようかと。

別に難しい話ではなさそうです。
パラメータはOAuth Gadgets Extensionとほぼ変わらない感じになりそう。
あとは、OPがProxyから渡された情報をXRD（メタデータ）を使ってどうやって確認していくかを考えています。

それではまた。