http://www.danga.com/openid/specs.bml のメモ 5/21 ・ユーザが相手サーバにログインする際に、IDとして(自分のブログやFOAFの)URLを使う。 ・ユーザがURLを入力すると、相手サーバはそのユーザのIDサーバを見つける。    上記書式のhrefがエンドポイントとなる。  redirectによってページを遷移したならば、ユーザが入力したurlと最終的なID URLが異なることになる。 ・相手サーバはブラウザにIDサーバのURLを返し、ブラウザは以下のデータ伴ってIDサーバにアクセスする。   openid.return_to この後IDサーバがリダイレクトするURL   openid.trust_root 承認してもらうべきURLでreturn_toはこのURLの下位に属する             指定しない場合はreturn_toと一緒   openid.is_identity IDサーバに認証してもらうURL(最初に入力したIDとは限らない)   openid.post_grant オプション。IDサーバがtrust_rootの承認をした後のページの             振る舞い。windowを閉じる'close'か、return_toに戻る'return'             指定しない場合、振る舞いは未定義。  IDサーバに確認してもらうことは、 「そのユーザはis_identityで表されるURLにログインしているか? trust_root(すなわちreturn_to)はそのことを知ってもよいか?」 ・IDサーバはmodeおよび条件によって以下のデータを伴いreturn_toにリダイレクトする   openid.mode=id_res  1. あるユーザがログインしている  2. openid.is_identityで尋ねられているURLは、そのユーザの支配下にある  3. そのユーザはIDサーバにtrust_rootのURLを信頼するよう伝えている  ◎3条件がそろった場合   openid.assert_identity openid.is_identityの値   openid.sig DSAシグニチャ   openid.timestamp タイムゾーン with Z  ◎条件が伴わない場合は認証失敗   openid.user_setup_url 認証を成功するために必要な手続きのURL ・ユーザがコメントを書いてsubmitしたとき、相手サーバは   openid.mode=getpubkey  でIDサーバからDSA公開鍵を取得し(キャッシュできる)シグネチャをチェック。  ファイナルフュージョン承認。 http://www.danga.com/openid/specs.bml の記述ではブラウザと各サーバのやりとりはjavascript、IFRAMEを使っている。 mode=id_resの後、親windowとiframeのドメインが一致するかチェックしている。