[OpenID] OpenID Authentication 2.0 - Final 読みメモ

• ポインタ
• Abstract
• 2. Terminology
• 3. Protocol Overview
• 5番のOPでの一連がよく分からない。
• 4. Data Formats
• Protocol Messages
• Key-Value Form Encoding
• HTTP Encoding
• Integer Representations
• 5. Communication Types
• Direct Communication
• Direct Request
• Direct Response
• Indirect Communication
• HTTP Redirect
• HTML Form Redirection
• Indirect Error Responses
• 6. Generating Signatures
• Procedure
• Signature Algorithms
• 7. Initiation and Discovery
• Initiation
• Normalization
• Discovery
• Discovered Information
• XRDS-Based Discovery
• OpenID Service Elements - OpenID
• HTML-Based Discovery
• 8. Establishing Associations
• Association Session Request
• Common Request Parameters
• Diffie-Hellman Request Parameters
• Association Session Response
• Common Response Parameters
• Unencrypted Response Parameters
• Diffie-Hellman Response Parameters
• Unsuccessful Response Parameters
• Association Types
• HMAC-SHA1
• HMAC-SHA256
• Association Session Types
• No-Encryption Association Sessions
• Diffie-Hellman Association Sessions
• 9. Requesting Authentication
• Request Parameters
• Realms
• Using the Realm for Return URL Verification
• Immediate Requests
• 10. Responding to Authentication Requests
• Positive Assertions
• Negative Assertions
• In Response to Immediate Requests
• In Response to Non-Immediate Requests
• 11. Verifying Assertions
• Verifying the Return URL
• Verifying Discovered Information
• Checking the Nonce
• Verifying Signatures
• Verifying with an Association
• Verifying Directly with the OpenID Provider
• Identifying the end user
• Identifier Recycling
• HTTP and HTTPS URL Identifiers

• Final: OpenID Authentication 2.0 - Final
• Final: OpenID Authenticaion 2.0 - 最終版
• 自分が読む為の嘘翻訳

• 認証を希望する側がセンシティブな情報にアクセスする必要がない
• 分散化されている
• OPを変更したとしてもIdentifierを維持する事が出来る
  • どういう事だろうか？{{footnote("An end user can freely choose which OpenID Provider to use, and can preserve their Identifier if they switch OpenID Providers.")}}SecurityError (Insecure: can't intern tainted string): inline plugin
    
  • 異なるOPで協調するのだろうか
• JavaScriptやモダンブラウザを要求しない(AJAXで利用可能)
• 標準的なHTTP(S)リクエスト/レスポンスのみを利用する
  • HTTP以外の特別なメカニズムに縛られない
• プロフィール情報の交換などは他で示される

• IdentifierはいわゆるURL(http/httpsの絶対URI)かXRI
  • |http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.html
• OpenIDではHTTP/1.1を前提としている様子
• Identifierが沢山
  • Identifier
  • OP Identifier
  • User-Supplied Identifier
  • Claimed Identifier
  • OP-Local Identifier

5番のOPでの一連がよく分からない。

The OP establishes whether the end user is authorized to perform OpenID Authentication and wishes to do so. The manner in which the end user authenticates to their OP and any policies surrounding such authentication is out of scope for this document.
Final: OpenID Authentication 2.0 - Final

OpenID認証を行うことがエンドユーザーに認められているかどうかを、 OPは(認められていることを期待しつつ)確認します。 エンドユーザーがどうやってOPに自身を本物であると証明するか、 またその証明の手段はどうするか、といった点については、 この文書の範囲外とします。
Final: OpenID Authenticaion 2.0 - 最終版

自分の頭を整理。

• この段階では、RPから認証要求が送られている
• これを、RPからOpenID認証による認証の是非を問われていると考える
• OPは、RPに対して是非の結果を返す必要がある
• OPは、この是非の判断をエンドユーザに問いかける
  • OPがエンドユーザを信頼するための仕組みは仕様外
  • 一般に、OPでの認証(ログイン)
• エンドユーザはRPからの認証要求に対する返答をOP上で行う

以上、はてなのOpenIDを使ってLiveJournalを利用した流れから推測。

5番では、RPからの認証要求を捌く事が出来れば良いという事なのだろうか。おそらく、仕様を読み進めていく事で、色々と分かってくるのだろう。

Protocol Messages

• plain-text
• keyとvalueのペア
• UTF-8でエンコード
• 同じ名前のパラメータを含んではいけない

Key-Value Form Encoding

• keyとvalueのペアは１行で構成(LFで区切られる)
• keyとvalueはコロンで区切られる
• keyにコロンを含めてはいけない
• keyとvalueには改行を含めてはいけない
• 署名の計算と、RPへの直接的なレスポンスに使われる

HTTP Encoding

• メッセージがHTTPサーバへの送信されるとき、HTML4.01の17.13.4に明記されている"form encoding"を使ってエンコードしなければならない
  • Content-Typeヘッダもこれに従わなければならない
• リクエストメッセージに含まれるkeyは全て"openid."で始まらなくてはならない
• メッセージがPOSTで送られたとき、OpenIDのパラメータは必ずPOSTボディで送られるか、POSTボディから抽出されなくてはならない
• HTTPリクエスト(GET/POST)として送られるメッセージに必ず含まなければならないフィールド
  • openid.ns
    • "http://specs.openid.net/auth/2.0"
    • 省略されるか"http://openid.net/signon/1.1"か"http://openid.net/signon/1.0"が指定されている場合は、OpenID Authentication 1.1 Compatibility modeとして解釈されるべき
  • openid.mode
    • それぞれのメッセージタイプ
    • どんな種類のメッセージを処理するか知る
    • 空の場合はOpenIDメッセージではないと考えるべき

Integer Representations

• 任意精度の整数は、"big-endian signed two's complement binary strings"としてエンコードしなければならない
  • "btwoc"関数で処理
• Diffie-Hellman鍵交換で使われる全ての整数は正
  • "This means that the left-most bit of the two's complement representation MUST be zero."
  • "If it is not, implementations MUST add a zero byte at the front of the string."

Direct Communication

• RPからOP Endpoint URLに対して始められる
• 関連付け(association)の確率(section 8)
• 認証アサーションの検証(section 11.4.2)

Direct Request

• POSTボディとしてエンコードされなければならない
  • "section 4.1.2"の"HTTP Encoding"
• 全てのdirect requestはHTTP POST
  • section 4.1.2にリストされているフィールドが要求される

Direct Response

• Direct Request(section 5.1.1)へのレスポンスボディ
  • Key-Value Form(section 4.1.1)に従うHTTPレスポンス
  • content-typeはplain/textであるべき
• 全てのKey-Value Formメッセージは以下のフィールドを含まなければならない
  • ns
    • "http://specs.openid.net/auth/2.0"
    • 空もしくは"http://openid.net/signon/1.1"か"http://openid.net/signon/1.0"であればOpenID Authentication 1.1 Compatibility mode(Section 14)であるべき

Successful Responses

• 正当なリクエストを受けたサーバは200ステータスコードをつけてレスポンスを送らなければならない

Error REsponses

• リクエストが異常もしくは不正な引数を含んでいる場合、サーバは400ステータスコードをつけてレスポンスを送らなければならない
• レスポンスボディは以下のフィールドを含むKey-Value Form(section 4.1.1)メッセージでなければならない
  • ns
    • section 5.1.2 で示されている
  • error
    • エラーの原因を示す人が読む事が出来るメッセージ
  • contact(Optional)
    • サーバ管理者の連絡先。人に見せるために意図されていれば、連絡先はどんな形式でもかまわない
  • reference(optional)
    • サポートチケット番号やニュースブログのURLなどの参照トークン
• OPはこのレスポンスに追加のフィールドを付け足すかもしれない

Indirect Communication

• 間接通信では、メッセージはUser-Agentを介す
• 間接通信は、RPとOPのいずれからでも始める事が出来る
• 認証要求(section 9)
• 認証応答(section 10)
• ２つの方法がある
  • HTTPリダイレクト、HTMLフォーム方式
  • 送信者は受取URLを知っている事が要求される
    • 受取URLは4.1.2で示されている様な間接メッセージだと期待
• 通信を始める側は間接通信の適当なメソッドを選ぶ
  • 特性
  • メッセージサイズ
  • 他の外部要因

HTTP Redirect

• 302, 303, 307でのリダイレクト
  • User-Agentが処理してデータを転送
• リダイレクトURL
  • 4.1.2で示されるOpenID認証メッセージをクエリストリングにつけた受信者のURL

HTML Form Redirection

• HTMLのフォーム要素を利用
• form要素のaction属性は受信者のURLでなければならない
• 各Key-Valueはinput要素の中に含まれなければならない
  • keyはname属性、valueはvalue属性
    • フォーム送信時に、User-Agentは4.1.2で示される様なメッセージを生成するはず
• フォームはsubmitボタンを含まなければならない

Indirect Error Responses

• 異常なリクエストもしくは不正な引数が含まれていた場合
  • "openid.return_to"が示されて正当なURLなら
    • OPはUser-Agentに"openid.return_to"のURLを渡す?
• フィールド
  • openid.ns
    • section 4.1.2
  • openid.mode
    • "error"
  • openid.error
  • openid.contact
  • openid.reference
• サーバは追加キーをこのレスポンスに加えるかもしれない
• 異常なリクエストや不正なメッセージがRPに受信されるか、"openid.return_to"が無いか不正な場合
  • サーバはエンドユーザにエラーを示す応答を返してそれを続けさせるべきでない

• 関連付け(association)の最も一般的な用法
  • MAC(Message Authentication Code)キーをOpenID認証メッセージの署名に使う事
• MACキーの生成は、RFC1750に従う事が推奨されるべき

Procedure

メッセージ署名を生成する手順

1. 署名されるメッセージに従って、署名されるキーの一覧を決定(section 10.1)
   1. 署名されるキー一覧はメッセージの一部である必要がある
   2. 一覧は"openid.signed"キーと一緒に格納される
   3. 値はカンマ区切りの"openid."が取り除かれたキー一覧
   4. このアルゴリズムは"openid."から始まるキーへの署名にのみ有効?
2. ???
3. 署名されたkey/valueペアをKey-Value Form Encoding(section 4.1.1)に従ってオクテットストリングに変換
4. 関連付けタイプ(association type)に従って署名アルゴリズムを決定
   1. 署名アルゴリズムをオクテットストリングに適用する

この手順はよくわからない。多分、実装(コード)を読むと分かると思う。

Signature Algorithms

• OpenID認証がサポートする2つの署名アルゴリズム
  • HMAC-SHA1
    • RFC2104, RFC1374
  • HMAC-SHA256
    • RFC2104, FIPS180-2

Initiation

• RPがエンドユーザにUser-Supplied Identifierを入力するためのフィールドを持つフォームを示すべき
• そのフィールドのname属性は"openid_identifier"であるべき
  • User-Agentが自動的にOpenIDフォームであると判断できる

Normalization

• エンドユーザの入力は正規化されなければならない

1. "xri://"から始まる場合、XRIはcanonical formが使われるからそれをはぎとならければいけない?
2. その結果の文字列の先頭文字がXRI Global Context Symbolなら、XRIとしてみなされるべき
   1. XRI Syntax 2.0
3. さもなければ、入力はhttp URLとしてみなされるべき
   1. httpかhttpsのスキーマが含まれない場合、そのIdentifierは"http://"接頭辞をつけなければならない
   2. URLがfragmentを含むなら、#以降を切り捨てなければならない(section 11.5.2)
   3. URL Identifiersはさらに正規化されて最終的な宛先URLになる
      1. コンテンツを回収したときのリダイレクト
      2. RFC3986のsection 6
   4. この最終的な宛先URL
      1. Claimed IdentifierとしてRPに記されなければならない?
      2. 認証要求(requesting authentication)の時に使われなければならない?

• Appendix A.1. Normarization参照

Discovery

• RPでのプロセス
  • Identifierを初期化する為に必要な情報を探す?

1. XRIはXRDSドキュメントに従う
   1. RPはhttp://www.xri.netでXDR.orgに提供されるXRI Proxy Resolverという利点が得られる?
      1. RPからXRI Resolutionの場所の必要性を取り除く?
2. URLなら、Yadis protocolが最初に試みられるべき?
   1. もし成功したなら、結果はXRDSドキュメントで返る?
3. URLが回収され、HTML-Based discoveryが企てられるべき?
   1. Yadis protocolが失敗して、正当でないXRDSドキュメントがもたらされた
   2. Servie ElementがXRDSドキュメントの中にない

Discovered Information

• ディスカバリが成功裏に終わったときRPは１つ以上の情報を持つはず
• ディスカバリで得た情報は、XRI Resolution 2.で定義される優先ルールが適用される
  • OP Endpoint URL
  • Protocol Version
• エンドユーザがOP Identifierを入力してない場合、以下の情報が示される
  • Claimed Identifier
  • OP-Local Identifier
• エンドユーザがOP Identifierを入力したら、Claimed Identifierはない
• OpenID認証リクエストを作る為に
  • OP Identifierが入力されたときに
    • 値"http://specs.openid.net/auth/2.0/identifier_select"がClaimed IdentifierとOP-Local Identifierとして使われるべき?

XRDS-Based Discovery

• XRIかYadisディスカバリが使われたなら
  • 結果はXRDSドキュメントであるはず
• これはXMLドキュメント
  • Identifierに関連づけられたサービスの為のエントリー群?
  • XRI Resolution 2.0のsection 3
• Appendix A.3 にXRDSドキュメントのサンプル

OpenID Service Elements - OpenID

OP Identifier Element

• OP Identifier要素は以下の情報を持つ<xrd:Service>
  • <xrd:Type>
    • テキストで"http://specs.openid.net/auth/2.0/server"
  • <xrd:URI>
    • テキストでOP Endpoint URL

Claimed Identifier Element

• Claim Identifier要素は以下の情報を持つ<xrd:Service>
  • <xrd:Type>
    • テキストで"http://specs.openid.net/auth/2.0/signon"
  • <xrd:URI>
    • テキストでOP Endpoint URL
  • <xrd:LocalID>
    • (optional) テキストでOP-Local Identifier

Extracting Authentication Data

• RPはXRDドキュメントを得られたら
  • まずはOP Identifier要素を探さなければならない?
    • (XRI Resolution 2.0のルールに従う)
  • なければ
    • RPはClaimed Identifier要素を探すはず

XRI and the CanonicalID Element

• IdentifierがXRIのとき
  • OpenID認証の<xrd:Service>に含まれる<xrd:XRD>要素は
    • <CanonicalID>要素を含まなければならない
  • この要素のコンテントはClaimed Identifierとして使われなければならない(section 11.5)
  • これは重要なセキュリティの考察
    • <CanonicalID>要素の第一の目的は決して再設定されない持続的な識別子
  • XRIの新しい設定による乗っ取りを防ぐ?
• RPはXRD提供者を確認しなければならない?
  • <CanonicalID>要素がCanonical IDの為に信頼できる?
  • XRDSドキュメントがOpenID Service要素の為に信頼できる?
  • RPは手動で行うか、resolverが行う、いずれにせよ確実にしなければならない?
• XRI resolutionを使うとき
  • Canonical IDはClaimed Identifierとして使われなければならない
  • あるXRIが正当なIdentifierになるために?
    • <ProviderID>と<CanonicalID>の両方が発見されたXRDSドキュメントに示されなければならない
• URLのIdentifierが使われるとき
  • CanonicalID要素は示されても無視される

Additional Information

• "openid"名前空間はOpenID Authenticaiton 2.0では使われていない
• "xrd"名前空間は"xri://$xrd*($v*2.0)"

• すでに使われているコードの互換性の為に?
  • RPは<xrd:Type>の値に以下を受け入れる事が推奨されている
    • "http://openid.net/signon/1.0"
    • "http://openid.net/signon/1.1"
  • OpenID Authentication 1.1 Compatibility mode
  • OpenID Authentication 2.0を使う為に選べる事が推奨?
    • もし利用かな王ならエンドポイントは
    • "http://specs.openid.net/auth/2.0/server"
    • "http://specs.openid.net/auth/2.0/signon"
    • Extracting Authentication Data

• OPが拡張(section 12)をサポートする場合
  • 拡張は追加の<xrd:Service>要素の<xrd:Type>小要素として一覧されるべき?

HTML-Based Discovery

• RPでサポートされなければならない
• Claimed Identifierを発見する為にのみ使われる
• OP IdentifierはXRDS discoveryがサポートするXRIかURLでなければならない
• HTMLドキュメントはClaimed IdentiferのURLで利用可能でなければならない
  • 1つのlink要素は以下を含まなければならない
    • "openid2.provier"がセットされたrel属性
    • OP Endpoint URLがセットされたhref属性
  • 1つのlink要素は以下を含むかもしれない
    • "openid2.local_id"がセットされたrel属性
    • OP-Local Identifierがセットされたhref属性
• HTML discoveryが行われる時のプロトコルバージョンは"http://specs.openid.net/auth/2.0/signon"
• HTMLドキュメントのホストはエンドユーザのOPのホストと違うかもしれない
• "openid2.provider"と"openid2.local_id"のURLは以下以外のエンティティを含んではいけない?
  • &amp;
  • &lt;
  • &gt;
  • &quot;
• HTMLドキュメントとして不正な他の文字や表現不可能な文字は
  • パーセントエンコーディングを使ってエスケープされなければならない
    • RFC3986

• RPとOPの間で秘密を共有して確立される関連付け
  • 後に続くプロトコルメッセージの正当性の確認と、やり取りを減らすために使われる
• 可能であるなら、RPが関連付けを作る事が推奨される
• RPが関連づけを作れなかったり保管できなければ
  • section 111.4.2でStateless Modeとして参照される検証メカニズムが提供される

Association Session Request

• 関連付けセッションは
  • RPから"associate"という値を持つ"openid.mode"キーを付けたOP Endpoint URLへのdirect requestによって初期化される

Common Request Parameters

• 全ての関連づけリクエストで共通のパラメータ
  • openid.ns
    • section 4.1.2
  • openid.mode
    • "associate"
  • openid.assoc_type
    • 好ましい関連付けのタイプ
    • 関連づけタイプはメッセージに署名する為に使われるアルゴリズムを定める
    • 正当な関連づけタイプはsection 8.3で
  • openid.session_type
    • 好ましいセッションタイプ
    • トランジットの中の関連付けMACキーを暗号化するために使われる方法を定める
    • 正当な関連付けセッションタイプはsection 8.4で
    • トランスポート層での暗号化を使わない場合、"no-encryption"は使ってはならない

Diffie-Hellman Request Parameters

• 関連づけセッションタイプが"DH-SHA1"か"DH-SHA256"であると要求するために共通で要求するパラメータ?
  • openid.dh_modulus
    • base64(btwoc(p))
    • デフォルトはAppendix Bで
  • openid.dh_gen
    • base64(btwoc(g))
    • デフォルトはg=2
  • openid.dh_consumer_public
    • base64(btwoc(g ^ xa mod p))
• これらのパラメータについて更なる情報はsection 8.4.2で
• 'btwoc'関数はsection 4.2で

Association Session Response

関連づけセッションの応答はKey-Value FormによるOPからRPへの直接応答

Common Response Parameters

• ns
  • section 5.1.2で
• assoc_handle
  • 関連づけハンドルは後に続くメッセージを参照する為のキーとして使われる?
  • 255文字以内の文字列
    • 33-126の範囲に含まれるASCII文字で無ければならない
    • printable non-whitespace characters
• session_type
  • リクエストの"openid.session_type"パラメータの値
  • OPがこの関連付けタイプで好まないか不可能、もしくはサポートしない場合
    • unsuccessful responseを返さなければならない
• assoc_type
  • リクエストの"openid.assoc_type"パラメータの値
  • OPがこの関連付けタイプで好まないか不可能、もしくはサポートしない場合
    • unsuccessful responseを返さなければならない
• expires_in
  • 関連付けの秒による生存時間
  • RPはこの時間が過ぎた後で関連付けを使ってはならない
  • 10進数のASCIIで表現される整数?

Unencrypted Response Parameters

• mac_key
  • Base 64エンコードされた関連づけの為のMACキー(共有されたsecret)

Diffie-Hellman Response Parameters

• 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 key)
  • 秘密のDiffie-Hellman値で暗号化されたMACキー(共有されたsecret)
  • Hはセッションタイプの"SHA1"か"SHA256"かに依存する

Unsuccessful Response Parameters

• OPがセッションタイプか関連づけタイプをサポートしない場合
  • 関連づけリクエストの失敗を伝える直接のエラーメッセージで応答しなければならない
• もし別の関連づけタイプかセッションタイプをサポートする場合
  • OPはその情報を応答に含めるべき
• ns
  • section 5.1.2で
• error
  • 関連付けリクエスト失敗の理由を示す人が読む事が出来る
• error_code
  • "unsupported-type"
• session_type
  • (optional) OPがサポートする正当なセッションタイプ
  • section 8.4で
• assoc_type
  • (optional) OPがサポートする関連づけタイプ
  • section 8.3
• "unsupported-type"応答を受け取ったら
  • RPは示された関連づけセッションタイプと関連づけタイプを付けた別のリクエストを作るだろう
• もし関連付けが確立されなければ
  • RPはDirect Verificationによる認証プロセスを続けるだろう

Association Types

HMAC-SHA1

• "HMAC-SHA1"
  • HMAC-SHA1署名アルゴリズムを使った関連付けタイプ

HMAC-SHA256

• "HMAC-SHA256"
  • HMAC-SHA256署名アルゴリズムを使った関連付けタイプ

Association Session Types

• OpenID認証は３つの正当な関連付けセッションタイプを定義する
  • "no-encryption"
  • "DH-SHA1"
  • "DH-SHA256"

No-Encryption Association Sessions

• "no-encryption"関連づけセッションの中では
  • OPは関連づけMACキーをplain-textでRPに送る
    • これは、盗聴者がキーを横取りすることを可能にする
    • トランスポート層暗号化を使わないときRPはこのメッセージを作る?
• "no-encryption"関連づけセッションは
  • トランスポート層暗号化をを使ったメッセージなしでつかってはいけない?
  • 詳しい事はsection 15.1.1
• OPに送られたMACキーは
  • section 6.2で示された、要求される関連づけタイプの為の長さでなければならない

Diffie-Hellman Association Sessions

• "DH-SHA1"と"DH-SHA256"の関連づけタイプは
  • 共有secretを安全に交換する為に
  • Diffie-Hellman鍵交換を使う
• MACキーはこの関連付けの署名アルゴリズムの出力と同様Hの出力と同じ長さでなければならない
  • ハッシュ関数
    • DH-SHA1の為の160bit
    • DH-SHA256の為の256bit
• RPは係数pとジェネレータgを示す
• RPはランダムな秘密鍵xaを選び、そしてOPはランダムな秘密鍵xbを選ぶ
  • 両者ともに[1 .. p-1]の範囲
• MACキーを暗号化する為に使われる共有secret
  • g ^ (xa * xb) mod p = (g ^ xa) ^ xb mod p = (g ^ xb) ^ xa mod p
  • 詳しくはRFC2631
• 乱数の詳しい情報はFRC1750

• RPがディスカバリと(必要なら)発見したOP Endpoint URLとの関連付けを作成を成功させたら
  • アサーションを得る為にOPに認証要求を送る事が出来る
• 認証要求はindirect request

Request Parameters

• openid.ns
  • section 4.1.2で
• openid.mode
  • "checkid_immediate"か"checkid_setup"
  • RPがOPと相互に作用する事が出来るエンドユーザを望むなら
    • "checkid_setup"が使われるべき
• openid.claimed_id
  • (optional) Claimed Identifier
  • "openid.claimed_id"と"openid.identifier"は
    • いずれかがしめされるか、いずれも空であるべき
  • OPが"xri://"接頭辞ありなしのXRI Identifierを受け入れる事が推奨される
    • Normalizationセクションで示される
• openid.identity
  • (optional) OP-Local Identifier
  • 異なるOP-Local Identifierが示されないなら
    • claimed identifierはopenid.identityの為の値として使われなければならない?
  • 特別な値である"http://specs.openid.net/auth/2.0/identifier_select"がセットされる場合
    • OPはエンドユーザに属するIdentifierを選ぶべき
  • このパラメータは隠されるかも
    • リクエストidentifierに関する要求でない場合?
• openid.assoc_handle
  • (optional) RPとOPの間の関連付けの為のハンドルは応答を署名するのに使われるべき?
  • 関連づけハンドルが送られない場合
    • トランザクションはStateless Modeに移行する?
• openid.return_to
  • (optional) OPへのURLは
    • リクエストの状態を示す応答と一緒にUser-Agentに戻されるべき?
  • リクエストの中でこの値が送られなければ
    • RPがエンドユーザに戻される事を望んでいない事をしめす
  • return_to URLは認証応答のための認証要求に関するコンテキストをRPに紐づける為のメカニズムとして使われるだろう?
• openid.realm
  • (optional) URLパターン
    • OPが信頼してエンドユーザに質問するためのもの?
    • section 9.2
    • この値はopenid.return_toが省かれたなら送られなければならない
    • デフォルトでreturn_to URL

Realms

"realm"はOpenID認証要求が正当であるためにURL空間の一部を示すパターン?

• realmは認証要求のスコープをエンドユーザに示すために設計された?
• OPは認証要求のためのエンドユーザの同意を求めるときに示すべき
• realmはRPをユニークに識別する為にOPによって使われるべき?
• 例えば
  • OPは認証要求の自動的な同意をエンドユーザに許可するためにrealmを使うかもしれない
• realmパターンはURL(URLといかが異なる)
  • realmはURI fragmentを含んではならない
  • realmはauthorityセクションの開始にワイルドカードを含むかも
    • "*."というワイルドカードはURLのauthorityセクションの中のDNS名の前に付ける?
• URLがrealmとマッチする場合?
  • URLスキームとURLのポートがrealmの中で同じ?
    • URIマッチングルールの為にRFC3986のsection 3.1を読むと良い
• URLのパスが一致するかrealmのパスのサブディレクトリ
• ほか
  • realmのドメインがワイルドカード"*."を含み
    • URLのドメインの対応する部分がrealmの"*."ワイルドカードに続く部分に一致する
  • URLのドメインがrealmのドメインに一致する
• "openid.return_to"が示されるとき
  • URLは"openid.realm"とマッチしなければならない
  • もしくは
    • OPはindirect error messageを返さなければならない?
• OPはあまりに一般的な(overly-general)realmによるアサーションの作成からユーザを守る事が推奨されている?
  • http://*.com
  • http://*.co.uk
• overly-general realmはrealmが異常なRPに使われたときに危険を引き起こす?
• realmがoverly-general realmであるかはOPの自由?

Using the Realm for Return URL Verification

• OPはリクエストで示されるreturn_to URLがOpenIDのRPのエンドポイントである事を確かめるべき?
• return_to URLを確認のするために
  • RPでのディスカバリによってrealmのRPエンドポイントが手に入る?
• ディスカバリが行われるとき常に
  • 発見されたURLはリダイレクトを追いかけた最後のHTTPレスポンスのURL
• realmでディカバリが行われるときのいかなるリダイレクトが追いかけられるなら検証は失敗する
  • もし成功するなら
    • RPエンドポイントの中の1つでもreturn_to URLに本当にマッチするか確認しなさい?
• realmはワイルドカードを含むために正当なURLではない
  • この場合
    • realmの中のワイルドカードを"www"に取り替えて手に入れたURLからディスカバリ?
• RPエンドポイントとreturn_to URLをマッチさせるには?
  • return_to URLとrealmのマッチングルールと同じ物を使う
    • RPエンドポイントURLをrealmであるとして扱う
• RPエンドポイントURLはドメインワイルドカードを含んではならない
  • そして可能な限り示されるべき?
• 検証が試みられて失敗したなら
  • プロバイダはポジティブアサーションをreturn_to URlに送るべきでない?
  • プロバイダは検証されたreturn_to URlをキャッシュするかも?

Immediate Requests

• 認証を要求したとき
  • RPはエンドユーザとの対話をOPに望まないかも
• この場合
  • OPは認証が成功したというアサーションか
  • ユーザの対話なしには完了できない事を示す応答を
  • 直ちに返さなければならない
• これは"openid.mode"に"checkid_immediate"がセットされた認証リクエストによってなされる

• 認証リクエストが間接通信によってUser-Agentからきたとき
  • OPは認証を完了させたいと望む認可されたエンドユーザを判断するべき?
  • もし認可されたエンドユーザが認証の完了を望むなら?
    • OPはpositive assertionをRPに送るべき
• 認可されたエンドユーザを確認する方法とOpenID認証アサーションを返す為の承認の入手?
  • この仕様のスコープの内
  • OPのセキュリティ考察の為のsection 15.1.2.1をみるとよい
• RPがOPによるidentifierの選定を要求したら
  • "openid.identity"に"http://specs.openid.net/auth/2.0/identifier_select"をセット
  • 認証レスポンスを発行するためにエンドユーザが認可される複数のIdentifier
  • OPはエンドユーアにどのIdentifierを使うか選ぶ事を許可するべき
• RPが認証リクエストについてくる関連づけハンドルを提供した場合
  • OPはハンドルに基づく関連付けを探す事を試みるべき
  • 関連付けが失われたか期限切れの場合
    • OPは"openid.invalidate_handle"パラメータをリクエストの"openid.assoc_handle"パラメータの値と一緒にレスポンスの一部として送るべき
    • OPは関連づけハンドルが示されなかったとして続行すべき?
• 関連づけハンドルが示されなかった場合
  • OPはレスポンスへの署名の為の私的な関連付けを使うべき
    • OPはこの関連付けを格納しなければならないし
    • 後のリクエストのためにDirect Verificationによる応答の署名をチェックチェックする事を返さなければならない?
• RPは認証を要求しないIdentifierに関するアサーションを受け入れて検証すべき?
  • OPは求められないpositiveアサーションに署名する為に私的な関連付けを使うべき?
• "openid.return_to"の値がリクエスト中で隠された場合
  • RPはOPから認証アサーションを受け取る事を期待しない
  • RPからOPへの転送データの為の拡張を使う時に便利?

Positive Assertions

• Positive assertionsはindirect responses
• openid.ns
  • section 4.1.2で
• openid.mode
  • "id_res"
• openid.op_endpoint
  • OP Endpoint URL
• openid.claimed_id
  • (optional) Claimed Identifier
  • "openid.claimed_id"と"openid.identity"はどちらかが示されるかどちらも空であるべき
  • エンドユーザはClaimed IdentifierとしてOP-Local Identifierを使う事を選ぶかも
  • どちらのIdentifierもアサーションに存在しないなら
    • 識別子の事ではなく
    • 拡張を使ってペイロードの中に他の情報を含めるだろう
• openid.identity
  • (optional) OP-Local Identifier
  • OPはエンドユーザの選択を助けるかも
    • アサーションが作られる事に関するClaimed IdentifierとOP-Local Identifierの選択?
• openid.return_to
  • リクエストとして送られたreturn_toパラメータのコピー
• openid.response_nonce
  • 255以内の文字列
    • 個々の成功の認証レスポンスでユニークでなければならない
  • nonceは
    • サーバの現在時間から始まらなければならない
    • 33-126の範囲に含まれる追加のASCII文字を含むかもしれない
    • それぞれのレスポンスをユニークにする為に必要?
  • 日付と時間はRFC3339のsection5.6で示されるフォーマットでなければならない
    • 全ての時間は"Z"と一緒に示されるUTCタイムゾーンでなければならない
    • 端数の秒は許可されない
  • 例: 2005-05-15T17:11:51ZUNIQUE
• openid.invalidate_handle
  • (optional) RPがリクエストに不正な関連付けハンドルを含めて送った場合に、ここに含まれるべき
• openid.assoc_handle
  • このアサーションに署名する為に使った関連付けのハンドル
• openid.signed
  • カンマで区切られた署名フィールドのリスト
  • "openid."接頭辞を削ったフィールドからなる
    • 署名を包む?
  • 一覧は少なくとも
    • "op_endpoint"と"return_to"と"response_nonce"と"assoc_handle"を含まなければならない
    • もしレスポンス中に存在するなら"claimed_id"と"identity"も
  • 追加のキーはメッセージの一部として署名されるだろう
  • 例: "op_endpoint,identity,claimed_id,return_to,assoc_handle,response_nonce"
• openid.sig
  • base64でエンコードされた、section6で示された様に計算された署名

Negative Assertions

• OPがエンドユーザを識別できないかエンドユーザが認証リクエストを承認できないなら?
  • OPは否定のアサーションをRPに間接応答として返すべき
• "checkid_immediate"モードリクエストでレスポンスの中の否定のアサーションを受けたとき
  • RPは"checkid_setup"モードを使った新しい認証リクエストを構築すべき
• OpenID Authentication 1.1からの違いがどうかという詳細はsection 14で見つかる

In Response to Immediate Requests

• immediateリクエストが要求された場合
  • エンドユーザにチャンスがない
    • 識別の証明を与える為のOP上のページでの対話か
    • リクエストの承認
• openid.ns
  • section 4.1.2で
• openid.mode
  • "setup_needed"

In Response to Non-Immediate Requests

• OPがエンドユーザにページを表示してエンドユーザからの証明書を要求
  • immediateでないリクエストへの否定のレスポンスは最終的?
• openid.ns
  • section 4.1.2で
• openid.mode
  • "cancel"
• もしユーザが認証リクエストを望まないか完了できない場合
  • OpenID認証プロセスは中断されるだろうし
  • RPはcanncel mode応答を得ないだろう
• RPが"cancel"応答を受け取ったら
  • 認証は失敗で
  • RPはエンドユーザをnon-authenticatedとして扱わなければならない

• RPが肯定のアサーションを受け取ったとき
  • アサーションを受け取る前に検証を行わなければならない
• "openid.return_to"の値は現在のリクエストのURLとマッチする(section 11.1)

1. 発見された情報はアサーションの中の情報とマッチする?(section 11.2)
2. アサーションは"openid.response_nonce"と同じ値を持つOPからまだ受け入れられていない?(section 11.3)
3. アサーションの署名は正当で、署名に必要とされる全てのフィールドは署名されている?(section 11.4)

• これら4つの条件を満たすなら
  • アサーションは実証された?
• もしアサーションがClaimed Identifierを含むなら
  • そのユーザはその識別子で認証された

Verifying the Return URL

• "openid.return_to"URLがそのURLにマッチする事を確かめるプロセス?

1. URLスキーム、authority, パスが両方のURLで同じ
2. "openid.return_to"URLに存在する全てのクエリパラメータは
   1. RPが受け取ったHTTPリクエストのURLの中のものと同じでなければならない

Verifying Discovered Information

• アサーションの中のClaimed IdentifierがURLでfragmentを含む場合
  • fragment部分とfragmentデリミタの"#"は
    • 発見された情報を確認する目的で使われてはならない?
• アサーションにClaimed Identifierが含まれる場合
  • RPによって発見されているべきで
  • アサーションの中の情報は発見された情報の中に存在するべき
  • Claimed IdentifierはOP Identifierであってはならない?
• Claimed Identifierが前もってRPによって発見されていない場合?
  • リクエストの中の"openid.identity"が"http://specs.openid.net/auth/2.0/identifier_select"か
  • 異なるIdentifierか
  • OPが求められない肯定のアサーションを送った場合
  • RPはOPがClaimed Identifierについて認可する許可を与えられている事を確認する為に
    • レスポンスのClaimed Identifier上でディスカバリを行う?
• レスポンスにClaimed Identifierがない場合
  • アサーションは識別子に関する事ではなく
  • RPはユーザを識別する為の現在のOpenID認証トランザクションに関連づけられたUser-supplied Identifierを使ってはならない?

Checking the Nonce

リプレイ攻撃を防ぐ為に

• • 署名をチェックするエージェントは肯定のアサーションに含まれるnonce値を保つ?
  • 同じOP Endpoint URLに同じ値を2度と受け付けない
• "check_authentication"を使うとき
  1. OPは同じ"openid.response_nonce"をつけたリクエストに更なる成功のリクエストを発行してはならない?
• RPがアサーションの署名をチェックするとき
  • RPは同じOP Endpoint URLからの"openid.response_nonce"のと同じ値でまだ受け付けていない事を保証すべき?
• タイムスタンプは現在時刻からかなり離れた応答をはじく事に使われるだろう?
  • 攻撃を防止する為に時間の量を制限してnonceを格納すべき?
• 時計のずれによるより短い範囲での増加とトランザクション時間がまがいものの排除を引き起こす?

Verifying Signatures

• RPセッション内の関連付けハンドルで示される関連付けを持っているなら?
  • 自身のアサーション上の署名を確認しなければならない?
• 関連付けを持っていないなら
  • Direct VerificationによってOPが署名を検証するよう要求しなければならない?

Verifying with an Association

• RPはOPが従ったgenerating the signatureの手順に従い?
  • 生成された署名とレスポンス内の署名を比較する?
  • 署名がマッチしなければアサーションは不正
• 認証リクエストがRPとOPの関連づけハンドルを含む場合
  • そしてOPが長い事そのハンドルを使おうとしない場合
    • 期限切れかsecretが信用できない?
  • OPはSection 11.4.2で示されるように、OPによって直接検証されるべきレスポンスを送る?
  • このインスタンスの中で
    • OPはRPがオリジナルのリクエストに含んでいた関連付けハンドルをセットした"openid.invalidate_handle"を含む?

Verifying Directly with the OpenID Provider

• OPによる署名検証が行われるために?
  • RPはOPにdirect requestを送る
• 署名を検証する為に
  • OPはpositive assersionが発行されたときに生成されたprivateな関連付けを使う

Request Parameters

• openid.mode
  • "check_authentication"
  • "openid.mode"の為に期待する?
    • 認証レスポンスから全てのフィールドの全く同一のコピー?
• 署名を検証するために?
  • OPはprivateな関連付けのみを使わなければならない
  • 共有鍵を持つ関連付けを使ってはならない?
• もし検証リクエストが共有された関連付けの為のハンドルを含むなら?
  • RPは長い事共有されたsecretを知らない事を意味するか?
  • ほかのRPがOPとこの関連付けを確立している事を意味する?
• リプレイ攻撃を防ぐ為に
  • OPは過去に発行された認証要求のための検証レスポンスをさらに発行してはならない?
• 認証レスポンスとマッチした検証リクエストはそれらの"openid.response_nonce"値によって識別される

Response Parameters

• ns
  • Section 5.1.2で
• is_valid
  • "true"か"false"
  • 検証リクエストの署名が正当かどうか
• invalidate_handle
  • (optional) OPが不正だと確認した場合に検証リクエストの中で送られる値?
  • "true"がセットされた"is_valid"つきで検証レスポンスが示された場合
    • RPは対応する関連付けを削除すべき?
    • このハンドルでさらに認証リクエストを送るべきでない
  • 不正な関連付けの為の2ステップは攻撃者を防ぐ為になくてはならない?
    • 認証レスポンスに"invalidate_handle"パラメータをつける事で不正にする関連付けから?

Identifying the end user

• 成功した認証レスポンスの中のClaimed Identifierは
  • ユーザに関する情報のローカルストレージの為のキーとしてRPに使われるべき
• Claimed Identifierはユーザの表示の為のIdentifierとして使われるかも
• URL Identifierが表示されるとき、fragmentは隠されるかも?

Identifier Recycling

• 多くのユーザがいるOPは望むならURL Identifierの再利用の為にfragmentを使う事ができる?
• 新しいエンドユーザにURL Identifierを再割当るとき
  • OPは新しい物を生成するかユニークなfragment部分を使うべき?
• fragment付きの完全なURLは肯定のアサーションの中のClaimed Identifierを構成する?
  • それゆえに、RPはfragmentなしURLの現在と以前の持ち主を見分けるだろう?
• この仕組みは(多分短い、覚えやすい)再利用されたfragmentなしのURL Identifierを許可する?
  • 表示する目的のためにRPによってエンドユーザのログイン時に使われる事を?

HTTP and HTTPS URL Identifiers

• RPは異なるスキームを持つURL Identifierを区別しなければならない
• エンドユーザの入力がURLに処理されるときそれはHTTP URLで処理される?
• 同じエンドユーザがスキームのみが異なる同じURLをコントロールするなら?
  • そして、HTTPS URLとして望まれるなら?
    • HTTP URLからHTTPS URLにリダイレクトするべき?
  • なぜなら、HTTPとHTTPSのURLは同等ではなく
    • 使われたIdentifierがリダイレクトに従ったURL
    • このスキームを使うときに安全性の低下がみこまれる?ない?
  • 攻撃者がHTTP URLの制御を得る事が出来たら
    • HTTPS URLの効果が得られない?
    • HTTP URLはディスカバリプロセスを始める事をのぞいてIdentifierとして使われる事は決してない?