OpenIDの属性交換拡張の実装例、及びOpenIDサーバに認証させるにあたってのケーススタディ

で、今度は「I want my OpenID!」でログインフローを確認してみました。

IDを入力して、サブミットすると・・・今回もVidentity.orgのセキュリティチェックページ（？）にリダイレクトされ、同じように「はい、今だけ」を選択したところ、その結果I want my OpenID!のページに戻り、「ログインしたいなら、emailアドレス入力せよ」とフォームが表示されました。
しょうがないので入力すると（またしてもだまされた感がしましたがｗ）、ログインは無事成功。
（I want my OpenID!は「ログイン成功。メール送ったからチェックしろ」と言いますが、いまだにメールは届きません・・・）

ほへ？と思って、私もhttp://kokogiko.net/を使ってI want my OpenID!にログインしてみたところ、いつもどおりDelegateしているMyOpenIDの認証画面に移って認証。
ところがその後の画面がこれまでと異なって、「I want my OpenID!」が追加の個人情報としてe-mailを要求しているが、送ってもよいかといったような確認画面が。
おー！
仕様追えてなくて、この仕様がOpenID Simple Registration ExtentsionにあたるのかOpenID Attribute Exchangeにあたるのか判らないけど、要するに単なる認証仕様だけでなく周辺の付帯情報交換の拡張仕様なんかも実装として動き出したということか！
なかなか感動。

元記事の人の状況なんかは、Videntity.orgが付帯情報（e-mail）を交換する拡張仕様に対応していなかったので、「I want my OpenID!」が独自にユーザにe-mailを要求したという感じなんだろうな。
と言いつつ、俺がやった時も、MyOpenIDの方で「I want my OpenID!にe-mail送ってもいい？」と聞かれてYesにしたにもかかわらず、I want my OpenID!の方でもまたe-mailを聞かれたので、どうもまだ付帯情報交換の拡張仕様プロトコルの方はうまく取り合えていない予感。

もうひとつ面白かったのは、私はhttp://kokogiko.net/をOpenIDサービスのアカウントにDelegateさせるにあたって、古いlinkタグをhtmlに仕込む方法ではなく、Yadisドキュメントという仕様を用いて複数のOpenIDサービスのアカウントをDelegateさせているんだけど。
I want my OpenID!は、http://kokogiko.net/でログインしたけど、各OpenIDサービスでの認証画面に移った際に認証手順を途中で終了してログインを完了しなかった場合、次同じhttp://kokogiko.net/　でログインしようとすると別のOpenIDサービスを使った認証にリダイレクトして、その結果全てのDelegateサーバでhttp://kokogiko.net/でのログインが完了せずに失敗すると、こっちがCookieを消すまでhttp://kokogiko.net/でのログインを拒否してきたりした。
これは中々おもしろかった。
悪意ある第三者がブルートフォースでIDを盗むようなことがないよう、一度認証失敗したOpenIDサーバは使わない、というようなポリシーっぽい。

なるほど、OpenIDもすでにしばらく運営されてきて、いろいろ運用上のセキュリティを守るノウハウ、ケーススタディが出てきているのだなと思った。