OpenID Authentication 2.0 - 最終版

Abstract

OpenID 認証は、エンドユーザが識別子 (Identifier) を管理していることを証明する方法を提供するものである。OpenID 認証を利用すれば、リライングパーティー (Relying Party、以下 RP) はエンドユーザのパスワードやメールアドレスなどにアクセスする必要がなくなる。

OpenID は、分散方式であり、RP や OpenID プロバイダ (OpenID Provider 、以下 OP) の承認・登録を行なう中央集権的な機関は存在しない。エンドユーザは利用する OP を自由に選択することができ、OP を変更しても自身の識別子をそのまま継続して利用することができる。

プロトコル自体は JavaScript や最新ブラウザを必要としないが、AJAX を利用しても認証 (authentication) の仕組みは上手く機能する。つまり、エンドユーザは、現在のウェブページから離れずに、RP に自らの身元を証明できるのである。

OpenID 認証は、HTTP(S) の標準的な要求／応答だけを用いているため、ユーザエージェント (User-Agent) やクライアントソフトウェアが特別な機能を備えている必要はない。OpenID は、cookie をはじめ、RP や OP 特有のセッション管理方法には全く依存していない。ユーザエージェントの機能拡張により、エンドユーザの操作を簡素化できるが、プロトコル利用上は必ずしも必要ではない。

プロファイル情報の交換や、本仕様に記されていないその他の情報の交換については、本プロトコル上にサービスタイプを追加し、仕組みを構築することで実現可能である。OpenID 認証は、ポータブル (環境に依存せずに使用可能) でユーザセントリックなデジタルアイデンティティを、自由かつ分散的な方式で実現するための基盤サービスを提供するために設計された。

Table of Contents

1.  要求記法および規則
2.  用語
3.  プロトコルの概要
4.  データフォーマット
    4.1.  プロトコルメッセージ
    4.2.  整数表現
5.  通信形式
    5.1.  直接通信 (Direct Communication)
    5.2.  間接通信 (Indirect Communication)
6.  署名の生成
    6.1.  署名の生成手順
    6.2.  署名アルゴリズム
7.  開始とディスカバリ
    7.1.  開始
    7.2.  正規化
    7.3.  ディスカバリ
8.  アソシエーションの確立
    8.1.  アソシエーションセッション要求
    8.2.  アソシエーションセッション応答
    8.3.  アソシエーション形式
    8.4.  アソシエーションセッション形式
9.  認証要求
    9.1.  要求パラメータ
    9.2.  レルム
    9.3.  即時要求
10.  認証要求に対する応答
    10.1.  肯定アサーション
    10.2.  否定アサーション
11.  アサーションの検証
    11.1.  戻り URL の検証
    11.2.  ディスカバリによって得られた情報の検証
    11.3.  ノンスのチェック
    11.4.  署名の検証
    11.5.  エンドユーザの識別
12.  拡張仕様
13.  OpenID リライングパーティーのディスカバリ
14.  OpenID Authentication 1.1 との互換性
    14.1.  OpenID Authentication 1.1 からの変更点
    14.2.  OpenID Authentication 1.1 互換性の実装
15.  セキュリティに関する考慮事項
    15.1.  アタック（攻撃）からの防御
    15.2.  ユーザエージェント
    15.3.  ユーザインタフェースに関する考慮事項
    15.4.  HTTP および HTTPS URL 識別子
    15.5.  サービス妨害攻撃 （DoS 攻撃）
    15.6.  プロトコルの可変項目
Appendix A.  使用例
Appendix A.1.  正規化
Appendix A.2.  OP ローカル識別子
Appendix A.3.  XRDS
Appendix A.4.  HTML 識別子のマークアップ
Appendix A.5.  XRI 正準化 ID
Appendix B.  Diffie-Hellman 鍵交換のデフォルト値
Appendix C.  謝辞
16.  参考文献
§  Author's Address

1.  要求記法および規則

本文書で用いられる各キーワード「MUST (しなければならない)」、「MUST NOT (してはならない)」、「REQUIRED (必須である)」、「SHALL (するものとする)」、「SHALL NOT (しないものとする)」、「SHOULD (すべきである)」、「SHOULD NOT (すべきではない)」、「RECOMMENDED (推奨される)」、「MAY (してもよい)」、「OPTIONAL (任意である)」は [RFC2119] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .) で述べられている通りに解釈されるべきものである。

本文書では、書いてあるままに解釈されるべき値は引用符 ("") で囲んで示している。プロトコルメッセージの中でこれらの値を使用する場合は、値の一部として引用符を用いてはならない (MUST NOT)。

2.  用語

識別子 (Identifier):

識別子は、"http" または "https" URI (本文書では、通例に従い "URL" と表記)、もしくは XRI (Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” .) [XRI_Syntax_2.0] のいずれかである。本文書では、様々な種類の識別子を定義するが、それぞれ異なるコンテキストでの使用を目的としている。

ユーザエージェント (User-Agent):

HTTP/1.1 [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” .) を実装したエンドユーザのウェブブラウザ。

リライングパーティー (Relying Party):

略語は RP。エンドユーザが識別子を管理しているという証明を要求するウェブアプリケーション。

OpenID プロバイダ (OpenID Provider):

略語は OP。エンドユーザが識別子を管理しているというアサーション (assertion) を得るために RP が依存する OpenID 認証サーバ。

OP エンドポイントURL (OP Endpoint URL):

OpenID 認証プロトコルメッセージを受け入れる URL で、ユーザ入力識別子 (User-Supplied Identifier) のディスカバリ (discovery) を実行することにより得られる。この値は、HTTP または HTTPS の絶対 URL でなければならない (MUST)。

OP 識別子 (OP Identifier):

OP の識別子。

ユーザ入力識別子 (User-Supplied Identifier):

エンドユーザが RP に提示する識別子、または OP においてユーザが選択した識別子。プロトコルの開始 (initiation) フェーズでは、エンドユーザは、自らの識別子、OP 識別子のどちらを入力してもよい。OP 識別子を用いる場合、OP は、エンドユーザが RP に提示する識別子の選択を支援してもよい。

主張識別子 (Claimed Identifier):

エンドユーザが自らのものであると主張する識別子。プロトコル全体の狙いは、この主張を検証することにある。主張識別子は、以下のいずれかである。

• URL の場合、ユーザ入力識別子を正規化 (正規化)することで得られる識別子。
• XRI の場合、正準化 ID (CanonicalID) (XRI および正準化 ID エレメント)。

OP ローカル識別子 (OP-Local Identifier):

特定の OP でエンドユーザを識別するためにローカルに用いられる代替の識別子。必ずしもエンドユーザが管理しているものではない。

3.  プロトコルの概要

1. エンドユーザは、ユーザエージェントを通じて RP にユーザ入力識別子を提示することによって、認証を開始 (開始)する。
2. ユーザ入力識別子を正規化 (正規化)した後、RP はそのディスカバリを実行 (ディスカバリ)し、エンドユーザが認証に用いる OP エンドポイント URL を確定する。ユーザ入力識別子は、OP 識別子である可能性があることに留意する必要があるが、この点については Section 7.3.1 (ディスカバリによって得られる情報) で述べる。OP 識別子のときは、OP で主張識別子を選択することができる。また、拡張仕様 (拡張仕様)を利用して実用的な代替手段が取られている場合は、主張識別子を用いずにプロトコルを続行することもできる。
3. (オプション) RP と OP の間のアソシエーション (association) (アソシエーションの確立) の確立は、Diffie-Hellman 鍵交換 (Rescorla, E., “Diffie-Hellman Key Agreement Method,” .) [RFC2631]を用いた共有秘密鍵の発行をもって行う。OP はその後のメッセージに署名するためにアソシエーションを用い、RP はこれらのメッセージを検証するためにアソシエーションを用いる。その結果、それぞれの認証要求／応答に続く署名検証のための直接要求を行なう必要がなくなる。
4. RP は、エンドユーザのユーザエージェントを、OpenID 認証要求 (認証要求)とともに OP にリダイレクトする。
5. OP は、エンドユーザが OpenID 認証の実行を許可されているかどうか、さらにエンドユーザが認証の実行を求めているかどうかを確定する。OP におけるエンドユーザの認証方法およびそのような認証に関わるポリシーは全て、本文書の対象範囲外である。
6. OP は、エンドユーザのユーザエージェントを、認証が承認された (肯定アサーション)ことを示すアサーション、認証が失敗した (否定アサーション)ことを示すメッセージのどちらかとともに RP へリダイレクトする。
7. RP は、OP から受け取った情報を検証 (アサーションの検証)し、戻り URL (Return URL) のチェック、ディスカバリによって得られた情報の検証、ノンス (nonce) のチェックなどを行なう。また、アソシエーション確立時に発行した共有鍵、あるいは OP への直接要求のいずれかを用いて、署名を検証する。

4.  データフォーマット

4.1.  プロトコルメッセージ

OpenID 認証プロトコルメッセージは、プレーンテキストのキーとプレーンテキストの値とをマッピングしたものである。キーおよび値には、Unicode 文字セット (UCS) を全て使用することができる。キーおよび値とバイト形式との間の変換が必要な場合は、UTF-8 (Yergeau, F., “UTF-8, a transformation format of Unicode and ISO 10646,” .) [RFC3629] を用いてエンコードしなければならない (MUST)。

メッセージは、同じ名前のパラメータを複数含んではならない (MUST NOT)。

本文書に記されている OpenID メッセージのパラメータは、全て必須である (REQUIRED)。ただし、任意である (OPTIONAL) と明示されている場合は、その限りではない。

4.1.1.  キー・バリュー形式エンコーディング

キー・バリュー形式のメッセージは、一連の行からなる。各行の最初はキーで、その後ろにコロンを付加し、キーと関連する値が続く。各行は、一個の改行文字 (UCS 文字コード番号 10, "\n") で終わる。キーまたは値は、改行文字を含んではならない (MUST NOT)。また、キーは、コロンを含んではならない (MUST NOT)。

空白を含む追加文字は、コロンまたは改行文字の前後に追加してはならない (MUST NOT)。メッセージからバイト文字列を生成するときは、UTF-8 でエンコードしなければならない (MUST)。

キー・バリュー形式エンコーディングは、署名計算および RP への直接応答 (直接応答 (Direct Response))に利用される。

4.1.2.  HTTP エンコーディング

HTTP サーバにメッセージを送るときは、[HTML401] (W3C, “HTML 4.01 Specification,” .) の Section 17.13.4 に定められるフォームエンコーディングを用いてエンコードしなければならない (MUST)。同様に、要求のヘッダに "Content-Type" ヘッダが含まれている場合は、その値も [HTML401] (W3C, “HTML 4.01 Specification,” .) の Section 17.13.4 に定められたエンコーディングでなければならない (MUST)。

要求メッセージの全てのキーは、その前に "openid." プレフィックスを付加しなければならない (MUST)。このプレフィックスを付加することにより、OpenID 認証メッセージとともに受け渡される他のパラメータとの干渉を回避できる。メッセージを POST で送るとき、OpenID パラメータは常に POST ボディに格納して送り、POST ボディから抽出しなければならない (MUST)。

HTTP 要求 (GET または POST) として送られるメッセージは全て、以下のフィールドを含んでいなければならない (MUST)。

• openid.ns

  値: "http://specs.openid.net/auth/2.0"

  要求が OpenID Authentication 2.0 として有効な要求であるためには、上記の値が存在していなければならない (MUST)。仕様の将来版においては、メッセージ受信者が要求を適切に解釈できるように、異なる値が定義される場合もある。

  この値が存在しない、あるいは "http://openid.net/signon/1.1" 、"http://openid.net/signon/1.0" のどちらかの値が設定されている場合、そのメッセージの解釈には、OpenID Authentication 1.1 互換モード (OpenID Authentication 1.1 との互換性)を用いるべきである (SHOULD)。

• openid.mode

  値: メッセージタイプごとに個別に指定。

  "openid.mode" パラメータを用いることによって、メッセージ受信者は、処理中のメッセージの種類を知ることができる。"openid.mode" がない場合、メッセージ処理側は、その要求が OpenID メッセージではないと見なすべきである (SHOULD)。

このモデルは、ユーザエージェントから RP に送られるメッセージ、ユーザエージェントから OP に送られるメッセージ、そして RP から OP に送られるメッセージにも適用される。

4.1.3.  用例

参考

下記は、次の情報のエンコード例である。

キー    | 値
--------+---------------------------
mode    | error
error   | This is an example message

エンコードされたキー・バリュー形式：

mode:error
error:This is an example message

HTTP POST ボディまたは URL のクエリ文字列に含まれるときなど x-www-urlencoded の場合 ([RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) Section 3) ：

openid.mode=error&openid.error=This%20is%20an%20example%20message

4.2.  整数表現

任意精度整数は、ビッグエンディアン符号付き 2 の補数表現バイナリ文字列にエンコードしなければならない (MUST)。以後 "btwoc" は、任意精度整数を引数とし、最も短いビッグエンディアン 2 の補数表現を返す関数とする。Diffie-Hellman 鍵交換で用いる整数は全て、正の数とする。つまり、2 の補数表現の最上位ビットはゼロでなければならない (MUST)。そうでない場合、文字列の先頭にゼロバイトを付加する実装をしなければならない (MUST)。

参考例:

10 進数表現      | btwoc文字列表現
---------------+----------------------------
0              | "\x00"
127            | "\x7F"
128            | "\x00\x80"
255            | "\x00\xFF"
32768          | "\x00\x80\x00"

5.  通信形式

5.1.  直接通信 (Direct Communication)

直接通信は、OP エンドポイント URL に対し、RP 側から開始され、アソシエーションの確立 (アソシエーションの確立)および認証アサーションの検証 (OpenID プロバイダを通じた直接検証)のために用いられる。

5.1.1.  直接要求 (Direct Request)

メッセージは、Section 4.1.2 (HTTP エンコーディング) で指定した通り、POST ボディとしてエンコードしなければならない (MUST)。

直接要求は全て HTTP POST であり、そのため、Section 4.1.2 (HTTP エンコーディング) で示した必須フィールドを含む。

5.1.2.  直接応答 (Direct Response)

直接要求 (直接要求 (Direct Request))への応答のボディは、キー・バリュー形式 (キー・バリュー形式エンコーディング)の中の HTTP 応答ボディで構成される。応答の content-type は、"text/plain" とすべきである (SHOULD)。

キー・バリュー形式のメッセージは全て、以下のフィールドを含まなければならない (MUST)。

• ns

  値: "http://specs.openid.net/auth/2.0"

  応答が OpenID 2.0 として有効な応答であるためには、上記の値が存在していなければならない (MUST)。仕様の将来版においては、メッセージ受信者が応答を適切に解釈できるように、異なる値が定義される場合もある。

  この値が存在しない、あるいは "http://openid.net/signon/1.1"、"http://openid.net/signon/1.0" のどちらかの値が設定されている場合、そのメッセージの解釈には、OpenID Authentication 1.1 互換モード (OpenID Authentication 1.1 との互換性)を用いるべきである (SHOULD)。

5.1.2.1.  成功時の応答 (Successful Responses)

サーバが有効な要求を受け取ったときは、HTTP ステータスコード 200 の応答を送らなければならない (MUST)。

5.1.2.2.  エラー時の応答 (Error Responses)

不正な要求があった場合や無効な引数が含まれていた場合、サーバは、HTTP ステータスコード 400 を含む応答を送らなければならない (MUST)。応答のボディは、以下のフィールドを含むキー・バリュー形式 (キー・バリュー形式エンコーディング)メッセージでなければならない (MUST):

• ns

  Section 5.1.2 (直接応答 (Direct Response)) で指定した通り。

• error

  値: 人間が解読可能なメッセージ。エラーの原因を示す。

• contact

  値: (オプション) サーバ管理者の連絡先。連絡先は、人間に対して表示するためのものなので、どのような形で記述してもよい。

• reference

  値: (オプション) サポートチケット番号やニュースブログへの URL などの参照トークン。

OP は、この応答に追加フィールドを追加してもよい (MAY)。

5.2.  間接通信 (Indirect Communication)

間接通信では、ユーザエージェントを経由してメッセージの受け渡しを行う。間接通信は、RP、OP のいずれからでも開始することができる。間接通信は、認証要求 (認証要求)および認証応答 (認証要求に対する応答)のために用いられる。

間接通信には、HTTP リダイレクトと HTML フォーム送信の二つの方法がある。フォーム送信もリダイレクトも、送信側が受信側の URL を知っていること、そして受信側の URL が Section 4.1.2 (HTTP エンコーディング) で指定されているような、間接メッセージの受信を想定していることが求められる。通信を開始する側が、機能、メッセージサイズ、その他の外部要因に応じて適切な間接通信の方法を選択する。

全ての間接メッセージは HTTP 要求として受信され、そのため、Section 4.1.2 (HTTP エンコーディング) で示した必須フィールドを含む。

5.2.1.  HTTP リダイレクト

データは、302、303 または 307 HTTP リダイレクトを発行することによって、エンドユーザのユーザエージェントに転送できる。リダイレクト URL は受信側の URL で、Section 4.1.2 (HTTP エンコーディング) で指定されている通り、クエリ文字列に OpenID 認証メッセージが付加されている。

5.2.2.  HTML フォームリダイレクト

キーと値とのマッピングを転送するには、HTML フォームエレメントを含む HTML ページをユーザエージェントに戻す。フォーム送信は、JavaScript を用いるなどして自動化してもよい (MAY)。

<form> エレメントの "action" 属性値は、受信側の URL でなければならない (MUST)。それぞれのキー・バリューのペアは、<input> エレメントとしてフォームに含まれていなければならない (MUST)。フォーム送信を行なうとき、Section 4.1.2 (HTTP エンコーディング) で指定されている通りにユーザエージェントがメッセージを生成するように、キーは "name" 属性として、値は "value" 属性としてエンコードしなければならない (MUST)。フォームは送信ボタンを含まなければならない (MUST)。

5.2.3.  エラー時の間接応答

不正な要求があった場合や無効な引数が含まれていた場合、OP は、ユーザエージェントを "openid.return_to" URL 値にリダイレクトしなければならない (MUST)。ただし、値が存在し、その値が有効な URL である場合に限る。

• openid.ns

  Section 4.1.2 (HTTP エンコーディング) で指定した通り。

• openid.mode

  値: "error"

• openid.error

  値: 人間が解読可能なメッセージ。エラーの原因を示す。

• openid.contact

  値: (オプション) サーバ管理者の連絡先。連絡先は、人間に対して表示するためのものなので、どのような形で記述してもよい。

• openid.reference

  値: (オプション) サポートチケット番号やニュースブログへの URL などの参照トークン。

サーバは、この応答に追加の鍵を追加してもよい (MAY)。

RP が不正なメッセージや無効なメッセージを受け取った場合、もしくは、"openid.return_to" が存在しなかったり、その値が有効な URL ではなかったりした場合、サーバはエンドユーザに応答を戻し、エラーが生じ、処理が継続できないことを示すべきである (SHOULD)。

6.  署名の生成

アソシエーションは、OpenID 認証メッセージに署名するために使用するメッセージ認証コード (MAC) 鍵として用いるのが最も一般的である。

MAC 鍵を生成するときは、[RFC1750] (Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,” .) に記されている勧告に従うべきである (SHOULD)。

6.1.  署名の生成手順

署名の生成手順は、以下の通りである。

1. 署名すべきメッセージに応じて、署名すべきキーのリストを決定する (Section 10.1 (肯定アサーション) 参照)。署名すべきキーのリストは、メッセージの一部でなければならない (MUST)。リストは "openid.signed" キーとともに格納される。値は、"openid." プレフィックスを削除したコンマ区切りのキーのリストである。このアルゴリズムは、"openid." で始まるキーの署名にのみ用いることができる。
2. "openid.signed" に示された順序で、署名すべきキーのリストそれぞれについて、メッセージ中から "openid." で始まり同じキーを持つ値を探す。
3. 署名すべキーと値のペアのリストを、キー・バリュー形式エンコーディング (キー・バリュー形式エンコーディング)でエンコードしてオクテット文字列に変換する。
4. アソシエーション形式 (アソシエーションの確立)から署名アルゴリズム (署名アルゴリズム)を決定する。その署名アルゴリズムをオクテット文字列に適用する。

6.2.  署名アルゴリズム

OpenID 認証は、以下のふたつの署名アルゴリズムをサポートしている。

• HMAC-SHA1 - 160 ビット鍵長 ([RFC2104] (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” .) および [RFC3174] (Eastlake, D. and P. Jones, “US Secure Hash Algorithm 1 (SHA1),” .))
• HMAC-SHA256 - 256 ビット鍵長 ([RFC2104] (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” .) および [FIPS180‑2] (U.S. Department of Commerce and National Institute of Standards and Technology, “Secure Hash Signature Standard,” .))

サポートされている場合は、HMAC-SHA256 の使用を推奨する (RECOMMENDED)。

7.  開始とディスカバリ

7.1.  開始

OpenID 認証を開始するに当り、RP は、ユーザ入力識別子の入力フォームをエンドユーザに提示すべきである (SHOULD)。

フォームが OpenID フォームであることが自動的に判断できるように、フォームフィールドの "name" 属性値は、"openid_identifier" であるべきである (SHOULD)。この属性に適切な値が設定されていないと、ブラウザの拡張機能など OpenID 認証をサポートするソフトウェアが RP のサポートを検出できないこともある。

7.2.  正規化

エンドユーザの入力は、識別子へと正規化されなければならない (MUST)。その手順を以下に示す。

1. ユーザの入力がプレフィックス "xri://" で始まる場合は、XRI が正準形式で使用されるように、その部分を削除しなければならない (MUST)。
2. その結果得られた文字列の最初の文字が、[XRI_Syntax_2.0] (Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” .) Section 2.2.1 で定義されている XRI グローバルコンテキストシンボル (Global Context Symbol) ("=", "@", "+", "$", "!") または "(" である場合、入力は XRI として扱うべきである (SHOULD)。
3. そうでない場合、入力は、http URL として扱うべきである (SHOULD)。得られた文字列に "http" または "https" スキームが含まれていない場合は、識別子の先頭に "http://" という文字列を付加しなければならない (MUST)。URL にフラグメント部分が含まれている場合、フラグメントの区切り文字 "#" も合わせて、その部分を削除しなければならない (MUST)。詳しくは、Section 11.5.2 (HTTP および HTTPS URL 識別子) 参照。
4. その後、コンテンツを取得するときにリダイレクトを辿り、最終的な目的の URL に対して [RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) Section 6 に記されている規則を適用することによって、URL 識別子をさらに正規化しなければならない (MUST)。この最終 URL を、RP は主張識別子として記録し、認証要求 (認証要求)時に使用しなければならない (MUST)。

正規化例 (正規化)参照。

7.3.  ディスカバリ

ディスカバリ (discovery) は、RP が識別子を使用して、要求の開始に必要な情報を調べる (“発見する (discover) ”) プロセスである。OpenID 認証には、ディスカバリを実行する3つの経路がある。

1. 識別子が XRI の場合、[XRI_Resolution_2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .) によって、必要な情報が記された XRDS 文書が生成される。また、RP は、XDI.org が http://www.xri.net で提供されているような XRI プロキシリゾルバを活用できるという点にも留意すべきである。XRI プロキシリゾルバを活用することによって、RP は XRI レゾリューションをローカルに行なう必要がなくなる。
2. 識別子が URL の場合は、Yadis プロトコル (Miller, J., “Yadis Specification 1.0,” .) [Yadis] を最初に試みるものとする (SHALL)。成功すれば、同様に XRDS 文書が結果として生成される。
3. Yadis プロトコルが失敗し、有効な XRDS 文書が取得できない場合、あるいは、XRDS 文書にサービスエレメント (OpenID サービスエレメント)が記されていない場合は、URL を取得し、HTML ベースのディスカバリ (HTML ベースのディスカバリ)を試みるものとする (SHALL)。

7.3.1.  ディスカバリによって得られる情報

ディスカバリが正常に完了すると、RP は、以下に示す情報を一組以上取得できる (定義については、用語セクション (用語)を参照)。以下に示す情報が二組以上得られた場合は、[XRI_Resolution_2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .) で定義されている優先順位規則を適用する。

• OP エンドポイント URL
• プロトコルバージョン

エンドユーザが OP 識別子を入力しなかった場合は、以下の情報も得られる。

• 主張識別子
• OP ローカル識別子

エンドユーザが OP 識別子を入力すると、主張識別子は得られない。OpenID 認証要求を行なう目的で、OP 識別子を入力するときには、主張識別子、OP ローカル識別子 の値はともに、"http://specs.openid.net/auth/2.0/identifier_select" を用いなければならない (MUST)。

7.3.2.  XRDS ベースのディスカバリ

XRI または Yadis ディスカバリを用いた場合、その結果、XRDS 文書が得られる。この XML 文書には、識別子に関連するサービスのエントリが含まれている。その定義は、Section 3 (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .) [XRI_Resolution_2.0] で行われている。付属資料 A.3 の Appendix A.3 (XRDS)を参照のこと。

7.3.2.1.  OpenID サービスエレメント

7.3.2.1.1.  OP 識別子エレメント

OP 識別子エレメントは、以下の情報を有する <xrd:Service> エレメントである。

テキスト内容が "http://specs.openid.net/auth/2.0/server" の <xrd:Type> タグ

テキスト内容が OP エンドポイント URL の <xrd:URI> タグ

7.3.2.1.2.  主張識別子エレメント

主張識別子エレメントは、以下の情報を有する <xrd:Service> エレメントである。

テキスト内容が "http://specs.openid.net/auth/2.0/signon" の <xrd:Type> タグ

テキスト内容が OP エンドポイント URL の <xrd:URI> タグ

テキスト内容が OP ローカル識別子 の <xrd:LocalID> タグ (オプション)

7.3.2.2.  認証データの抽出

RP が XRDS 文書を取得したら、まず ([XRI_Resolution_2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .) に記されている規則に従って)、その文書の中から OP 識別子エレメントを検索しなければならない (MUST)。見つからない場合は、主張識別子エレメントを検索する。

7.3.2.3.  XRI および正準化 ID エレメント

識別子が XRI の場合、OpenID 認証エレメント <xrd:Service> を含む <xrd:XRD> エレメントには、<CanonicalID> エレメントも含まれていなければならない (MUST)。また、このエレメントの内容を主張識別子として使用しなければならない (MUST) (Section 11.5 (エンドユーザの識別) 参照)。これはセキュリティ上の配慮として不可欠である。その理由は、<CanonicalID> エレメント の主要目的は、再度割り当てられることがない永続的 (persistent) な識別子を検証し、XRI が新たな登録者に ("乗っ取られる") 可能性をなくすことにあるからである。

RPは、<CanonicalID> エレメントを含む XRD の提供者がその正準化 ID に対する権限を有していること、また、当該 XRDS 文書がその OpenID サービスエレメントに対する権限を有していることを確認しなければならない (MUST)。RP は、これを手動で行なうか、リゾルバによる実施を確保すべきである。

XRI レゾリューションを用いる場合、正準化 ID を主張識別子として使用しなければならない (MUST)。XRI が有効な識別子であるためには、<ProviderID> と <CanonicalID> の両方がディスカバリによって得られた XRDS 文書の中に記されていなければならない (MUST)。

URL 識別子を用いる場合、正準化 ID が記されていたとしても、それを無視しなければならない (MUST)。

7.3.2.4.  追加情報

OpenID Authentication 2.0 以降、"openid"名前空間は使用されない。"xrd"名前空間は、"xri://$xrd*($v*2.0)" である。

使用されている既存のコードに対する互換性を確保するため、RP は、OpenID Authentication 1.1 互換モード (OpenID Authentication 1.1 との互換性)のセクションで記した通り、<xrd:Type> の値として "http://openid.net/signon/1.0" または "http://openid.net/signon/1.1" を受け入れることが推奨される (RECOMMENDED)。OpenID Authentication 2.0 をサポートする RP は、"http://specs.openid.net/auth/2.0/server" および "http://specs.openid.net/auth/2.0/signon" タイプのエンドポイントが利用可能な場合、Section 7.3.2.2 (認証データの抽出) で指定した順序で、これらのエンドポイントの利用を選択することが推奨される (RECOMMENDED)。

OP が拡張仕様 (Section 12 (拡張仕様) 参照) をサポートする場合は、その拡張仕様を <xrd:Service> エレメントの追加の <xrd:Type> 子エレメントとして列記すべきである (SHOULD)。

7.3.3.  HTML ベースのディスカバリ

RP は、HTML ベースのディスカバリをサポートしなければならない (MUST)。HTML ベースのディスカバリは、主張識別子のディスカバリにのみ用いることができる。OP 識別子は、XRDS ディスカバリをサポートする XRI または URL でなければならない。

HTML ベースのディスカバリを利用するためには、主張識別子の URL に HTML 文書が用意されていなければならない (MUST)。文書の HEAD エレメントは以下の要素を含む。

"rel" 属性が "openid2.provider" 、"href" 属性が OP エンドポイント URL に設定された LINK エレメントを含まなければならない (MUST)。

"rel" 属性が "openid2.local_id" 、"href" 属性がエンドユーザの OP ローカル識別子 に設定された LINK エレメントを含んでいてもよい (MAY)。

HTMLディスカバリの際のプロトコルバージョンは "http://specs.openid.net/auth/2.0/signon" である。

HTML 文書の提供ホストは、エンドユーザの OP のホストと異なっていてもよい (MAY)。

"openid2.provider" および "openid2.local_id" URL は、"&amp;" 、"&lt;" 、"&gt;" 、"&quot;" 以外のエンティティを含んでいてはならない (MUST NOT)。HTML 文書において有効でない、あるいは、文書の文字エンコーディングにおいて表現できない、その他の文字の使用は、[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) に示されるパーセントエンコーディング (%xx) の仕組みを用いて、エスケープしなければならない (MUST)。

OpenID Authentication 1.1 互換モード (OpenID Authentication 1.1 との互換性)のセクションで述べたように、これらのディスカバリタグは前バージョンのプロトコルとは同じではない。送られるデータに変更はないが、RP が使用するプロトコルのバージョンを決定できるように名称が変更された。RP は、バージョン 1.1 および 2.0 の両方のプロバイダを通知するために HTML ベースのディスカバリを利用する主張識別子に遭遇することもある (MAY)。

8.  アソシエーションの確立

RP と OP との間でアソシエーションを確立すると、共有秘密鍵が発行される。この共有秘密鍵を、その後両者間で交換されるプロトコルメッセージの検証に用いることで、メッセージのやりとりを減らすことができる。

RP がアソシエーションを形成できる場合は、アソシエーションを形成することが推奨される (RECOMMENDED)。RP がアソシエーションを構築・保持できない場合は、Section 11.4.2 (OpenID プロバイダを通じた直接検証) に示される代わりの検証の仕組みを用いる。この仕組みは、ステートレスモード (Stateless Mode) と呼ばれる。

8.1.  アソシエーションセッション要求

アソシエーションセッション (Association Session) は、RP から OP エンドポイント URL に対して、"openid.mode" が "associate" である直接要求 (直接通信 (Direct Communication))を行なうことよって開始される。

8.1.1.  共通の要求パラメータ

以下のパラメータは、全てのアソシエーション要求において共通して用いられる。

• openid.ns

  Section 4.1.2 (HTTP エンコーディング) で指定した通り。

• openid.mode

  値："associate"

• openid.assoc_type

  推奨されるアソシエーション形式。アソシエーション形式は、以後のメッセージの署名を行なう際に用いられるアルゴリズムを定義するためのものである。

  値：Section 8.3 (アソシエーション形式) で指定される有効なアソシエーション形式から選択。

• openid.session_type

  推奨されるアソシエーションセッション形式。データ送信中にアソシエーションの MAC 鍵の暗号化に用いる方法を定義する。

  値：Section 8.4 (アソシエーションセッション形式) で指定される有効なアソシエーションセッション形式から選択。

  注：トランスポート層の暗号化を使用していない場合は、"no-encryption" を用いてはならない (MUST NOT)。

8.1.2.  Diffie-Hellman 要求パラメータ

以下のパラメータは、要求するアソシエーションセッション形式が "DH-SHA1" の要求および "DH-SHA256" の要求の両方の場合に共通して用いられる:

• openid.dh_modulus

  値： base64(btwoc(p))

  デフォルト値：Appendix B (Diffie-Hellman 鍵交換のデフォルト値) 参照

• openid.dh_gen

  値： base64(btwoc(g))

  デフォルト値：g = 2

• openid.dh_consumer_public

  値： base64(btwoc(g ^ xa mod p))

これらのパラメータに関する詳細は、Section 8.4.2 (Diffie-Hellman アソシエーションセッション) 参照。

注： 'btwoc' 関数については、Section 4.2 (整数表現) で定義した通りである。

8.2.  アソシエーションセッション応答

アソシエーションセッション応答は、OP から RP に対して行なうキー・バリュー形式 (キー・バリュー形式エンコーディング)での直接応答である。

8.2.1.  共通の応答パラメータ

• ns

  Section 5.1.2 (直接応答 (Direct Response)) で指定した通り。

• assoc_handle

  アソシエーションハンドル (association handle) は、以後のメッセージにおいて、このアソシエーションを参照するキーとして用いられる。

  値： 長さが 255 文字以下の文字列。33-126 の範囲に含まれる ASCII 文字 (空白を除く印刷可能な文字) のみで構成しなければならない (MUST)。

• session_type

  要求の中の "openid.session_type" パラメータの値。OP がこのアソシエーション形式をサポートしたくない、あるいはサポートできない場合は、失敗時の応答 (失敗時の応答パラメータ)を戻さなければならない (MUST)。

• assoc_type

  要求の中の "openid.assoc_type" パラメータの値。OP がこのアソシエーション形式をサポートしたくない、あるいはサポートできない場合は、失敗時の応答 (失敗時の応答パラメータ)を戻さなければならない (MUST)。

• expires_in

  このアソシエーションの有効期限 (単位：秒)。RP は、当該期限を経過した後に、そのアソシエーションを使用してはならない (MUST NOT)。

  値： 整数値、ASCII 文字 10 進数表現。

8.2.2.  暗号化されない応答パラメータ

• mac_key

  このアソシエーションの MAC 鍵 (共有秘密鍵) で、Base 64 (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” .) [RFC3548] でエンコードしたもの。

8.2.3.  Diffie-Hellman 応答パラメータ

• dh_server_public

  値： base64(btwoc(g ^ xb mod p))

  説明： OP の Diffie-Hellman 公開鍵。

• enc_mac_key

  値： base64(H(btwoc(g ^ (xa * xb) mod p)) XOR MAC 鍵)

  説明： MAC 鍵 (共有秘密鍵) で、秘密の Diffie-Hellman 値を用いて暗号化したもの。セッション形式に応じて、ハッシュ関数 H は "SHA1" 、"SHA256" のいずれかとなる。

注： 'btwoc' 関数については、Section 4.2 (整数表現) で定義した通りである。

8.2.4.  失敗時の応答パラメータ

OP がセッション形式やアソシエーション形式をサポートしていない場合、アソシエーション要求が失敗したことを示す直接のエラーメッセージを含む応答を返さなければならない (MUST)。他のアソシエーションセッション形式またはアソシエーション形式をサポートしている場合、OP は、応答にその情報を含めるべきである。

• ns

  Section 5.1.2 (直接応答 (Direct Response)) で指定した通り。

• error

  値： 人間が解読可能なメッセージ。アソシエーション要求が失敗した理由を示す。

• error_code

  値： "unsupported-type"

• session_type

  値： (オプション) Section 8.4 (アソシエーションセッション形式) に示される有効なアソシエーションセッション形式のうち、OP がサポートしているもの。

• assoc_type

  値： (オプション) Section 8.3 (アソシエーション形式) に示されるアソシエーション形式のうち、OP がサポートしているもの。

"unsupported-type" の応答を受け取ったとき、RP は、アソシエーションセッション形式およびアソシエーション形式を指定して、再度、要求を行なってもよい (MAY)。アソシエーションが確立できない場合、RP は、直接検証 (OpenID プロバイダを通じた直接検証)の形で認証プロセスを継続してもよい (MAY)。

8.3.  アソシエーション形式

8.3.1.  HMAC-SHA1

"HMAC-SHA1" 形式のアソシエーションでは、HMAC-SHA1 (署名アルゴリズム) 署名アルゴリズムを用いる。

8.3.2.  HMAC-SHA256

"HMAC-SHA256" 形式のアソシエーションでは、HMAC-SHA256 (署名アルゴリズム) 署名アルゴリズムを用いる。

8.4.  アソシエーションセッション形式

OpenID 認証では、"no-encryption" 、"DH-SHA1" 、"DH-SHA256" の3 種類の有効なアソシエーションセッション形式が定義されている。

8.4.1.  暗号化されないアソシエーションセッション

"no-encryption" 形式のアソシエーションセッションでは、そのアソシエーションの MAC 鍵が OP から RP にプレーンテキストで送られる。そのため、トランスポート層での暗号化を行わない場合、悪意ある第三者がその鍵を傍受し、受信する RP に対してメッセージを改ざんすることが可能となる。従って、メッセージがトランスポート層での暗号化を行わない場合は、"no-encryption" 形式のアソシエーションセッションを用いてはならない (MUST NOT)。詳しくは、Section 15.1.1 (盗聴攻撃) を参照。

OP から送られる MAC 鍵 は、Section 6.2 (署名アルゴリズム) で指定した通り、要求されたアソシエーション形式で指定されている長さでなければならない。

8.4.2.  Diffie-Hellman アソシエーションセッション

"DH-SHA1" および "DH-SHA256" アソシエーション形式では、秘密共有鍵を安全に送信するために、Diffie-Hellman 鍵交換を用いる。

MAC 鍵 の長さは、ハッシュ関数 H の出力および、当該アソシエーションの署名アルゴリズムの出力と同じ長さでなければならない (MUST)。つまり、DH-SHA1 の場合は 160 ビット (20 バイト)、DH-SHA256 の場合は 256 ビット (32 バイト) となる。

RP は、モジュラス (法) p とジェネレータ (原始元) g を指定する。また、RP は任意の秘密鍵 xaをランダムに選び、OP は任意の秘密鍵 xb を選ぶ。これらの秘密鍵はともに、[1 .. p-1] の範囲に含まれていなければならない。このとき MAC 鍵の暗号化に用いる秘密共有鍵は、g ^ (xa * xb) mod p = (g ^ xa) ^ xb mod p = (g ^ xb) ^ xa mod p となる。詳しくは、[RFC2631] (Rescorla, E., “Diffie-Hellman Key Agreement Method,” .) を参照のこと。また、ランダム値の選択に関する詳細は、[RFC1750] (Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,” .) を参照。

9.  認証要求

RP がディスカバリの実行に成功し、ディスカバリによって得られた OP エンドポイント URL とアソシエーションを構築 (オプション) すれば、RP は、アサーションを得るために OP に認証要求を送ることができる。認証要求は、間接要求 (間接通信 (Indirect Communication))である。

9.1.  要求パラメータ

• openid.ns

  Section 4.1.2 (HTTP エンコーディング)で指定した通り。

• openid.mode

  値： "checkid_immediate" または "checkid_setup"

  注： RP がエンドユーザと OP との対話を望む場合は、"checkid_setup" を用いるべきである。エンドユーザと OP との対話を望まない状況の例として、JavaScript の中で非同期の認証要求が生じた場合があげられる。

• openid.claimed_id

  値： (オプション) 主張識別子。

  "openid.claimed_id" と "openid.identity" については、両方がともに存在するか、ともに存在しないかのいずれかとする (SHALL)。どちらの値も存在しない場合、そのアサーションは識別子に関するものではなく、拡張仕様 (拡張仕様)を用いて、ペイロードにその他の情報が含まれることになる。

  OP は、正規化 (正規化)のセクションで示した通り、"xri://" プリフィックスを伴った XRI 識別子または "xri://" プリフィックスを伴わない XRI 識別子を受け入れることが推奨される (RECOMMENDED)。

• openid.identity

  値： (オプション) OP ローカル識別子。

  openid.identity の値に異なる OP ローカル識別子 が指定されていない場合は、その値として主張識別子を用いなければならない (MUST)。

  注： openid.identity に "http://specs.openid.net/auth/2.0/identifier_select" という特殊値が設定されている場合、OP は、エンドユーザに属する識別子を選択すべきである (SHOULD)。このパラメータは、要求が識別子に関するものでない場合 (例えば、拡張仕様が使用され、当該パラメータがなくても要求が意味をなす場合。上記 openid.claimed_id 参照)、省略してもよい (MAY)。

• openid.assoc_handle

  値： (オプション) RP と OP の間のアソシエーションハンドル。応答に署名するために用いるべきである (SHOULD)。

  注：アソシエーションハンドルが送られない場合、トランザクションは、ステートレスモードで (OpenID プロバイダを通じた直接検証)行われる。

• openid.return_to

  値： (オプション) OP が要求のステータスを示す応答とともにユーザエージェントを戻すべき (SHOULD) URL。

  注：送られた要求の中にこの値が記されていない場合、エンドユーザが戻されることを RP は望んでいないということを意味している。

  注：認証要求に関するコンテキストを RP が認証応答に添付する仕組みとして、return_to URL を利用してもよい (MAY)。本文書では、クエリパラメータが外部の第三者によって変更されないことを RP が保証できる仕組みは定義していない。このような仕組みは、RP 自身で定義することができる。

• openid.realm

  値： (オプション) OP がエンドユーザに信任を求めるべきである (SHOULD) URL のパターン。Section 9.2 (レルム)参照。openid.return_to を省略した場合は、この値を送らなければならない(MUST)。

  デフォルト値： return_to URL

9.2.  レルム

レルム (realm) とは、OpenID 認証要求が有効な URL 空間を表すパターンである。レルムは、認証要求の対象範囲をエンドユーザに知らせるために考案された。エンドユーザに認証要求の承諾を求める際、OP はレルムを提示すべきである (SHOULD)。レルムは、OP が RP を一意に特定するために用いるべきである (SHOULD)。例えば、OP は、エンドユーザが認証要求の承認を自動化できるようにするために、レルムを用いてもよい (MAY)。

レルムパターンは URL であるが、以下の点が異なっている。

• レルムは、URI フラグメントを含んでいてはならない (MUST NOT)
• レルムは、URL のオーソリティセクションの先頭にワイルドカードを含んでいてもよい (MAY)。ワイルドカードは、"*." の文字列からなり、URL のオーソリティセクションの DNS 名の前に付加される。

以下の条件を満たす場合、URL はレルムにマッチする。

• URL スキームおよび URL のポートがレルムの中のスキームおよびポートと同一である。URI マッチングに関する規則については、RFC 3986 (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) [RFC3986]、Section 3.1 参照。
• URL のパスが、レルムのパスと同一、もしくはそのサブディレクトリである。
• 以下のいずれかが成り立つ。
  1. レルムのドメインがワイルドカード文字 "*." を含み、URL のドメインの末尾部分がワイルドカード "*." に続くレルム部分と同一である。
  2. URL のドメインがレルムのドメインと同一である。

"openid.return_to" URL が存在するとき、"openid.return_to" URL は "openid.realm" とマッチしなければならない (MUST)。マッチしない場合、OP は、エラー時の間接応答 (エラー時の間接応答)を返さなければならない (MUST)。

OP は、http://*.com/ や http://*.co.uk/ などあまりにも汎用的なレルムを用いてエンドユーザがアサーションを行なわないようにすることが推奨される (RECOMMENDED)。あまりにも汎用的なレルムは、特定の RP の識別に用いるときには、危険である場合がある。レルムが汎用的過ぎるかどうかの判断は、OP に委ねられている。

9.2.1.  レルムを用いた戻りURLの検証

OP は、要求において指定された return_to URL が OpenID RP のエンドポイントであることを検証すべきである (SHOULD)。return_to URL の検証を行なうには、RP に対するディスカバリ (OpenID リライングパーティーのディスカバリ)を実行し、レルムに対する RP のエンドポイントを取得する。ディスカバリを実行すると、その結果得られる URL は常に、リダイレクトを辿った先の最後の HTTP 応答の URL となる。レルムに対してディスカバリを実行したとき、その後何らかのリダイレクトが生じた場合、検証に失敗したことになる。ディスカバリが正常に完了したときは、return_to URL が RP のエンドポイントのひとつと一致することを確認する。

レルムはワイルドカードを含む場合があり、そのため有効なURLでないことがある。この場合は、レルムの中のワイルドカードを "www" に置き換え、その結果得られる URL に関してディスカバリを実行する。

return_to URL を RP のエンドポイントと照合するためには、RP のエンドポイント URL をレルムとして扱い、return_to URL をレルムと照合するために用いたのと同じ規則を適用する。RP の エンドポイント URL は、ドメインのワイルドカードを含んではならず (MUST NOT)、可能な限り、固有のものであるべきである (SHOULD)。

検証を試みても失敗した場合、プロバイダは、その return_to URL に肯定アサーション (positive assertion) を送るべきではない (SHOULD NOT)。

プロバイダは、検証済みの return_to URL をキャッシュしてもよい (MAY)。

9.3.  即時要求

RP は、認証要求に当り、OP がエンドユーザとの対話を行なわないことを要求してもよい (MAY)。この場合、OP は即時に、認証成功のアサーション、または、ユーザとさらに対話を行なわないと要求が完了できないことを示す応答のいずれかを返さなければならない (MUST)。即時要求は、認証要求の "openid.mode" に "checkid_immediate" という値を設定することによって実現できる。

10.  認証要求に対する応答

間接通信 (間接通信 (Indirect Communication))を通じてユーザエージェントから認証要求を受け取ったときには、OP は、認可済みの正規のエンドユーザが認証完了を望んでいると判断すべきである (SHOULD)。認可済みの正規のエンドユーザが認証完了を望んでいる場合、OP は、RP に肯定アサーション (肯定アサーション)を送るべきである (SHOULD)。

認可済みのエンドユーザの識別方法および OpenID 認証アサーションを戻す上で必要な承諾の取得方法については、本仕様の対象範囲外である。OP のセキュリティに関する考慮事項については、Section 15.1.2.1 (不正なリライングパーティーのプロキシ化)参照のこと。

"openid.identity" に "http://specs.openid.net/auth/2.0/identifier_select" という値を設定することによって OP 主導での識別子選択を RP が要求し、エンドユーザが認証応答の発行を認可される複数の識別子がある場合、OP は、エンドユーザがどの識別子を使用するのかを選択できるようにすべきである (SHOULD)。

RP が認証要求にアソシエーションハンドルを付与した場合、OP は、そのハンドルをもとにしてアソシエーションを探すべきである (SHOULD)。アソシエーションが見つからないか有効期限切れで失効している場合、OP は、応答の一部として、要求の "openid.assoc_handle" パラメータと同じ値で"openid.invalidate_handle" パラメータを送り返すべきである (SHOULD)。さらに OP は、アソシエーションハンドルが指定されなかった場合と同様に、処理を継続すべきである (SHOULD)。

アソシエーションハンドルの指定がない場合、OP は、応答への署名に専用のアソシエーションを用いるべきである (SHOULD)。OP は、このアソシエーションを記憶しなければならない (MUST)。また、その後の要求に応答し、直接検証 (OpenID プロバイダを通じた直接検証)を通じて応答の署名をチェックしなければならない (MUST)。

RP は、認証要求を済ませていない識別子に関するアサーションを受け入れ、検証すべきである (SHOULD)。OP は、一方的な (unsolicited) 肯定アサーションの署名に専用のアソシエーションを用いるべきである (SHOULD)

要求時に "openid.return_to" の値が省略されている場合、RP は認証アサーションを OP から受け取ることを望んでいない。これは、RP から OP へのデータ送信に拡張機能を用いている場合に役立つ。

10.1.  肯定アサーション

肯定アサーションのフィールドは、以下の通り。間接通信 (間接通信 (Indirect Communication))で行う。

• openid.ns

  Section 4.1.2 (HTTP エンコーディング) 指定した通り。

• openid.mode

  値： "id_res"

• openid.op_endpoint

  OP エンドポイント (Endpoint) URL。

• openid.claimed_id

  値： (オプション) 主張識別子。"openid.claimed_id" と "openid.identity"については、両方がともに存在するか、ともに存在しないかのいずれかとする (SHALL)。

  注：エンドユーザは、OP ローカル識別子 を主張識別子として 使用することを選択してもよい (MAY)。

  注：アサーションにどちらの識別子も存在しない場合、そのアサーションは識別子に関するものではなく、拡張仕様 (拡張仕様)を用いて、ペイロードにその他の情報が含まれることになる。

• openid.identity

  値： (オプション) OP ローカル識別子

  注：OpenIDプロバイダは、アサーションを作成する対象である主張識別子および OP ローカル識別子の選択において、エンドユーザを支援してもよい (MAY)。拡張仕様が使用され、当該フィールドがなくても応答が意味をなす場合、openid.identity フィールドを省略してもよい (MAY) (上記 openid.claimed_id 参照)。

• openid.return_to

  値： 要求時に送られた return_to URL パラメータそのままのコピー。

• openid.response_nonce

  値：長さが 255 文字以下の文字列で、この成功した特定の認証応答に固有のものでなければならない (MUST)。ノンスは、サーバの現在時刻で始まらなければならない (MUST)。またノンスには、それぞれの応答を固有のものとする上での必要に応じて、33-126 の範囲に含まれる ASCII 文字 (空白を除く印刷可能な文字) を追加してもよい (MAY)。日付および時刻は [RFC3339] Section 5.6[RFC3339] (Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps,” .)に指定される形式で記述しなければならない (MUST) が、以下の制限がある。

  • 時刻は全て世界協定時 ( UTC ) 時間帯とし、"Z" で示す。
  • 小数点以下の秒の記述は認められていない。

  例： 2005-05-15T17:11:51ZUNIQUE

• openid.invalidate_handle

  値： (オプション) 要求とともに RP が無効なアソシエーションハンドルを送った場合、その値をここに含めるべきである (SHOULD)。

• openid.assoc_handle

  値： このアサーションに署名するために用いられたアソシエーションのハンドル。

• openid.signed

  値：署名済みフィールドのコンマ区切りのリスト。

  注：このエントリは、署名がカバーしているフィールドからなるが、"openid." プリフィックスは省略する。このリストは、少なくとも "op_endpoint"、"return_to"、"response_nonce"、"assoc_handle" を含まなければならない (MUST)。また、応答に存在する場合は、"claimed_id" と "identity" を含まなければならない (MUST)。追加のキーをメッセージの一部として署名してもよい (MAY)。署名の生成 (署名の生成)を参照のこと。

  例："op_endpoint,identity,claimed_id,return_to,assoc_handle,response_nonce"

• openid.sig

  値: Section 6 (署名の生成) で指定した方法で計算され、Base 64 エンコードされた署名

10.2.  否定アサーション

OP がエンドユーザを識別できない場合、あるいは、エンドユーザが認証要求を承諾しない、もしくは承諾できない場合、OP は、RP に対し間接応答 (間接通信 (Indirect Communication))の形で否定アサーション (negative asserton) を送るべきである (SHOULD)。

"checkid_immediate" モードでの要求に対する応答として否定アサーションを受け取ったとき、RP は、"checkid_setup" モードを用いて、新たな認証要求を構築すべきである (SHOULD)。OpenID Authentication 1.1 との相違点に関する詳細は、Section 14 (OpenID Authentication 1.1 との互換性)で述べる。

10.2.1.  即時要求への応答の場合

要求が即時要求であった場合、エンドユーザが OP のページを介して対話し、識別用のクレデンシャルと要求に対するの承諾を送信する機会はない。即時要求への否定アサーションは、以下のフォームとする。

• openid.ns

  Section 4.1.2 (HTTP エンコーディング)で指定した通り。

• openid.mode

  値： "setup_needed"

10.2.2.  即時要求ではない要求への応答の場合

OP がエンドユーザに対してページを表示し、エンドユーザのクレデンシャルを要求してもよいことから、即時要求ではない要求への否定応答は最終的なものとなる。この場合の否定応答は、以下のフォームとする。

• openid.ns

  Section 4.1.2 (HTTP エンコーディング)で指定した通り。

• openid.mode

  値： "cancel"

ユーザが認証要求の完了を望まない場合、あるいは認証要求を完了できない場合、OpenID の認証プロセスが異常終了し、キャンセルモードの応答を RP が取得できないことが多い (継続する代わりに、エンドユーザは終了したり、ユーザエージェントの「戻る」ボタンを押したりするかもしれない)。RP が "cancel" 応答を受け取った場合、認証は失敗したことを意味し、RP はそのエンドユーザを認証されなかったものとして扱わなければならない (MUST)。

11.  アサーションの検証

RP が肯定アサーションを受け取ったときには、そのアサーションを受け入れる前に、以下の値について検証しなければならない (MUST)。

• "openid.return_to" が現在の要求の URL と一致する (Section 11.1 (戻り URL の検証))
• ディスカバリによって得られた情報がアサーションの情報と一致する (Section 11.2 (ディスカバリによって得られた情報の検証))
• "openid.response_nonce" について、当該 OP から、これまでに同じ値のアサーションを受け入れたことがない (Section 11.3 (ノンスのチェック))
• アサーションの署名が有効で、署名が必要な全てのフィールドに署名がされている (Section 11.4 (署名の検証))

上記４つの条件が全て満たされていれば、アサーションが検証されたことになる。アサーションに主張識別子が含まれている場合は、その識別子について、ユーザの認証が済んだことになる。

11.1.  戻り URL の検証

"openid.return_to" URL がこのアサーションを処理している URL と一致していることを検証するためには、

• URL のスキーム、オーソリティ、パスが、ふたつの URL の間で同じでなければならない (MUST)。
• "openid.return_to" URL のクエリ値は、どのパラメータも、RP が受け取った HTTP 要求の URL に同じ値がなければならない。

11.2.  ディスカバリによって得られた情報の検証

アサーションの中の主張識別子が URL で、フラグメントを含む場合、ディスカバリによって得られた情報を検証するために、そのフラグメント部分およびフラグメントの区切り文字 "#" を用いてはならない (MUST NOT)。

主張識別子がアサーションに含まれている場合、その主張識別子は RP が事前にディスカバリによって取得したものでなければならない (MUST)。また、アサーションの中の情報はディスカバリによって得られた情報の中に存在していなければならない (MUST)。主張識別子は OP 識別子であってはならない (MUST NOT)。

RP がその時点までに主張識別子をディスカバリによって取得していない場合 (要求中の "openid.identity" が "http://specs.openid.net/auth/2.0/identifier_select"または異なる識別子であった場合、もしくは、OP が一方的な肯定アサーションを送ろうとしている場合)、RP は応答の中の主張識別子に関するディスカバリを実行し、その主張識別子に関するアサーションを行なう権限を OP が有しているかどうかを確認しなければならない (MUST)。

応答の中に主張識別子がない場合、アサーションは識別子に関するものではない。RP は、ユーザを識別するために、現在の OpenID 認証トランザクションに関連するユーザ入力識別子を用いてはならない (MUST NOT)。しかし、アサーションの中の拡張仕様情報は用いてもよい (MAY)。

この表は、ディスカバリによって得られた情報 (ディスカバリによって得られる情報)の OpenID Authentication 2.0 "id_res" 応答 (肯定アサーション)へのマッピング (対応づけ) を示している。

XRDS 文書を生成するディスカバリの仕組みを使用する場合、いずれかの <xrd:Service> エレメントの中に、プロトコルバージョン、OPエンドポイントURL および OP ローカル識別子 (主張識別子と異なる場合) が記されていなければならない (MUST)。その <xrd:Service> エレメントの中に使用されないフィールドがあってもよい (MAY)。

参考例

<Service xmlns="xri://$xrd*($v*2.0)">
  <Type>http://specs.openid.net/auth/2.0/signon</Type>
  <URI>http://provider.example.com/openid</URI>
  <URI>https://provider.example.com/openid</URI>
</Service>

この XRDS 断片の例では、<xrd:Service> エレメントにふたつの <xrd:URI> エレメントがあり、Section 7.3.1 (ディスカバリによって得られる情報) の通り OP エンドポイント URL へと対応づけられている。アサーションの中の "openid.op_endpoint" の値がふたつのうちのいずれかであれば、そのフィールドとこの <xrd:Service> エレメントとが一致する。もう一方の <xrd:URI> エレメントは使われない。

11.3.  ノンスのチェック

リプレイアタックを阻止するため、署名のチェックを行なうエージェントは、肯定アサーションの中に含まれるノンス値の履歴を辿り、同一の OP エンドポイント URL について、同じ値を二度以上決して受け入れてはならない。

• "check_authentication" を用いるに当たり、OP は、要求への成功時の応答の "openid.response_nonce" に、同一の値を二度以上用いてはならない (MUST NOT)。
• RP がアサーションの署名をチェックするに当たり、RP は、同じ OP エンドポイント URL から "openid.response_nonce" の値が同一のアサーションを過去に受け入れていないことを保証すべきである (SHOULD)。

タイムスタンプを利用して、現在時刻との時間差が大きすぎる応答を拒否してもよい (MAY)。そのとき、攻撃を避ける上でノンスの保存が必要な時間は制限する。有効期間については、本仕様の対象範囲外である。有効期間が長いほど、より多くのノンスを、より長時間保存する必要がある。有効期間を短くすると、クロック・スキューやトランザクション時間が原因で誤って拒否してしまう可能性が高まる。

11.4.  署名の検証

アサーションで指定されるアソシエーションハンドルに紐付くアソシエーションを RP が保存した場合、RP は、アサーション自体の署名をチェックしなければならない (MUST)。アソシエーションを保存していない場合、RP は、OP が直接検証 (OpenID プロバイダを通じた直接検証)を通じて署名を検証するように要求しなければならない (MUST)。

11.4.1.  アソシエーションによる検証

RP は署名を生成する際に OP が従うのと同じ手順に従い、その後、応答の中の署名を生成された署名と比較する。署名が一致しなければ、アサーションは無効である。

認証要求に OP 、RP 間のアソシエーションのアソシエーションハンドルが含まれているが、OP がそのアソシエーションハンドルをもはや使用したくない場合 (例えば、有効期限が既に切れている、秘密鍵が漏えいしてしまったなどの理由による場合)、Section 11.4.2 (OpenID プロバイダを通じた直接検証) で指定する通り、OP は、OP との直接検証が必要な応答を送ることになる。この場合、OP は、RP から受け取った元の要求に含まれていたアソシエーションハンドルを "openid.invalidate_handle" の値に設定して、そのフィールドを含める。

11.4.2.  OpenID プロバイダを通じた直接検証

RP が OP に署名検証を行なわせたいときは、OP に直接要求 (直接要求 (Direct Request))を送る。OP は、署名検証のために、肯定アサーション (肯定アサーション)発行時に生成された専用のアソシエーションを用いる。

11.4.2.1.  要求パラメータ

• openid.mode

  値： "check_authentication"

• 認証応答の全てのフィールドをそのままコピー、ただし "openid.mode" を除く。

署名検証のために OP は、専用のアソシエーションを用いなければならない (MUST)。また、共有鍵を有するアソシエーションを用いてはならない (MUST NOT)。共有されているアソシエーションのハンドルが検証要求に含まれている場合は、RP がもはや秘密共有鍵を知らない、あるいは、このアソシエーションが RP 以外のエンティティ (例えば、攻撃者) と OP との間で確立してしまっていることを意味している。

リプレイアタックを阻止するため、OP は、過去に発行した認証応答のそれぞれについて、検証応答を二度以上発行してはならない (MUST NOT)。"openid.response_nonce" の値で、認証応答およびそれに対応する検証要求を識別してもよい。

11.4.2.2.  応答パラメータ

• ns

  Section 5.1.2 (直接応答 (Direct Response))Section 5.1.2 で指定した通り。

• is_valid

  値： "true" または "false"。検証要求の署名が有効かどうかを示す。

• invalidate_handle

  値： (オプション) OP が無効であることを確認した場合に、検証要求の中で送る "invalidate_handle" の値。

  説明： "true" に設定された "is_valid" を含む検証応答の中に、このパラメータが存在する場合、RP は、保存しているアソシエーションの中から対応するものを削除すべきである (SHOULD)。また、これ以降、このハンドルを含む認証要求を送るべきではない (SHOULD NOT)。

  注：認証応答に "invalidate_handle" パラメータを追加することによって、攻撃者がアソシエーションを自由自在に無効化してしまうのを防止するためには、こうした二段階のアソシエーション無効化プロセスが必要である。

11.5.  エンドユーザの識別

RP は、成功時の認証応答における主張識別子を、ローカルストレージ内のユーザ情報へのキーとして用いるべきである (SHOULD)。また、主張識別子をユーザが管理している識別子として用いてもよい (MAY)。URL 識別子を表示するときは、フラグメントを省略してもよい (MAY)。

11.5.1.  識別子のリサイクル

多数のユーザを抱える OP は、必要に応じ、フラグメントを用いて URL 識別子をリサイクルすることができる。新たなエンドユーザに対して URL 識別子の再割り当てを行なうに当り、OP は、新規かつ固有のフラグメント部分を生成すべきである。

フラグメント部分を含む URL 全体は、肯定アサーションにおいて主張識別子を構成する要素であるため、RP は、フラグメントを除く URL の現在の所有者と以前の所有者を区別することになる。

この仕組みを用いると、(恐らく短く、記憶しやすい) リサイクルされたフラグメントのない URL 識別子を、エンドユーザがログイン時に使用したり、RP が表示するために用いたりすることができるようになる。

11.5.2.  HTTP および HTTPS URL 識別子

RP は、異なるスキームを持つ URL 識別子同士を区別しなければならない (MUST)。エンドユーザの入力を URL に変換するときは、その URL は HTTP URL となる。同一のエンドユーザがスキーム以外は同一の URL を管理しており、識別子が HTTPS URL であることが望ましい場合、HTTP URL から HTTPS URL へのリダイレクトを発行することが推奨される (RECOMMENDED)。HTTP URL と HTTPS URL とは等価ではなく、使用される識別子は、リダイレクト後のURLであるため、このスキームを用いる場合には、セキュリティの低下は懸念されない。たとえ攻撃者が HTTP URL をコントロールできるようになったとしても、HTTPS URL には何の影響も与えないだろう。HTTP URL は、ディスカバリプロセスを開始させる以外には識別子として用いられないからである。

12.  拡張仕様

OpenID 認証の拡張仕様は、認証要求および応答の“上に乗る”プロトコルである。拡張仕様は、認証要求や応答に関するその他の情報を提供したり、認証応答の対象に関するその他の情報を提供したりする際に役立つ。

OpenID の拡張仕様は、サービスタイプ URI で識別される。サービスタイプ URI は、主張識別子と関連する XRDS 文書内で、OpenID <xrd:Service> エレメントの <xrd:Type> エレメントの値として用いてもよい (MAY)。サービスタイプ URI は、拡張仕様を含むメッセージの中で、キーと値のペアを関連づけるためにも用いられる。

メッセージの中で拡張仕様を用いてキーと値とを関連づけるためには、キーを サービスタイプ URI と関連づけなければならない (MUST)。キーとサービスタイプ URI とを関連づけるためには、頭に "openid.ns." を付加したキーを追加するとともに、値がサービスタイプ URI のエイリアステキストを後ろに追加することによって、エイリアスを確定する。エイリアスが確定すると、メッセージの中のペアのうち、"openid." で始まり、その後にエイリアステキストが続き、さらにその後ろにピリオドもしくはキーの末尾が続くようなキーを有するペアは全て、拡張仕様と関連づけられる。この仕組みは、XML名前空間と似ている。

名前空間のエイリアスは、ピリオドを含んでいてはならない (MUST NOT)。また、同じメッセージの中の他の名前空間のエイリアスと同じであってはならない (MUST NOT)。さらに、名前空間のエイリアスは、以下のリストに示す許可されていないエイリアスのひとつであってはならない (MUST NOT)。

• assoc_handle
• assoc_type
• claimed_id
• contact
• delegate
• dh_consumer_public
• dh_gen
• dh_modulus
• error
• identity
• invalidate_handle
• mode
• ns
• op_endpoint
• openid
• realm
• reference
• response_nonce
• return_to
• server
• session_type
• sig
• signed
• trust_root

同じメッセージの中で、ある名前空間にひとつ以上のエイリアスを割り当ててはならない (MUST NOT)。メッセージが他のメッセージへの応答の場合、その応答は、同じ名前空間を参照するのに異なるエイリアスを用いてもよい (MAY)。

参考例：

拡張仕様のサービスタイプ URI は、"<http://example.com/ext/1.0>" である。

openid.ns.x=http://example.com/ext/1.0

openid.x=example

openid.x.foo=bar

openid.xx=notx

この例において、"openid.x" と "openid.x.foo" という鍵は拡張仕様と関連づけられている。"openid.xx" という鍵は関連づけられていない。

拡張仕様は、同じ名前を有する複数のパラメータを定義してはならない (MUST NOT)。同じパラメータ名について複数の値を送る必要がある拡張仕様は、そのための独自の規則を定義しなければならない。

13.  OpenID リライングパーティーのディスカバリ

RP のディスカバリによって、ソフトウェアエージェントは、OpenID をサポートしているサイトを発見することができる。OpenID 要求の中の return_to URL が、指定されたレルムに対するOpenID RP のエンドポイントであることを、OpenID プロバイダが自動的に検証することも可能である。

RP は、Yadis プロトコルを使用して、有効な return_to URL を公開すべきである (SHOULD)。RP は、この情報をどの URL で公開してもよい (MAY)。また、プロバイダが return_to URL を検証できるように、レルムの範囲内で公開すべきである (SHOULD)。

RP のディスカバリの XRDS 文書は、ひとつ以上の <xrd:Service> エレメントを含まなければならない (MUST)。

• 少なくともひとつの <xrd:URI> エレメントを含む。
• 全ての <xrd:URI> タグが OpenID 2.0 認証応答を受け入れる URL を含む。
• 内容が "http://specs.openid.net/auth/2.0/return_to" である <xrd:Type> タグを含む。

参考例：

<Service xmlns="xri://$xrd*($v*2.0)">
  <Type>http://specs.openid.net/auth/2.0/return_to</Type>
  <URI>http://consumer.example.com/return</URI>
</Service>

14.  OpenID Authentication 1.1 との互換性

このセクションでは、OpenID Authentication 1.1 RP および OP との連携方法について説明する。OpenID Authentication 2.0 の実装においては、セキュリティに関する考慮事項によって好ましくないとされない限り、OpenID Authentication 1.1 互換性をサポートすべきである (SHOULD)。

14.1.  OpenID Authentication 1.1 からの変更点

（参考）

本仕様は、Brad Fitzpatrick が記した OpenID 認証のオリジナルの仕様に基づいている。その仕様にはバージョン番号がなかったが OpenID 1.0 と呼ばれ、その後改訂されて OpenID 1.1 となった。本仕様で概要を示しているプロトコルは、改訂後の OpenID プロトコルと下位互換性を保つように意図されている。仕様の変更点の概要は、このセクションに記す通りである。

14.1.1.  開始およびディスカバリに関わる更新

• OP 識別子をサポート。この新たな種類のプロトコルフローは、エンドユーザ自身の識別子の代わりに OP 識別子を入力することによって開始される。このため、OP は、エンドユーザによる識別子の選択を支援できる。
• 識別子としての XRI の使用をサポート。エンドユーザ用の識別子、OP 用の識別子のどちらにも XRI を使用してよい。また XRI は、ひとつ以上の再割り当て可能な (reassignable) i-names から同義かつ永続的で、再割り当てが決して行われない正準化 ID へと自動的にマッピングする。
• URL を識別子として用いた場合、既存のウェブのインフラとの互換性を高めるために、識別子は [RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) に示される指針に従って正規化される。
• ディスカバリでの Yadis プロトコルの使用。ひとつの識別子のために複数の OP を利用することができ、OP に不具合が生じたときのロードバランシングやフォールバックとして役立つ。さらに、サポートしている拡張仕様や他の関連サービスのディスカバリにも利用できる。

14.1.2.  セキュリティ面での改善

OpenID 2.0 ではノンスがプロトコルの一部として組み込まれ、リプレイアタックへの防御策が内蔵されることになった。こうした防御策はこれまで、それぞれのライブラリまたはアプリケーションが仕様の外で実装していた。

新たなアソシエーション形式である HMAC-SHA256 および新たなアソシエーションセッション形式である DH-SHA256 によって、認証アサーションにおける、より強力な署名が可能となった。

セキュリティに関する考慮事項のセクション (セキュリティに関する考慮事項)を設け、プロトコルをエンドツーエンドで保護するために考慮している。

14.1.3.  拡張仕様

OpenID 2.0 では、認証に加え、RPとOP間のデータ交換やその他の通信をサポートするための仕組みとして、拡張仕様が正式にサポートされた。拡張仕様は、任意の属性の交換に利用できるほか、RP に関する追加情報を認証要求の中に含めるといったプロトコルの拡張にも利用できる。

拡張機能は任意のデータを転送できるため、OpenID 2.0 では、認証メッセージの中への識別子の記述はオプションとなった。

14.2.  OpenID Authentication 1.1 互換性の実装

OpenID Authentication 1.1 のメッセージは全て "openid.ns" パラメータが省略されているため、OpenID Authentication 1.1 endpoint から送信されたメッセージかどうかを RP が簡単に判断することができる。OpenID Authentication 1.1 がサポートしているのは HMAC-SHA1 のアソシエーションのみである。

OpenID Authentication 1.1 のエラー時の応答では、"contact" や "reference" を定義していなかった。OpenID Authentication 1.1 では、エラー時の応答への追加フィールドの追加が可能であった。デバッグに役立つことがあり、また互換性に影響を与えないことから、OpenID Authentication 1.1 を使用するときも、連絡先や参照先を送ることが推奨される (RECOMMENDED)。

14.2.1.  リライングパーティー

• HTML ベースのディスカバリを実行したとき、OP エンドポイント URL のリンク関係は、"openid2.provider" よりも "openid.server" が優先して指し示される。また、エンドユーザの OP ローカル識別子のリンク関係は "openid2.local_id" よりも "openid.delegate" が優先して指し示される。これらに該当する場合、プロトコルバージョンは "http://openid.net/signon/1.1" である。HTML では、ひとつのリンクに対して複数のリンク関係を指定することができる。従って、もし OP が OpenID Authentication 1.1 と OpenID Authentication 2.0 の両方に対応していれば、同一の "rel" 属性に "openid2.provider" と "openid.server" の両方が記述されている可能性がある。
• XRDS ベースのディスカバリを実行したとき、エンドユーザの OP ローカル識別子は、OpenID <xrd:Service> エレメントの <xrd:LocalID> タグではなく、<openid:Delegate> タグに記述されている。現在実装されているディスカバリコードをサポートするため、<xrd:Service> エレメントに両方のタグを記述してもよい (MAY)。
• RP は、Yadis が URL 識別子で成功した場合、XRDS 文書から OpenID Authentication 1.x サービスエレメントを抽出し、利用すべきである (SHOULD)。該当のサービスエレメントは、<xrd:Type> タグのテキスト内容が "http://openid.net/server/1.0" または "http://openid.net/server/1.1" であることから特定できる。前バージョンのプロトコルでは定められていないが、Yadis を通じて OpenID Authentication 1.x サービスを広く知らせる手法として、一般に受け入れられている。
• OpenID Authentication 1.1 では、"openid.claimed_id" を定義していない。RP は、要求を行なうときに値を送ってもよい (MAY) が、認証応答の中に記述されている値に依存してはならない (MUST NOT)。OP ローカル識別子 ("openid.identity") と主張識別子とが異なっている場合、RP は、セッション状態に保持する等の方法で、OP ローカル識別子 のディスカバリ時にどの主張識別子を用いたのかを追跡しなければならない (MUST)。応答に主張識別子が記されることはないが、ユーザの識別子として主張識別子を用いなければならない (MUST)。
• 認証要求時 (認証要求に対する応答)には、"openid.identity" を送らなければならない (MUST)。
• "no-encryption" アソシエーション要求では、RP は、ブランクの session_type パラメータを送らなければならない (MUST)。
• OpenID Authentication 1.1 では、"openid.session_type" パラメータの内容がブランク、または、当該パラメータがない場合、"no-encryption" アソシエーションセッション形式 であることを意味する。RP は、"openid.session_type" の値を "no-encryption" に設定して要求を送ってはならない (MUST NOT)。
• 認証要求 (認証要求)では、OpenID Authentication 1.1 が OP 識別子の使用をサポートしていないので、"openid.identity"パラメータの値を特殊値 "http://specs.openid.net/auth/2.0/identifier_select" にすべきではない (SHOULD NOT)。
• 認証要求の中の "openid.realm" パラメータは、以前は "openid.trust_root" と呼ばれていた。構文規則や意味は全く同じである。
• "checkid_immediate" モードでの認証要求に対して、否定アサーションで応答するときは、"user_setup_url" パラメータを戻さなければならない (MUST)。このパラメータは、エンドユーザが要求を完了するために訪れるかもしれない URL を示している。OP は、エンドユーザをこの URL にリダイレクトしてもよい (MAY)。また、エンドユーザに、この URL を指し示すリンクを提供してもよい (MAY)。
• RP は、"openid.response_nonce" パラメータがない認証応答 (肯定アサーション)を受け入れなければならない (MUST)。リプレイアタックを防ぐための手段を実装すべきである (SHOULD)。
• RP は、"openid.op_endpoint" パラメータがない認証応答 (肯定アサーション)を受け入れなければならない (MUST)。

14.2.2.  OpenID プロバイダ

• 肯定の認証アサーション (肯定アサーション)の中に、"openid.identity" を含めて送らなければならない (MUST)。
• OpenID Authentication 1.1 では、"openid.session_type" パラメータの内容がブランク、または、当該パラメータがない場合、"no-encryption" アソシエーションセッション形式 であることを意味する。OP は、"openid.session_type" の値を "no-encryption" に設定して応答を送ってはならない (MUST NOT)。
• OP は、どのアソシエーション要求に対しても、成功時の "no-encryption" 応答を返すことを選択してもよい (MAY)。前述の通り、"openid.session_type" パラメータは、その内容をブランクとするか、パラメータ自体を省略するかしなければならない (MUST)。
• OP は、assoc_type でないパラメータが記されたアソシエーション要求を受け入れなければならない (MUST)。また、それらのアソシエーション要求は、HMAC-SHA1 タイプであると見なさなければならない (MUST)。
• アソシエーション構築が失敗したときは、直接のエラーメッセージ、あるいは "noencryption" の肯定アソシエーションで応答してもよい (MAY)。
• 認証要求の中の "openid.realm" パラメータは、以前は "openid.trust_root" と呼ばれていた。構文規則や意味は全く同じである。
• "checkid_immediate" モードでの認証要求に対して、否定アサーションで応答するときは、"user_setup_url" パラメータを戻さなければならない (MUST)。このパラメータは、エンドユーザが要求を完了するために訪れるかもしれない URL を示している。RP は、エンドユーザをこの URL にリダイレクトしてもよい (MAY)。また、エンドユーザに、この URL を指し示すリンクを提供してもよい (MAY)。
• OP は、認証応答時に "openid.op_endpoint" パラメータを送ってはならない (MUST NOT)。その理由は、OpenID Authentication 1.1 プロトコルが当該パラメータを実装していないからである。

15.  セキュリティに関する考慮事項

15.1.  アタック（攻撃）からの防御

15.1.1.  盗聴攻撃

このプロトコルには、盗聴攻撃に対して脆弱な部分が一か所存在する。

• ノンスのチェックが行なわれないと、盗聴者が成功時の認証アサーションを転送途中で入手して、再利用できてしまう。

こうした攻撃は、トランスポート層での暗号化を用い、これらの接続を盗聴行為から防御することによって防ぐことができる。また TLS を利用しない場合でも、メッセージ検証を実行する途中でノンスをチェックすることによって防ぐことができる。その場合は、肯定の認証アサーションの再利用はできなくなる。

15.1.2.  中間者攻撃

アソシエーションは、ディスカバリやアソシエーションセッション、直接検証 (OpenID プロバイダを通じた直接検証)の最中を除き、署名済みフィールドの中間者による改竄を防ぐ。秘密の共有鍵を知らずに署名済みフィールドを変更しようとすれば、MAC を解読する必要がある。現時点では、本プロトコルで用いられている MAC に関し、簡単に対処できる攻撃は判明していない。MAC によって提供される保護の質は 共有 MAC 鍵のランダムさに依存しており、推測できない値を用いることが重要となる。

DNS 名前解決やトランスポート層で漏えいが生じる場合、攻撃者が OP に成りすまし、攻撃者自身がアソシエーションを発行したり、ステートレスモードで自ら署名検証を行なったりできるため、メッセージへの署名では不十分である。攻撃者がディスカバリプロセスを改竄できる場合、攻撃者は任意のOP を指定することができ、OP に成りすます必要がなくなる。さらに、攻撃者が XRDS 文書を変更することによって、情報の完全性を損なうことができる場合、中間者さえ必要がなくなる。この種の攻撃を防ぐ方法のひとつとして、XMLDSIG (Eastlake 3rd, D., Reagle Jr., J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing,” .) [RFC3275] に示されるような XRDS ファイルへのデジタル署名があげられる。これらの署名に用いられている鍵を信頼するかどうかを最終的に判断する必要があるのは RP であるため、鍵となる材料 (keying materials) は指定しない。

SSL と信頼できる機関が署名した証明書を用い、DNS 検索結果と証明書を照らし合わせて検証することによって、こうした攻撃は、避けることができる。証明書の妥当性が立証されれば、改竄は不可能である。SSL サーバに成りすますためには、証明書を偽造したり、盗んだりする必要があるが、これらはネットワークベースの攻撃よりも遥かに困難である。

SSL による保護を受けるには、ユーザエージェントを通じたエンドユーザとの双方向の通信をはじめ、双方向の通信の全ての部分で SSL を用いなければならない。本プロトコルでは必須とはしていないが、SSL の使用が強く推奨される (RECOMMENDED)。エンドポイント URL およびエンドユーザのユーザエージェントとの双方向の通信のセキュリティを確保するために、OP は、SSLと信頼できる機関が署名した証明書を用いるべきである (SHOULD) ことが、現時点のベストプラクティスから明らかになっている。さらに、SSLと信頼できる機関が署名した証明書を用いることにより、RP は、エンドユーザの URL を安全な方法で取り出すことができる。RP は、種々のエンドポイントにおいて SSL が正しく用いられていない場合、RP 自身のセキュリティポリシに基づいて、トランザクションを完了しない、あるいは、トランザクションの開始さえしないことを選択してもよい (MAY)。

15.1.2.1.  不正なリライングパーティーのプロキシ化

特殊な形態の中間者攻撃のひとつとして、RP が不正な中間者（ MITM ）としての役割を果たす、というのがあげられる。RP は、エンドユーザの主張識別子に関してディスカバリを実行し、ユーザエージェントを OP にリダイレクトするのではなく、代わりに自分自身を通して OP をプロキシする。その結果、エンドユーザが OP に提供するクレデンシャルを、RP は入手することができるのである。この種の攻撃を防ぐにはいくつかの方法があるが、本文書で記述する対象範囲外である。これらの防御方法はいずれも、OP がエンドユーザとの間にセキュリティが確保されたチャネルを確立することが必要である。

15.2.  ユーザエージェント

本プロトコルは対話的に用いられることを意図しているため、ユーザエージェント (User-Agents) は、主として、一般に普及しているウェブブラウザとなるだろう。ウェブブラウザやそのホストは、スパイウェアやマルウェアに感染している可能性がある。その場合、ソフトウェアが信頼できず、認証がエンドユーザの承諾に基づいて行われたかどうかを知ることが不可能であるため、認証アサーションの強度は制限を受ける。従って、現状では、多くのウェブアプリケーションやプロトコルは、ウェブブラウザやそのホストのセキュリティに依存しているのである。

OP に対するクロスサイトスクリプティングアタックが、同様の効果を狙って行われる可能性がある。セキュリティを安全に保つために、OP は、スクリプトに依存すべきではない。こうすれば、スクリプトをサポートしていないユーザエージェントやスクリプトを使用不可に設定したユーザエージェントでもプロトコルを利用することができる。

15.3.  ユーザインタフェースに関する考慮事項

RP は、ブラウザのトップレベルのウインドウにおいて全てのコントロールを表示し、エンドユーザを OP エンドポイント URL にリダイレクトすべきである (SHOULD)。こうすれば、一見 OP のように見えるサイト（フィッシング）に対するエンドユーザの保護が向上する。

OpenIDプロバイダは、OpenID のフィッシングアタックの可能性について、エンドユーザを教育すべきである (SHOULD)。また、こうした攻撃を防ぐため、OP の認証サービスエンドポイント URL を検証するブラウザのプラグインなどのツールをエンドユーザに装備させるべきである (SHOULD)。

15.4.  HTTP および HTTPS URL 識別子

これらのタイプ識別子については、既に述べた通り (HTTP および HTTPS URL 識別子)であるが、再度触れておく価値がある。前述の通り、エンドユーザがスキーム以外は同一の URL を管理していることを表明するための方法としては、HTTP URL から HTTPS URL へのリダイレクトを発行することが推奨される (RECOMMENDED)。RP は、ディスカバリと開始フェーズでHTTP URLを決して保存するようなことはなく、リダイレクトを辿って、HTTPS URL を主張識別子として用いる。

本推奨事項に関心を持つエンドユーザは、自身の HTTPS URL をそれぞれの RP で直接入力すべきである。そうすれば、RP が HTTPS URL ヘのリダイレクトを辿る段階が省かれる。現時点で考慮すべき唯一のセキュリティに関する考慮事項は、攻撃者がリダイレクトを実施せず、識別子を不正な OP に向けることで、HTTP URL の完全性を損なう場合である。しかし、こうした攻撃は、ユーザエクスペリエンスを変化させるであろうし、アンチフィッシング技術を用いれば検知可能である。そして、OpenID においては、識別子自体のセキュリティが基本原則なのである。

15.5.  サービス妨害攻撃 （DoS 攻撃）

本プロトコルには、不正な RP が OP に対してサービス妨害攻撃を始めることができる部分がある。本当の要求であるかどうかを OP が迅速にチェックするための手段が OpenID プロトコルメッセージにないためである。サービス妨害攻撃は、RP がアソシエーションや認証、署名検証を繰り返し要求することによって可能となるのである。

こうした攻撃が最も重大な影響を与える可能性があるのは、各メッセージに対しOP が離散指数の演算を行う必要があるアソシエーションフェーズである。RP はメッセージごとにモジュラスやジェネレータを指定することができるので、攻撃者はOP に対し、各メッセージへの応答に優先して累乗計算をリアルタイムに実行するよう強制すらできる。

こうした攻撃は極めて有害であるが、OpenID プロバイダは、汎用の IP ベースの大量アクセス制限、禁止技術を用いて、この種の攻撃に容易に対抗することができる。OP は、"openid.realm" および "openid.return_to" の値をもとに禁止されている要求を調べることもできる。

15.6.  プロトコルの可変項目

プロトコルにおいては以下のバリエーションが知られており、これらのバリエーションは、プロトコルの使用に当たってのセキュリティに直接影響をあたえる場合も与えない場合もある。こうした値は、本プロトコルのためのセキュリティプロファイルの作成に用いられる可能性があると推測される。次の表は、OpenID プロバイダ側から見た可変項目のリストである。

特定されたセキュリティの可変項目

Appendix A.  使用例

参考

Appendix A.1.  正規化

テキスト URL の正規化の詳細およびさらなる事例については、[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) Section 6 を参照。

ユーザ入力の識別子への正規化

Appendix A.2.  OP ローカル識別子

エンドユーザが "http://www.example.com/" を主張識別子として使用したい。エンドユーザが OpenID プロバイダとしての機能を有する プロバイダ(example.com)にアカウントを持っている。エンドユーザの OP ローカル識別子 が "https://exampleuser.exampleprovider.com/" である。

このシナリオにおいて、適切な構成で Yadis または HTML ベースのディスカバリ（Section 7.3 (ディスカバリ) および下記 Appendix A.3 (XRDS) 参照）を実行すると、RP はエンドユーザに関して以下の情報が得られる。

主張識別子

http://www.example.com/

OP ローカル識別子

https://exampleuser.exampleprovider.com/

Appendix A.3.  XRDS

エンドユーザは "http://www.example.com/" を識別子として使用するが、RP には実際に OP エンドポイント URL "https://www.exampleprovider.com/endpoint/" で "https://exampleuser.exampleprovider.com/" を検証させるためには、"http://www.example.com/" に関するディスカバリを実行したとき、XRDS ファイルの最後の XRD エレメントに、以下の XML 断片が記されているべきである。

<Service xmlns="xri://$xrd*($v*2.0)">
  <Type>http://specs.openid.net/auth/2.0/signon</Type>
  <URI>https://www.exampleprovider.com/endpoint/</URI>
  <LocalID>https://exampleuser.exampleprovider.com/</LocalID>
</Service>

Appendix A.4.  HTML 識別子のマークアップ

"http://www.example.com/" を識別子として用いるが、RP には実際に "http://www.livejournal.com/openid/server.bml" で位置が指定される OpenID プロバイダで "http://exampleuser.livejournal.com/" を検証させるためには、識別子 URL によって位置が指定される HTML 文書の <head> 部分に、以下のマークアップが記されているべきである。

<link rel="openid2.provider openid.server"
      href="http://www.livejournal.com/openid/server.bml"/>
<link rel="openid2.local_id openid.delegate"
      href="http://exampleuser.livejournal.com/"/>

Appendix A.5.  XRI 正準化 ID

例えば、=example と =exmpl という XRI i-name がともに xri://(example)!1234 という正準化 ID を含む XRDS 文書を生成する場合、これらの識別子は同等として扱うべきである。ユーザアカウントを有するアプリケーションでは、永続的な正準化 ID 、xri://(example)!1234 を、そのアカウントの主キーとして用いるべきである。i-names =example および =exmpl を表示名として参照するために保存してもよいが、これらは再割り当て可能な識別子であり、永続的な鍵として用いるべきではない。

Appendix B.  Diffie-Hellman 鍵交換のデフォルト値

これは確認済みの素数で、Diffie-Hellman 鍵交換においてデフォルトのモジュラスとして用いられる。16 進表現では、以下の通りである。

DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61E
F75A2E27898B057F9891C2E27A639C3F29B60814581CD3B2CA3986D268370557
7D45C2E7E52DC81C7A171876E5CEA74B1448BFDFAF18828EFD2519F14E45E382
6634AF1949E5B535CC829A483B8A76223E5D490A257F05BDFF16F2FB22C583AB

Appendix C.  謝辞

OpenID コミュニティは、本仕様の草案作成および編集における、以下の人々の取り組みに謝意を表します。誰がどの部分を実際に書いたのか、その詳細が知りたい場合は、自由に当コミュニティの SVN リポジトリを調べたり、"svn blame" を使用したりして下さい。http://openid.net/svn/specifications/authentication/2.0/

Barry Ferg (barry@sxip.com)

Brad Fitzpatrick (brad@danga.com) <author>

Carl Howells (chowells@janrain.com)

David Recordon (david@sixapart.com) <author/editor>

Dick Hardt (dick@sxip.com) <author>

Drummond Reed (drummond.reed@cordance.net)

Hans Granqvist (hgranqvist@verisign.com)

Johannes Ernst (jernst@netmesh.us)

Johnny Bufu (johnny@sxip.com) <editor>

Josh Hoyt (josh@janrain.com) <author/editor>

Kevin Turner (kevin@janrain.com)

Marius Scurtescu (marius@sxip.com)

Martin Atkins (mart@degeneration.co.uk)

Mike Glover (mpg4@janrain.com)

16. 参考文献

Author's Address