斜め読みOpenID Authentication 1.1 Modes
訂正！
checkid_immediate, assosiateの説明が逆になってました！（＞＜）
はじめに
d:id:ZIGOROu:20070322:1174552378の続き
もっと理解が進めば多分自分の言葉で語れるとは思うんですけども。。。うー。
通信の詳細についてはちと長いので割愛。
associateモード
- 説明
- 共通鍵(shared secret)をコンシューマーとIdPの間で確立させる
- HTTP method
- POST
- Flow
- Consumer -> IdP -> Consumer
checkid_immediateモード
- 説明
- エンドユーザーがClaimed Identifierを所有している場合、「はい」または「回答出来ない」という答えを即時に戻す為のIdPへの問い合わせ
- HTTP method
- GET
- Flow
- Consumer -> User-Agent -> IdP -> User-Agent -> Consumer
checkid_setupモード
- 説明
- エンドユーザーがClaimed Identifierを所有している場合にIdPに問い合わせる。しかし応答の為に待たなければならない。コンシューマーはUser-Agentを「はい」か「いいえ」のいずれかを戻す短い期間の為にIdPに誘導する。
- HTTP method
- GET
- Flow
- Consumer -> User-Agent -> [IdP -> User-Agent ->] + Consumer
check_authenticationモード
- 説明
- メッセージが妥当な場合、IdPへ問い合わせる。dumbモード、statelessなコンシューマーまたはinvalidate_handleリクエストの時の為に使います。
- 注意
- statelessなassociation handleでのsignatureの確認にのみ使用して下さい。IdPは決してsignatureの確認を誰もが所有している共通鍵のassociate handleの為に行うべきではありません。それらはstateless対協調 されたassociate handle、そして唯一要求するstateless handleにおけるcheck_authenticationに違いがあるべきです。*1
- HTTP method
- POST
- Flow
- Consumer -> IdP -> Consumer
まとめ
checkid_immediateに関してはとても良く理解出来る。恐らくだがConsumerとIdPの初回のやり取りに発生する手続きなのだろう。
associateとcheckid_setupの違いが良く分からない。。。
- associate
- 共通鍵を交換する際のモード
- checkid_immediage,checkid_setup
- claimed identifierを所有しているかどうかをIdPに問い合わせる
って事ですね。
checkid_immediate, checkid_setupの大きな違いはIdP側でエンドユーザーの確認をした後に直ちにその結果をConsumerに返すか、あるいはエンドユーザーに結果の通知をしても良いかどうか確認を求めるかの違いになる。
check_authenticationにおけるメッセージって何だ？
非常にもどかしい。。
*1:もう日本語すらおかしいw
