斜め読みOpenID Authentication 2.0 - Draft11 (5) Communication Types
OpenID Authentication 2.0 - Draft 11 - Communication Typesがソースです。
前のエントリ
Direct Communication
Direct communicationはRelying Party*1によって初期化されたOP*2のエンドポイントURLである。そのURLはassociationsの確立*3及び、証明の主張に対する妥当性の検証*4の為に使われます。
Direct Request
メッセージはPOSTの本文としてエンコードされていなければならず、それはは4.1.2節*5で仕様化されている。(HTTP Encoding)
全てのdirectリクエストはHTTPのPOSTで、かつ4.1.2節*6で一覧化されている必須フィールドを含めなくてはならない。
Direct Response
Direct Requestに対するレスポンスの本文はキー-値のフォームエンコーディングで表現されたHTTPレスポンスの本文から成ります。そのContent-typeはtext/plainであるべきです。
全てのキー-値のフォームメッセージは下記のフィールドを含めなくてはなりません。
ns
この特別な値はリクエストが妥当なOpenID Authentication 2.0のリクエストであることを表す為にある。将来の仕様のバージョンはそのリクエストをきちんと解釈するメッセージの受信者の許可に従って異なる値を定義しても良い。
もしこの値が省略されているか、"http://openid.net/signon/1.1" または "http://openid.net/signon/1.0" が設定されていた場合、このメッセージはOpenID Authentication 1.1の互換モードと解釈すべきである。
成功時のメッセージ
妥当なリクエストを受信したサーバーはHTTPステータスコード200を返すべきである。
失敗時のメッセージ
もしリクエストが異常な形あるいは正しく無い値を含む場合、サーバーはHTTPステータスコード400を返さなければならない。そのレスポンスの本文はキー-値のフォームエンコードメッセージで下記のフィールドを伴う。
- ns
- 5.1.2節で仕様化されている(Direct Response).
- error
- 値: どうしてエラーが生じたかを示す人間にも可読なメッセージ
- contact
- 値: (オプション) そのサーバーの管理者への連絡先アドレス。その連絡先アドレスはどのような形式で提供されても良く、要は利用者に対して表示出来れば良い。*7
- reference
- 値: (オプション) 参照、サポート用のチケットナンバーだとか、お知らせ用のブロクのURLなど。
OPはこのレスポンスに追加のフィールドを付与するかもしれません。
Indirect Communication
Indirect Communicationの中でのメッセージはUser-Agentを通してやりとりされます。これはRP, OPのいずれによっても初期化されうると言う事である。Indirect communicationは証明リクエスト(Requesting Authentication)や証明レスポンス(Responding to Authentication Requests)の為に使われます。
Indirect communicationの為に二つの方法が存在します。HTTPリダイレクトとHTMLのフォーム送信です、その両者共に送信者は受信者のURLを知り、受信者のURLはindirect messegeをやり取りする事を前提としている事が求められていると言う事が4.1.2節で仕様化されています。そのやりとりの初期化は適切な可用性及びメッセージのサイズに依存した手法または、他の外部の要因に起因した手法のいずれかを選びます。*8
全てのindirectメッセージはHTTPリクエストとして届き、4.1.2節で一覧として示したフィールドを含まなければならない。
HTTP Redirect
データはエンドユーザのUser-Agentに対して302, 303あるいは307と言ったHTTPリダイレクトを発行する事によって転送される。そのリダイレクトURLはクエリストリングにOpenID Authentication messeageを付け加えた受信者のURLであり、4.1.2節で示されている。
HTML FORM Redirection
キーと値のマッピングはHTMLのform要素を含んだHTML pageにUser-Agentを戻す事によって転送する事が出来る。フォームの送信は例えばJavaScriptなどを使って自動かもしれない。
form要素のaction属性の値は受信者のURLで無ければならない。それぞれのキー-値のペアはformの中のinput要素に含まれなければならない。そのキーはname属性としてエンコードされなければならず、値はvalue属性でエンコードされていなければならない、そのようにしてUser-Agentは4.1.2節で示されたメッセージをformとして生成し、そしてそのフォ−ムを送信する。そのフォームは送信ボタンを含めなければならない。
Indirect Error Responses
不正な形式のリクエスト、あるいは妥当でない値を含む場合、OPはUser-Agentを"openid.return_to" URLの値に対してその値が示されており、かつ妥当なURLならば、リダイレクトしなければならない。
- openid.ns
- 5.1.2節で仕様化されている(Direct Response).
- openid.mode
- 値:"error"
- openid.error
- 値: どうしてエラーが生じたかを示す人間にも可読なメッセージ
- contact
- 値: (オプション) そのサーバーの管理者への連絡先アドレス。その連絡先アドレスはどのような形式で提供されても良く、要は利用者に対して表示出来れば良い。
- reference
- 値: (オプション) 参照、サポート用のチケットナンバーだとか、お知らせ用のブロクのURLなど。
サーバーはこのレスポンスに追加のキーを付与するかもしれない。
もし不正な形式あるいは妥当でないメッセージをRPから受信したら、または "openid.return_to" が無かったりあるいはその値が妥当でないURLであったら、サーバーはエンドユーザーに対してエラーを示さねばならず、また続行が不可能である事を示さねばならない。
