TOC 
DraftN. Sakimura
 NRI
 J. Bradley
 Ping Identity
 M. Jones
 Microsoft
 B. de Medeiros
 Google
 C. Mortimore
 Salesforce
 August 3, 2015


OpenID Connect Basic Client Implementer's Guide 1.0 - draft 37

Abstract

OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである. このプロトコルは, Client が Authorization Server の認証結果に基づいて End-User のアイデンティティを検証することを可能にする. また同時に End-User の必要最低限のプロフィール情報を, 相互運用可能かつ RESTful な形で取得することも可能にする.

本ドキュメント OpenID Connect Basic Client Implementer's Guide 1.0 は, OpenID Connect Core 1.0 仕様のサブセットであり, OAuth Authorization Code Flow を利用して Web ベースの Relying Party を実装する際に読みやすいように構成されている. 本ドキュメントは Core 仕様と重複したコンテンツを含んでいるが, それは実装者が本ドキュメントを読むだけで OAuth Authorization Code Flow を利用した Relying Party を実装できるよう意図したものである.

OpenID Provider および Web ベース以外のアプリケーションの実装者は, Core 仕様を参照のこと.



Table of Contents

1.  Introduction
    1.1.  Requirements Notation and Conventions
    1.2.  Terminology
    1.3.  Overview
2.  Protocol Elements
    2.1.  Code Flow
        2.1.1.  Client Prepares Authentication Request
            2.1.1.1.  Request Parameters
        2.1.2.  Client Sends Request to Authorization Server
        2.1.3.  Authorization Server Authenticates End-User
        2.1.4.  Authorization Server Obtains End-User Consent/Authorization
        2.1.5.  Authorization Server Sends End-User Back to Client
            2.1.5.1.  End-User Grants Authorization
            2.1.5.2.  End-User Denies Authorization or Invalid Request
        2.1.6.  Client Obtains ID Token and Access Token
            2.1.6.1.  Client Sends Code
            2.1.6.2.  Client Receives Tokens
    2.2.  ID Token
        2.2.1.  ID Token Validation
    2.3.  UserInfo Endpoint
        2.3.1.  UserInfo Request
        2.3.2.  Successful UserInfo Response
        2.3.3.  UserInfo Error Response
    2.4.  Scope Values
    2.5.  Standard Claims
        2.5.1.  Address Claim
        2.5.2.  Claims Languages and Scripts
        2.5.3.  Claim Stability and Uniqueness
3.  Serializations
    3.1.  Query String Serialization
    3.2.  Form Serialization
4.  String Operations
5.  TLS Version
6.  Implementation Considerations
    6.1.  Discovery and Registration
7.  Security Considerations
    7.1.  TLS Requirements
8.  Privacy Considerations
    8.1.  Personally Identifiable Information
    8.2.  Data Access Monitoring
    8.3.  Correlation
    8.4.  Offline Access
9.  IANA Considerations
10.  References
    10.1.  Normative References
    10.2.  Informative References
    10.3.  翻訳プロジェクト
Appendix A.  Acknowledgements
Appendix B.  Notices
Appendix C.  Document History
Appendix D.  翻訳者
§  Authors' Addresses




 TOC 

1.  Introduction

本ドキュメント OpenID Connect Basic Client Implementer's Guide 1.0 は, OpenID Connect Core 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” August 2015.) [OpenID.Core] 仕様のサブセットであり, OAuth 2.0 [RFC6749] (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) Authorization Code Flow を利用して Web ベースの Relying Party を実装する際に読みやすいように構成されている. 本ドキュメントは Core 仕様と重複したコンテンツを含んでいるが, それは実装者が本ドキュメントを読むだけで OAuth Authorization Code Flow を利用した Relying Party を実装できるよう意図したものである. 本実装者ガイドと OpenID Connect Core 仕様の間に齟齬がある場合は, Core 仕様を優先する.

OAuth Implicit Flow を利用する Web ベースの Relying Party を実装する場合には, OpenID Connect Implicit Client Implementer's Guide 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Implicit Client Implementer's Guide 1.0,” July 2015.) [OpenID.Implicit] を参照のこと. OpenID Provider および Web ベース以外のアプリケーションの実装者は, Core 仕様を参照のこと. 本ガイドは OpenID Provider および Web ベース以外のアプリケーションに関する Implimentation Consideration および Security Considerations を省略している.

OpenID Connect のベースとなる OAuth 2.0 Authorization Framework (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] と OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] は, 3rd-party アプリケーションが HTTP リソースへの限定的アクセス権を取得および行使するための全般的フレームワークを提供している. これらはリソースアクセスのための Access Token を取得および行使する方法は定義するが, アイデンティティ情報を提供するための標準的手段は定義しない. とりわけ, OAuth 2.0 のプロファイリングを行わずに End-User の認証に必要な情報を提供することは不可能である. 本ドキュメント読者は上記2つの仕様を理解していることが期待される.

OpenID Connect は OAuth 2.0 認可プロセスを拡張し, 認証目的で利用できるようにする. 本拡張を利用する場合, Client は openid scope を指定して Authorization Request を送信する. 本拡張を利用した Authorization Request は, Authentication Request と呼ばれる.

認証結果は ID Token (Section 2.2 (ID Token) 参照) と呼ばれる JSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.) [JWT] として返される. OpenID Connect をサポートする OAuth 2.0 Authentication Server は, OpenID Provider (OP) とも呼ばれる. OpenID Connect を利用する OAuth 2.0 Client は Relying Party (RP) とも呼ばれる.

本ドキュメントでは, Relying Party は Authorization Endpoint, Token Endpoint 等を含む OpenID Provider の設定情報を既に得ているものとする. これらの情報は通常 OpenID Connect Discovery 1.0 (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” August 2015.) [OpenID.Discovery] にある Discovery を通じて得られるが, その他の手段で得られることもある.

また同様に, Relying Party は OpenID Provider 利用に必要なクレデンシャルを取得し, OP 利用に必要な情報を登録しているものとする. これの処理は通常 OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” August 2015.) [OpenID.Registration] にある Dynamic Registration を通じて行われるが, その他の手段で行われることもある.



 TOC 

1.1.  Requirements Notation and Conventions

本ドキュメント中の "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" の意味するところは, [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) の定める通りである.

本ドキュメントの .txt バージョンでは, 表記そのままで利用される値についてはクオートで囲んでいる. このような値をプロトコルメッセージ中で用いる場合, クオートを含めてはならない (MUST NOT). HTML バージョンではクオートで囲う代わりに this fixed-width font を用いる.

JSON Web Signature (JWS) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [JWS] を用いる場合, シリアライゼーションには JWS Compact Serialization を用いる. JWS JSON Serialization は利用しない.

本ドキュメント中の RFC 2119 に定義されるキーワードが OpenID Provider の挙動に言及する場合, それはあくまで Client 実装者が OpenID Provider の挙動を理解しやすいように用いられているに過ぎない.



 TOC 

1.2.  Terminology

本ドキュメントでは, OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] で定義された "Access Token", "Authorization Code", "Authorization Endpoint", "Authorization Grant", "Authorization Server", "Client", "Client Authentication", "Client Identifier", "Client Secret", "Grant Type", "Protected Resource", "Redirection URI", "Refresh Token", "Resource Owner", "Resource Server", "Response Type" および "Token Endpoint", JSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.) [JWT] で定義された "Claim Name", "Claim Value", および "JWT Claims Set", JSON Web Signature (JWS) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [JWS] で定義された "Header Parameter" および "JOSE Header", RFC 7230 (Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing,” June 2014.) [RFC7230] で定義された "User Agent" という用語を用いる.

本ドキュメントはその他に以下の用語を用いる.

Authentication
提示された Identity と実際の Entity が紐づいているという十分な確信を得るためのプロセス.
Authentication Request
OpenID Connect が定める拡張パラメータおよびスコープを利用して, Authorization Server に End-User の認証を要求する OAuth 2.0 Authorization Request. このとき Authorization Server は OpenID Connect Provider, Client は OpenID Connect Relying Party となる.
Claim
Entity に関する情報の部分集合.
Claims Provider
Entity の Claim を返すサーバー.
End-User
一連のフローに参加する人間.
Entity
あるコンテキストの中で識別される, 他と独立した個. End-User は Entity の一例.
ID Token
Authentication イベントに関する Claim を含む JSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.) [JWT]. その他の Claim を含むこともある (MAY).
Identifier
あるコンテキスト中で Entity をユニークに特徴づける値.
Issuer
Claim を発行する Entity.
Issuer Identifier
検証可能な Issuer の識別子. Issuer Identifier は, 大文字小文字を区別する URL である. この URL は https スキーム, ホスト, そして任意でポート番号およびパス要素からなり, クエリーとフラグメント要素は含まない.
OpenID Provider (OP)
End-User を Authenticate できる OAuth 2.0 Authorization Server. End-User の Authentication イベントに関する Claim を Relying Party に提供する.
Pairwise Pseudonymous Identifier (PPID)
ある Relying Party に対してのみ, ある Entity の識別子として提供される値. 他の Relying Party には, 当該 PPID を当該 Entity と関連づけることはできない.
Personally Identifiable Information (PII)
特定の人物に紐づき, 実際の人物の識別に用いることができる情報. もしくは特定の人物に直接および間接的にリンクされる可能性のある情報.
Relying Party (RP)
OpenID Provider に End-User Authentication と Claim を要求する OAuth 2.0 Client.
Subject Identifier
Issuer にとって局地的にユニークで再利用されることのない End-User 識別子. この値は Client に利用されることを想定する.
UserInfo Endpoint
Protected Resource のひとつ. Access Token を提示する Client に対して, Authorization Grant に従って End-User に関する情報を提供する.
Validation
あるものごとの健全性および正当性を確立するためのプロセス.
Verification
ある事実や値の正確さを検査もしくは証明するためのプロセス.
Voluntary Claim
Client が End-User が要求するあるタスクを実行する際に, 有用ではあるが Essential ではないとを Client が指定した Claim.

IMPORTANT NOTE TO READERS: 上記の用語定義は本ドキュメントが定めるところであり, 本ドキュメントの実装においてはこれらの定義に従うこと. "Issuer Identifier" をはじめとして, 本ドキュメントで大文字表記されている用語はすべて上記の定義に従う. 本ドキュメントの読者は必ずこれらの用語定義に従うこと.



 TOC 

1.3.  Overview

OpenID Connect プロトコルは, おおまかに言って以下のステップに従う.

  1. RP (Client) が OpenID Provider (OP) にリクエストを送る.
  2. OP は End-User を認証し, 認可を受ける.
  3. OP は ID Token および (通常は) Access Token を返す.
  4. RP は Access Token を添えて UserInfo Endpoint にリクエストを送る.
  5. UserInfo Endpoint は End-User の Claim を返す.

これら一連のステップを以下に図示する.

+--------+                                   +--------+
|        |                                   |        |
|        |---------(1) AuthN Request-------->|        |
|        |                                   |        |
|        |  +--------+                       |        |
|        |  |        |                       |        |
|        |  |  End-  |<--(2) AuthN & AuthZ-->|        |
|        |  |  User  |                       |        |
|   RP   |  |        |                       |   OP   |
|        |  +--------+                       |        |
|        |                                   |        |
|        |<--------(3) AuthN Response--------|        |
|        |                                   |        |
|        |---------(4) UserInfo Request----->|        |
|        |                                   |        |
|        |<--------(5) UserInfo Response-----|        |
|        |                                   |        |
+--------+                                   +--------+


 TOC 

2.  Protocol Elements

Authentication Request は Authorization Code Flow, Implicit Flow および Hybrid Flow のいずれかのフローに従う. Authorization Code Flow は, Authorization Server と Client 自身との間でセキュアに Client Secret を管理できる Client 向けのフローである. それが不可能な Client は Implicit Flow を用いる. しかしながら, Client Secret をセキュアに保持できないにも関わらず, Refresh Token 取得のためにしばしば Native アプリケーションやその他の Client が Authorization Code flow を利用することもある. Hybrid Flow は Authorization Code Flow と Implicit Flow をあわせたものであり, Client が Authorization Server から直接 ID Token およびオプションで Access Token を受け取ることでレイテンシ低下を防ぎつつも, 後から Client が Token Endpoint にアクセスして各種トークン (特に Refresh Token) を取得できるようにするものである.

このドキュメントは Code Flow を利用する Client に対して必要十分な情報のみを提供する.



 TOC 

2.1.  Code Flow

Code Flow は以下のステップからなる.

  1. Client は必要なリクエストパラメータを含んだ Authentication Request を構築する.
  2. Client は Authorization Server にリクエストを送信する.
  3. Authorization Server は End-User を認証する.
  4. Authorization Server は End-User の Consent/Authorization を取得する.
  5. Authorization Server は End-User を code とともに Client に戻す.
  6. Client は code を Token Endpoint に送信し, Access Token と ID Token を受け取る.
  7. Client はそれらのトークンを検証し, End-User の Subject Identifier を取得する.



 TOC 

2.1.1.  Client Prepares Authentication Request

RP が End-User を Authenticate したい, もしくは End-User が既に Authenticated であるかどうか知りたい場合, Client は Authorization Endpoint に Authentication Request を送る.

Authorization Endpoint との間の通信は TLS を利用しなければならない (MUST). TLS の詳細については Section 7.1 (TLS Requirements) を参照のこと.

Client は RFC 7231 (Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content,” June 2014.) [RFC7231] に定義される HTTP GET もしくは HTTP POST を利用できる (MAY).

HTTP GET を利用する場合, パラメータは Section 3.1 (Query String Serialization) にある Query String Serialization を用いてシリアライズされる. HTTP POST を利用する場合, パラメータは [W3C.REC‑html401‑19991224] (Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.) にある application/x-www-form-urlencoded フォーマットを用いてエンティティボディ中に含まれる.

以下は Authentication Request URL の一例である. (改行は掲載上の都合による)

  https://server.example.com/authorize?
    response_type=code
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj


 TOC 

2.1.1.1.  Request Parameters

OpenID Connect は以下の OAuth 2.0 リクエストパラメータを利用する.

response_type
REQUIRED. 値は code とすること (MUST). これにより Authorization Endpoint から返される code と交換で, Access Token および ID Token が Token Endpoint から返されることになる.
client_id
REQUIRED. Authorization Server における OAuth 2.0 Client Identifier の値.
scope
REQUIRED. OpenID Connect リクエストは scope に openid を含まねばならない (MUST). OPTIONAL な scope としては, profile, email, address, phone, および offline_access が定義されている. それぞれの scope 値についての詳細は Section 2.4 (Scope Values) を参照のこと.
redirect_uri
REQUIRED. レスポンスが返される Redirection URI. この URI は, Client が OpenID Provider に対して事前に登録済みの Redirection URI のいずれかと完全一致しなければならない (MUST). マッチングルールは [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) (Simple String Comparison) の Section 6.2.1 に従うこと. Redirection URI は https スキーマを利用することが望まれる (SHOULD) が, Client Type が confidential であり, かつ OP が http の利用を容認する場合に限り, http スキーマを利用してもよい (MAY). Client Type 等の定義については OAuth 2.0 の Section 2.1 を参照のこと. Redirection URI には, ネイティブアプリケーションにコールバックを送る目的などで, 上記以外のスキーマを利用することもできる.
state
RECOMMENDED. リクエストとコールバックの間で維持されるランダムな値. 一般的に Cross-Site Request Forgery (CSRF, XSRF) 対策の目的で利用される, ブラウザ Cookie と紐づく暗号論的にセキュアな値を取る.

本ドキュメントは上記に加えて以下のリクエストパラメータを定義する.

nonce
OPTIONAL. Client セッションと ID Token を紐づける文字列であり, リプレイアタック対策に用いられる. この値は Authentication Request で指定され, そのままの値で ID Token に含まれる. nonce 値には, 推測不可能なように十分なエントロピーを持たせること (MUST). この条件を満たすには, 暗号論的にセキュアな乱数を HttpOnly なセッションクッキーとして用い, その暗号論的ハッシュ値を nonce として利用するといった方法が考えられる. この場合, ID Token に含まれて返される nonce 値をセッションクッキーのハッシュ値と比較することで, 第三者によるリプレイアタックを検知することができる. Code Flow を利用する場合, nonce の利用は OPTIONAL である.
display
OPTIONAL. Authorization Server が認証および同意のためのユーザーインタフェースを End-User にどのように表示するかを指定するための ASCII 値 [RFC20] (Cerf, V., “ASCII format for Network Interchange,” October 1969.). 以下の値が定義されている.
page
Authorization Server は認証および同意 UI を User Agent の全画面に表示すべきである (SHOULD). display パラメータが指定されていない場合, この値がデフォルトとなる.
popup
Authorization Server は認証および同意 UI を User Agent のポップアップウィンドウに表示すべきである (SHOULD). User Agent のポップアップウィンドウはログインダイアログに適切なサイズで, 親ウィンドウ全体を覆うことのないようにすべきである.
touch
Authorization Server は認証および同意 UI をタッチインタフェースを持つデバイスに適した形で表示すべきである (SHOULD).
wap
Authorization Server は認証および同意 UI を "feature phone" に適した形で表示すべきである (SHOULD).
Authorization Server は User Agent の機能を検知して適切な表示を行うようにしても良い (MAY).
prompt
OPTIONAL. Authorization Server が End-User に再認証および同意を再度要求するかどうか指定するための, スペース区切りの ASCII 文字列のリスト. 以下の値が定義されている.
none
Authorization Server はいかなる認証および同意 UI をも表示してはならない (MUST NOT). End-User が認証済でない場合, Client が要求する Claim 取得に十分な事前同意を取得済でない場合, またはリクエストを処理するために必要な何らかの条件を満たさない場合には, エラーが返される. 典型的なエラーコードは login_required, interaction_required である. この prompt 値は現在の認証状態, 同意状況を確認する為にも利用できる.
login
Authorization Server は End-User を再認証するべきである (SHOULD). 再認証が不可能な場合はエラーを返す (MUST). 典型的なエラーコードは login_required である.
consent
Authorization Server は Client にレスポンスを返す前に End-User に同意を要求するべきである (SHOULD). 同意要求が不可能な場合はエラーを返す (MUST). 典型的なエラーコードは consent_required である.
select_account
Authorization Server は End-User にアカウント選択を促すべきである (SHOULD). この prompt 値は, End-User が Authorization Server 上に複数アカウントを持っているとき, 現在のセッションに紐づくアカウントの中から一つを選択することを可能にする. End-User によるアカウント選択が不可能な場合はエラーを返す (MUST). 典型的なエラーコードは account_selection_required である.
prompt パラメータは Client に対して, End-User のセッションがアクティブであることを確認したり, End-User にリクエストに対する注意を促すことを可能にする. none がその他の値とともに用いられる場合はエラーとなる.
max_age
OPTIONAL. Authentication Age の最大値. End-User が OP によって明示的に認証されてからの経過時間の最大許容値 (秒). もし経過時間がこの値より大きい場合, OP は End-User を明示的に再認証しなければならない (MUST). max_age が指定された場合, 発行される ID Token は auth_time Claim を含まねばならない (MUST).
ui_locales
OPTIONAL. End-User の選好する UI の表示言語および文字種. スペース区切りの BCP47 (Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” September 2009.) [RFC5646] 言語タグ値のリストとして表現され, 順序は選好順となる. 例えば "fr-CA fr en" という値が指定された場合, カナダで用いられるフランス語が第一選好となり, 次いで地域指定のないフランス語, そして英語と続く. 要求されたロケールがサポートされていない場合でも, OpenID Provider はエラーとするべきではない (SHOULD NOT).
claims_locales
OPTIONAL. End-User の選好する Claim の表示言語および文字種. スペース区切りの BCP47 (Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” September 2009.) [RFC5646] 言語タグ値のリストとして表現され, 順序は選好順となる. 要求されたロケールがサポートされていない場合でも, OpenID Provider はエラーとするべきではない (SHOULD NOT).
id_token_hint
OPTIONAL. Authorization Server が以前発行した ID Token. Client が認証した End-User の現在もしくは過去のセッションに関するヒントとして利用される. もしこの ID Token に紐づく End-User が認証済, もしくはこのリクエスト中で認証された場合, Authorization Server はポジティブレスポンスを返す. さもなければ, Authorization Server はエラーを返す (SHOULD). prompt=none を利用する場合は, 可能であれば id_token_hint を指定するべきであり (SHOULD), さもなければ invalid_request を返しても良い (MAY). ただしサーバーはその場合可能な限りサクセスレスポンスを返すこと. id_token_hint 利用時は, ID Token の audience に Authorization Server 自身が含まれている必要はない.
login_hint
OPTIONAL. Authorization Server に対する End-User ログイン識別子のヒントとして利用される. RP が End-User に Email アドレス (もしくはその他の識別子) を要求し, それを Authorization Server にヒントとして送信することでヒントとする. Discovery に利用された値をヒントの値として利用することを推奨する (RECOMMENDED). この値は phone_number Claim に指定されるフォーマットに従った電話番号でもよい (MAY). このパラメータを利用するか否かは OP の判断にゆだねる.
acr_values
OPTIONAL. Authentication Context Class Reference リクエスト値. Authorization Server が認証リクエストを処理する際に要求される acr の値をスペース区切りで示した文字列. 認証処理が満たした Authentication Context Class は, Section 2.2 (ID Token) に示す acr Claim Value として返される. acr Claim はこのパラメータを用いることで Voluntary Claim としてリクエストされることになる.



 TOC 

2.1.2.  Client Sends Request to Authorization Server

Client は Authorization Endpoint に HTTPS で Authentication Request を送信する.

以下の例では Client が User Agent に HTTP 302 リダイレクトレスポンスを返し, User Agent に対して Authorization Endpoint に Authentication Request を送るよう指示している. (改行は掲載上の都合による)

  HTTP/1.1 302 Found
  Location: https://server.example.com/authorize?
    response_type=code
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj

User Agent は上記の Client からの HTTP 302 リダイレクトレスポンスに従い, Authorization Server に以下のようなリクエストを送る. (改行は掲載上の都合による)

  GET /authorize?
    response_type=code
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj HTTP/1.1
  Host: server.example.com


 TOC 

2.1.3.  Authorization Server Authenticates End-User

Authorization Server は, リクエストパラメータ値に基づき, End-User をログインさせたり既にログイン済みであることを検証する. End-User とのインタラクションが HTTP で行われる場合は, Section 7.1 (TLS Requirements) に基づきTLS を用いること (MUST). 認証手段の詳細については, 本ドキュメントの定めるところではない.



 TOC 

2.1.4.  Authorization Server Obtains End-User Consent/Authorization

Authorization Server は要求された Claim に対する認可結果を得る. 認可取得には, End-User が何に同意をしようとしているのかを明示する同意ダイアログを用いることもあれば, その他の何らかの手段 (事前の管理者による同意等) を用いることもあろう.

openid scope 値は, その OAuth 2.0 リクエストが OpenID Connect リクエストであることを宣言する. その他の scope 値の利用は任意である (OPTIONAL).



 TOC 

2.1.5.  Authorization Server Sends End-User Back to Client

認可結果が得られると, Authorization Server はサクセスレスポンスまたはエラーレスポンスを返す.



 TOC 

2.1.5.1.  End-User Grants Authorization

End-User がアクセス権要求を承認した場合, Authorization Server は code を発行し, OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の Section 4.1.2 に従い, 以下のクエリパラメータを Redirection URI のクエリー部に application/x-www-form-urlencoded フォーマットで付与して Client に渡す.

code
REQUIRED. OAuth 2.0 Authorization Code.
state
OAuth 2.0 state 値. Authorization Request に state パラメータが含まれていた場合は必須 (REQUIRED). Clients は state 値が Authorization Request に含めた値と同一であることを検証しなければならない (MUST).

以下に例を示す. (改行は掲載上の都合による)

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    code=SplxlOBeZQQYbYS6WxSbIA
    &state=af0ifjsldkj


 TOC 

2.1.5.2.  End-User Denies Authorization or Invalid Request

End-User が認可を拒否したり, End-User の認証に失敗した場合, Authorization Server は OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] Section 4.1.2.1 に従ってエラーの Authorization Response を返さなければならない (MUST). (RFC 6749 に関係のないエラーは, 適切な HTTP ステータスコードを用いて User Agent に返すこと)



 TOC 

2.1.6.  Client Obtains ID Token and Access Token

次に Client は, 以下のように Token Endpoint に対して Authorization Code を付与した形で Access Token Request を送る.



 TOC 

2.1.6.1.  Client Sends Code

Client は OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の Section 4.1.3 にあるように, Token Endpoint に対して Form Serialization (Section 3.2 (Form Serialization)) を用いてリクエストを送る. ここで Client は OAuth 2.0 の Section 2.3.1 に従い, 自身の Client Credentials を HTTP Basic 方式で Authorization ヘッダーに付与して認証を行う. (この方法は OpenID Connect Discovery 1.0 (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” August 2015.) [OpenID.Discovery] において client_secret_basic と呼ばれているものである)

Token Endpoint との通信は TLS を用いること (MUST). TLS の利用についての詳細は Section 7.1 (TLS Requirements) を参照.

以下は Token Request の例である. (改行は掲載上の都合による)

  POST /token HTTP/1.1
  Host: server.example.com
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
  Content-Type: application/x-www-form-urlencoded

  grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb


 TOC 

2.1.6.2.  Client Receives Tokens

Client は OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] Section 4.1.4 にあるように, 以下のパラメーターをレスポンスとして受け取る. レスポンスは UTF-8 エンコード [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.) とすること (SHOULD).

access_token
REQUIRED. UserInfo Endpoint にアクセスするための Access Token.
token_type
REQUIRED. OAuth 2.0 Token Type 値. この値は Clients が OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] に従い Bearer とすること (MUST).
id_token
REQUIRED. ID Token.
expires_in
OPTIONAL. Access Token が生成されてから期限切れになるまでの秒数.
refresh_token
OPTIONAL. Refresh Token.

次に Client は Access Token を使って Resource Server 上の保護リソースにアクセスする.

以下に例を示す. (改行は掲載上の都合による)

  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-cache, no-store
  Pragma: no-cache

  {
   "access_token":"SlAV32hkKG",
   "token_type":"Bearer",
   "expires_in":3600,
   "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
   "id_token":"eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso"
  }


 TOC 

2.2.  ID Token

ID Token は, ある Client を利用するというコンテキスト中での, Authorization Server による End-User 認証に関する Claim を含んだセキュリティトークンである. 潜在的にはその他の Cliam を含む可能性もある. ID Token は JSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.) [JWT] である.

ID Token には以下の Cliam が含まれる.

iss
REQUIRED. レスポンスを返した Issuer の Issuer Identifier. iss 値は, https スキーマで始まる大文字小文字を区別する URL であり, スキーマ, ホスト, そして任意でポート番号とパスを含む. クエリーとフラグメントは含まない.
sub
REQUIRED. Subject Identifier. Client に利用される前提で, Issuer のローカルでユニークであり再利用されない End-User の識別子. (例: 24400320AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4 等) この値は ASCII で255文字を超えてはならない (MUST NOT). sub 値は大文字小文字を区別する.
aud
REQUIRED. ID Token の想定されるオーディエンス (Audience). この値は Relying Party の OAuth 2.0 client_id を含まなければならない (MUST). 他のオーディエンスの識別子を含んでもよい (MAY). 一般的には aud は大文字小文字を区別した文字列の配列であるが, オーディエンスが単体の場合は aud 値を大文字小文字を区別した単一文字列としてもよい (MAY).
exp
REQUIRED. ID Token の有効期限. この有効期限以降に該当 ID Token を受け入れたり処理してはならない (MUST NOT). ある ID Token が有効期限内であるためには, この値が示す時刻より現在時刻が前でなければならない (MUST). 実装者は, 通常数分以内で, 時計のズレを考慮して多少の猶予期間を設けてもよい (MAY). この値は UTC 1970-01-01T00:00:00Z から該当時刻までの秒数を示す JSON [RFC7159] (Bray, T., Ed., “The JavaScript Object Notation (JSON) Data Interchange Format,” March 2014.) 数値である. 詳細は RFC 3339 (Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.) [RFC3339] を参照のこと.
iat
REQUIRED. JWT 発行時刻. この値は UTC 1970-01-01T00:00:00Z から該当時刻までの秒数を示す JSON 数値である.
auth_time
End-User の認証が発生した時刻. この値は UTC 1970-01-01T00:00:00Z から該当時刻までの秒数を示す JSON 数値である. リクエストに max_age が含まれていた場合, この Cliam は必須である (REQUIRED). その他の場合は任意 (OPTIONAL).
nonce
OPTIONAL. Client セッションと ID Token を紐づける文字列値. リプレイアタック防止のために用いられる. Authentication Request で指定されたままの値を ID Token に含める. Client は Authentication Request に含めた nonce 値が ID Token に含まれる nonce Claim Value と一致することを検証しなければならない (MUST). Authentication Request に nonce が含まれていた場合, Authorization Server は ID Token にそのままの値で nonce Claim を含めねばならない (MUST). nonce は大文字小文字を区別する文字列である.
at_hash
OPTIONAL. Access Token のハッシュ値. ID Token が Token Endpoint から発行される場合には, 任意 (OPTIONAL) であるが, その場合にも at_hash Claim を含めてもよい (MAY). この値は, access_token の ASCII オクテット列のハッシュ値の左半分を Basd64URL エンコードしたものであり, ハッシュアルゴリズムは ID Token の JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [JWS] ヘッダーにある alg で用いられるハッシュアルゴリズムと同じものを用いる. 例えば algRS256 であれば, access_token の SHA-256 ハッシュ値を計算し, その左半分の128ビットを Base64URL エンコードする. at_hash は大文字小文字を区別する文字列である.
acr
OPTIONAL. Authentication Context Class Reference. 実施された認証処理が満たす Authentication Context Class を表す Authentication Context Class Reference 値を示す文字列. "0" という値は End-User 認証が ISO/IEC 29115 (International Organization for Standardization, “ISO/IEC 29115:2013 -- Information technology - Security techniques - Entity authentication assurance framework,” March 2013.) [ISO29115] の定める level 1 を満たさないことを意味する. 長期間有効なブラウザクッキーを用いた認証などが, "level 0" の例として挙げられる. 金銭にかかわるリソースへのアクセス認可要求時には, level 0 の認証を受け入れるべきではない (SHOULD NOT). acr 値には, 絶対 URL か RFC 6711 (Johansson, L., “An IANA Registry for Level of Assurance (LoA) Profiles,” August 2012.) [RFC6711] に登録された値を用いるべきである (SHOULD). RFC 6711 (Johansson, L., “An IANA Registry for Level of Assurance (LoA) Profiles,” August 2012.) [RFC6711] 登録済の値を用いる場合, RFC 6711 (Johansson, L., “An IANA Registry for Level of Assurance (LoA) Profiles,” August 2012.) [RFC6711] と異なる意味でそれを用いてはならない (MUST NOT). この値の意味するところはコンテキストによって異なる可能性があるため, この Claim を利用する場合は, 関係者間で値の意味するところについて合意しておくこと. acr は大文字小文字を区別する文字列である.
amr
OPTIONAL. Authentication Methods References. 認証時に用いられた認証方式を示す識別子文字列の JSON 配列. 例として, パスワードと OTP 認証が両方行われたことを示すといったケースが考えられる. amr Claim にどのような値を用いるかは本ドキュメントの定めるところではない. この値の意味するところはコンテキストによって異なる可能性があるため, この Claim を利用する場合は, 関係者間で値の意味するところについて合意しておくこと. amr は大文字小文字を区別する文字列である.
azp
OPTIONAL. ID Token 発行対象である認可された関係者 (authorized party). この Claim が存在する場合, その値は受け取り手の OAuth 2.0 Client ID でなければならない. この Claim は, ID Token のオーディエンス値が単一文字列であり, かつその値が azp の値と異なる場合にのみ必要となる. オーディエンスと azp 値が同値である場合にも, この Claim を含んでもよい (MAY). azp は大文字小文字を区別する文字列である.

ID Token はその他の Claim を含んでもよい (MAY). 解釈不可能な Claim は全て無視すること (MUST).

ID Token は JWS および JWE の x5u, x5c, jku, jwk ヘッダーフィールドを含むべきではない (SHOULD NOT). これらの代わりに事前の Discovery および Registration において, ID Token に用いる鍵を得ること.

以下は Base64URL デコードされた ID Token ペイロードに含まれる Claim (the JWT Claims Set) の例である.

  {
   "iss": "https://server.example.com",
   "sub": "24400320",
   "aud": "s6BhdRkqt3",
   "exp": 1311281970,
   "iat": 1311280970
  }


 TOC 

2.2.1.  ID Token Validation

本ドキュメントの定めるバリデーションが1つでも失敗した場合, バリデーションが失敗した情報を必要とする処理を全て中止し (MUST), バリデーションが失敗した情報を利用してはならない (MUST NOT).

Client は Token Response に含まれる ID Token をバリデートしなければならない (MUST). ID Token のバリデーションの為に, Client は ID Token をピリオド (".") で分割し, 2番目のセグメントを Base64URL デコードして ID Token Claim を含む JSON オブジェクトを取得する. この JSON オブジェクトのバリデーションは以下の通りとする (MUST).

  1. OpenID Provider の Issuer Identifier (これは通常 Discovery によって得られる) が iss (issuer) Claim と一致しなければならない (MUST).
  2. aud Claim が, iss Claim に紐づく Issuer に登録されている Client 自身の client_id を含まなければならない (MUST). ID Token のオーディエンスに Client が含まれていなかったり, Client にとって信頼できない主体がオーディエンスに含まれている場合, その ID Token を拒絶しなければならない (MUST).
  3. ID Token が複数のオーディエンスを含む場合, Client は azp Claim が存在することを検証すべきである (SHOULD).
  4. azp Claim が存在する場合, Client はそれが自身の client_id と一致することを検証すべきである (SHOULD).
  5. 現在時刻が exp Claim より前でなければならない (MUST). (時計のズレを考慮した多少の猶予は許容される)
  6. iat Claim が現在時刻からあまりにかけ離れている場合は, そのトークンを拒絶してもよい. これにより nonce の保存期間を制限することができる. 適切な閾値は, Client ごとにことなる.
  7. acr Claim がリクエストに含まれていた場合, Client は ID Token の acr Claim が適切かどうか検証すべきである (SHOULD). acr Claim Value とその意味は, 本ドキュメントの定めるところではない.
  8. max_age Claim がリクエストに含まれていた場合, Client は ID Token の auth_time Claim をチェックし, 最後の End-User 認証からあまりに時間が経過している場合には再認証を要求すべきである (SHOULD).



 TOC 

2.3.  UserInfo Endpoint

UserInfo Endpoint は, 認証された End-User に関する Claim を返す OAuth 2.0 Protected Resource である. UserInfo Endpoint は https スキーマの URL であり, ポート番号, パス, クエリーを含むことができる (MAY). Claim は JSON オブジェクトとして返される.

UserInfo Endpoint にアクセスする際には TLS は必須である (MUST). TLS 利用についての詳細は Section 7.1 (TLS Requirements) 参照.



 TOC 

2.3.1.  UserInfo Request

Client は, OpenID Connect Authentication で得られた Access Token を使って, UserInfo Endpoint に End-User の Claim をリクエストする. UserInfo Endpoint は OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] に従った OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] Protected Resource である. このリクエストは HTTP GET で行われるべきであり (SHOULD), Access Token は Authorization ヘッダー経由で渡されるべきである (SHOULD).

以下に UserInfo Request の例を示す.

  GET /userinfo HTTP/1.1
  Host: server.example.com
  Authorization: Bearer SlAV32hkKG


 TOC 

2.3.2.  Successful UserInfo Response

UserInfo Claim は JSON オブジェクトのメンバーとして返される (MUST). レスポンスボディは UTF-8 エンコードされる (SHOULD). Section 2.5 (Standard Claims) に定義されている Claim に加え, そこに明記されていない Claim も返却可能である.

Claim が返されない場合, Claim Name は JSON オブジェクトから除かれるべきであり (SHOULD), 値を null や空文字列にした状態で該当 Claim を含めるべきではない (SHOULD NOT).

UserInfo Response には, 必ず sub Claim を含むこと (MUST).

注) トークン置換攻撃を考慮すると, UserInfo Response が必ずしも ID Token の sub Claim が示す End-User のものであるとは保証できない. そのため UserInfo Response に含まれる sub Claim が ID Token のそれと一致することを検証しなければならない (MUST). もし2つが一致しない場合, UserInfo Response を利用してはならない (MUST NOT).

Client はレスポンスを返した OP が意図した通りの OP であることを, RFC 6125 (Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March 2011.) [RFC6125] に従い TLS サーバー証明書チェックを通じて検証しなければならない (MUST).



 TOC 

2.3.3.  UserInfo Error Response

もし何らかのエラーが起こった場合, UserInfo Endpoint は OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] SEction 3 に示す Error Response を返す.



 TOC 

2.4.  Scope Values

OpenID Connect Client は OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] Section 3.3 に従い, Access Token に要求されるアクセス権限を scope 値を通じて指定する. Access Tokens に紐づく scope は, そのトークンを使って OAuth 2.0 で保護されたエンドポイントにアクセスした際にどのようなリソースが得られるかを規定する. OpenID Connect では, scope は Claim Value として取得可能な情報セットを指定する為に利用できる. 本ドキュメントでは OpenID Connect で用いられる scope についてのみ述べる.

OpenID Connect は, ここで述べる scope 値以外の値を定義および利用することを制限しない. また実装が理解できない scope 値は無視されるべきである (SHOULD).

Authorization Server は, 以下の scope によって要求される Claim を Voluntary Claim として扱う.

OpenID Connect は以下の scope 値を定義する.

openid
REQUIRED. Client が Authorization Server に OpenID Connect リクエストを投げていることを示す. openid scope 値が存在しない場合の挙動は定義しない.
profile
OPTIONAL. この scope 値は, 以下に示す End-User のデフォルトプロフィール Claim へのアクセス要求に用いる. name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, and updated_at.
email
OPTIONAL. email および email_verified Claim へのアクセス要求に用いる.
address
OPTIONAL. address Claim へのアクセス要求に用いる.
phone
OPTIONAL. phone_number および phone_number_verified Claim へのアクセス要求に用いる.
offline_access
OPTIONAL. OAuth 2.0 Refresh Token 発行要求に用いる. Refresh Token は End-User とのインタラクションを介さずに UserInfo Endpoint にアクセスするための Access Token を発行する為に用いる.

複数の scope 値は, スペース区切りの大文字小文字を区別した ASCII scope 値のリストによって指定することができる (MAY).

profile, email, address, および phone scope 値により要求される Claim は, Section 2.3.2 (Successful UserInfo Response) にある通り UserInfo Endpoint から返される.

End-User が OpenID Provider に対して RP に要求された情報の一部もしくは全ての提供を拒否することもある. End-User に要求する情報を最小化するために, RP は UserInfo Endpoint で提供される情報の一部のみをリクエストすることもできる.

以下に scope リクエスト例を示す.

  scope=openid profile email phone


 TOC 

2.5.  Standard Claims

OpenID Connect では以下に示す標準 Claim セットを定義する. これらは UserInfo Response として返される.



MemberTypeDescription
sub string Subject - Issuer における End-User の識別子.
name string End-User の表示用フルネーム. 肩書きや称号 (suffix) 等が含まれることもある. 氏名等の表示順は End-User の locale や選好に従う.
given_name string End-User の名 (given name / first name). 複数の given name を持つ文化圏もあることに注意. 全ての given name が含まれる可能性があり, その場合はスペース区切りで表記される.
family_name string End-User の姓 (surname / last name). 複数の family name を持つ文化圏や family name を持たない文化圏もあることに注意. 全ての family name が含まれる可能性があり, その場合はスペース区切りで表記される.
middle_name string End-User の middle name. 複数の middle name を持つ文化圏もあることに注意. 全ての middle name が含まれる可能性があり, その場合はスペース区切りで表記される. また middle name を使用しない文化圏もある.
nickname string End-User のニックネーム. これは given_name と同じこともあれば異なることもある. 例えば, nicknameMike, given_nameMichael として返されることがある.
preferred_username string janedoej.doe といった, End-User の選好する簡略名. これは @/ や空白文字といった特殊文字を含むあらゆる valid な JSON 文字列でありうる (MAY). Section 2.5.3 (Claim Stability and Uniqueness) にあるように, RP は この値がユニークであるという前提で扱ってはならない (MUST NOT).
profile string End-User のプロフィールページの URL. この Web ページに掲載されるコンテンツはこの End-User に関するものであろう (SHOULD).
picture string End-User のプロフィール画像の URL. この URL は画像ファイル (PNG, JPEG, GIF 画像ファイル等) を参照すること (MUST). またこの画像は End-User が撮影した任意の写真ではなく, End-User に言及する際に適切な画像とするべきである (SHOULD).
website string End-User の Web ページやブログの URL. この Web ページは End-User 自身や End-User が所属する組織が発信する情報を含むべきである (SHOULD).
email string End-User の選好する Email アドレス. RFC 5322 (Resnick, P., Ed., “Internet Message Format,” October 2008.) [RFC5322] の addr-spec シンタックスに従うこと. Section 2.5.3 (Claim Stability and Uniqueness) にあるように, RP は この値がユニークであるという前提で扱ってはならない (MUST NOT).
email_verified boolean End-User の Email アドレスが検証済であれば true, さもなければ false. Claim Value が true の場合, これは OP が検証を行った時点において該当 Email アドレスが End-User のコントロール下にあるという確認処理を行ったことを示す. Email アドレスの検証の詳細についてはコンテキストに依存し, 関係者間でのトラストフレームワークや契約上の同意事項等などによって異なる.
gender string End-User の性別. 本ドキュメントでは female, male を定義する. 定義済の値に適切なものがない場合, その他の値を利用してもよい (MAY).
birthdate string End-User の誕生日. ISO 8601:2004 (International Organization for Standardization, “ISO 8601:2004. Data elements and interchange formats - Information interchange - Representation of dates and times,” 2004.) [ISO8601‑2004] YYYY-MM-DD 形式で表現される. 生年を 0000 とすることで生年を省略することもできる (MAY). 生年のみを提示する場合は YYYY 形式としても良い. プラットフォームの日付関連の関数の実装によって, 生年のみを提供した場合の月日の扱いは様々であるため, 実装者はこの点を考慮にいれて日付を処理すべきである.
zoneinfo string End-User のタイムゾーンを示す [zoneinfo] (Public Domain, “The tz database,” June 2011.) に登録された文字列. (Europe/Paris, America/Los_Angeles 等)
locale string End-User の locale. BCP47 (Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” September 2009.) [RFC5646] 言語タグ表現. これは通常 ISO 639-1 Alpha-2 (International Organization for Standardization, “ISO 639-1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code,” 2002.) [ISO639‑1] 言語コードを小文字表記, ISO 3166-1 Alpha-2 (International Organization for Standardization, “ISO 3166-1:1997. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes,” 1997.) [ISO3166‑1] 国コードを大文字表記し, ダッシュでつなげたものである. (en-US, fr-CA 等) 実装によってはダッシュの代わりにアンダースコアを区切り文字に用いる場合もあるため, 互換性の観点からは注意すること. (en_US 等) Relying Party はダッシュ区切りに加えてアンダースコア区切りのシンタックスを受け入れてもよい (MAY).
phone_number string End-User の選好する電話番号. この Claim のフォーマットとしては E.164 (International Telecommunication Union, “E.164: The international public telecommunication numbering plan,” 2010.) [E.164] を推奨する (RECOMMENDED). (+1 (425) 555-1212, +56 (2) 687 2400 等) 電話番号が拡張を含む場合, その拡張は RFC 3966 (Schulzrinne, H., “The tel URI for Telephone Numbers,” December 2004.) [RFC3966] 拡張シンタックスで表記することを推奨する (RECOMMENDED). (+1 (604) 555-1234;ext=5678 等)
phone_number_verified boolean End-User の電話番号が検証済であれば ture, さもなければ false. Claim Value が true の場合, これは OP が検証を行った時点において該当電話番号が End-User のコントロール下にあるという確認処理を行ったことを示す. 電話番号の検証の詳細についてはコンテキストに依存し, 関係者間でのトラストフレームワークや契約上の同意事項等などによって異なる. また true の場合, phone_number Claim は E.164 形式でなければならず (MUST), すべての拡張は RFC 3966 形式でなければならない (MUST).
address JSON object End-User の選好する郵送先住所. address メンバーは Section 2.5.1 (Address Claim) に定義されたメンバーを含む JSON [RFC4627] (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) 構造である.
updated_at number End-User に関する情報の最終更新日時. この値は UTC 1970-01-01T00:00:00Z から該当時刻までの秒数を示す JSON 数値である.

 Table 1: Reserved Member Definitions 

以下に例を示す.

  {
   "sub": "248289761001",
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "preferred_username": "j.doe",
   "email": "janedoe@example.com",
   "picture": "http://example.com/janedoe/me.jpg"
  }

Registration [OpenID.Registration] (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” August 2015.) において特に他フォーマットを指定されない限り, UserInfo Endpoint では Claim を JSON 形式で返し (MUST), Content-Type ヘッダーを用いてフォーマットを示すこと (MUST). 以下に許可されたコンテンツタイプを示す.

Content-TypeFormat Returned
application/json plain text JSON object
application/jwt JSON Web Token (JWT)



 TOC 

2.5.1.  Address Claim

Address Claim は物理的な郵送先住所である. End-User の登録済情報とプライバシー設定に基づいて, address の一部のみを返却することもある (MAY). 例えば countryregion を返し, それ以外の詳細なアドレス情報を省略するなどが考えられる.

住所全体を整形済サブフィールドに1文字列として入れてもよいし (MAY), 他のサブフィールドに個別の要素として各住所要素を指定するだけでもよいし (MAY), 両方を含めてもよい (MAY). もし両方を含める場合, 整形済住所は住所の各要素の連結方法を示すものとし, 両方が同じアドレスを示すこと (SHOULD).

formatted
Full mailing address, formatted for display or use on a mailing label. This field MAY contain multiple lines, separated by newlines. Newlines can be represented either as a carriage return/line feed pair ("\r\n") or as a single line feed character ("\n").
street_address
Full street address component, which MAY include house number, street name, Post Office Box, and multi-line extended street address information. This field MAY contain multiple lines, separated by newlines. Newlines can be represented either as a carriage return/line feed pair ("\r\n") or as a single line feed character ("\n").
locality
City or locality component.
region
State, province, prefecture, or region component.
postal_code
Zip code or postal code component.
country
Country name component.



 TOC 

2.5.2.  Claims Languages and Scripts

Human-readable な Claim Value およびそれらへの参照は, 複数言語および複数文字種で表現することができる (MAY). 言語および文字種の指定には BCP47 (Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” September 2009.) [RFC5646] 言語タグを # を区切り文字としてメンバー名に付与する. 例えば family_name#ja-Kana-JP は日本語のカタカナ表記の Family Name を示す. カタカナ表記の氏名は, 漢字表記 (family_name#ja-Hani-JP) の氏名の発音を示したりインデックス目的等で用いられることが多い. 他にも website が言語指定のない Web サイト, website#de がドイツ語の Web サイトを参照していることを示すといった例も挙げられる.

Claim Name は大文字小文字を区別するため, Claim Name 内の言語タグは IANA "Language Subtag Registry" [IANA.Language] (IANA, “Language Subtag Registry,” .) に登録されたままの表記とすることを強く推奨する (RECOMMENDED). 一般的に言語名は小文字, 地域名は大文字, 文字種は大文字小文字混合で表記されることが多い. しかしながら BCP47 言語タグ値は大文字小文字を区別しないため, 実装は言語タグを大文字小文字区別なく処理できるべきである (SHOULD).

BCP47 で推奨されるように, Claim の言語タグ値は必要な時にのみ指定すべきである (SHOULD). 例えばほとんどの場合 fr-CAfr-FR でなく fr で十分である. 可能であれば OP は要求された Claim locale と自身が持つ Claim のマッチングを試みるべきである (SHOULD). 例えば Client が de (ドイツ語) の Claim を要求してきており, OP が de-CH (スイスのドイツ語) 表記の Claim は持つが地域指定無しの一般的ドイツ語表記の Claim を持たない場合, OP はスイスのドイツ語の値を返すのが適切である. (Client をできるかぎりシンプルに保つため, ここでは言語タグのマッチングが内包する複雑性をわざと OP に寄せている)

リクエスト中の claims_locales を使って, 返却される Claim の好ましい言語および文字種を指定することができる.

OP が claims_locales やその他の手段により End-User と Client が単一言語および文字種表記の Claim を要求していると特定した場合, 該当言語および文字種表記の Claim を返却する際には言語タグを付けずに返すことを推奨する (RECOMMENDED). また Client は言語タグ付きの Claim を処理可能なよう実装することを推奨する (RECOMMENDED).



 TOC 

2.5.3.  Claim Stability and Uniqueness

sub (subject) と iss (issuer) Claim のペアは, RP が End-User の不変な識別子として信頼できる唯一の Claim である. Section 2.2 (ID Token) で述べたように, sub は Issuer が End-User に割り振るローカルでユニークかつ再利用されない識別子でなければならない (MUST). 以上のことから, iss Claim と sub Claim のペアが, 唯一の保証された End-User の識別子となる.

その他の Claim に関しては, 時間経過や複数ユーザー間での不変性等は保証されず, Issuer は独自の制約やポリシーを適用してよい. 例えば Issuer は時系列上の異なるポイントにおいて, 同一の email Claim Value を異なるユーザーのために再利用してもよい (MAY). よって email アドレスは時間経過によって異なる End-User に紐づく可能性がある (MAY). 以上のことより, email, phone_number, preferred_username などの Claim を End-User のユニークな識別子として利用してはならない (MUST NOT).



 TOC 

3.  Serializations

リクエストメッセージは以下のいずれかの方法でシリアライズできる (MAY).

  1. Query String Serialization
  2. Form Serialization



 TOC 

3.1.  Query String Serialization

Query String Serialization を使ってパラメータをシリアライズするためには, Client は [W3C.REC‑html401‑19991224] (Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.) で定義された application/x-www-form-urlencoded フォーマットを使いパラメータと値をクエリコンポーネントへ追加することで文字列を構成する. Query String Serialization は一般的に HTTP GET リクエストで使用される.

以下はシリアライズの参考例である. (改行は掲載上の都合による)

  GET /authorize?scope=openid
    &response_type=code
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
  Host: server.example.com


 TOC 

3.2.  Form Serialization

パラメータやその値は, HTTP リクエストのエンティティボディに [W3C.REC‑html401‑19991224] (Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.) に定義されているように application/x-www-form-urlencoded フォーマットでパラメータ名とその値を追加することで Form Serialize される. Form Serialization は一般的には HTTP POST リクエストで利用される.

以下はシリアライズの参考例である. (改行は掲載上の都合による)

  POST /authorize HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded

  scope=openid
    &response_type=code
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb


 TOC 

4.  String Operations

いくつかの OpenID Connect メッセージを処理する際にはメッセージの中の値を既知の値を比較することが求められる. 例えば, UserInfo エンドポイントから返された Claim Name は sub などの特定の Claim Name と比較される. よって Unicode [UNICODE] (The Unicode Consortium, “The Unicode Standard,” .) 文字列比較処理はセキュリティ上重要な意味を持つ.

したがって, JSON 文字列を他の Unicode 文字列と比較する際は下記の通り実施しなければならない (MUST).

  1. JSON に適用されたすべてのエスケープ処理を取り除き Unicode コードポイントの配列を生成する.
  2. Unicode Normalization [USA15] (Davis, M. and K. Whistler, “Unicode Normalization Forms,” 06 2015.) を JSON 文字列, もしくは比較対象文字列に対していかなる時点であっても適用してはならない (MUST NOT).
  3. 二つの文字列の比較は, Unicode コードポイント同士の等値比較として実施されなければならない (MUST).

いくつかの箇所において, 本ドキュメントはスペースで区切られた文字列のリストを使用している. そのようないかなる場合においても, この目的では ASCII のスペース文字 (0x20) のみを使用しなければならない (MUST).



 TOC 

5.  TLS Version

本ドキュメントでは Transport Layer Security (TLS) が用いられるが, 実際に広く使われている実装や既知のセキュリティ脆弱性に依存して, TLS の適切なバージョンはその時々で異なりうる. 本ドキュメント執筆時には, TLS バージョン 1.2 [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) が最新であるが, 実装が限定されており, すぐに各実装で利用可能とはいえないかもしれない. TLS バージョン 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) は現在もっとも広く利用されているバージョンで, 最も広範な相互運用性を提供するであろう.



 TOC 

6.  Implementation Considerations

本ドキュメント書では Relying Party が, OAuth Authorization Code Flow で利用する機能を定義する. Relying Parties は本ドキュメント書内で "REQUIRED" であると記載されている, もしくは "MUST" 付きで説明されている機能を実装しなければならない (MUST).



 TOC 

6.1.  Discovery and Registration

OpenID Connect 環境によっては, あらかじめ設定された OpenID Provider や Relying Party を利用することができる. その場合, アイデンティティ情報やサービス情報の Discovery や Client の Dynamic Registration をサポートする必要はないかもしれない.

しかしながら, 事前の信頼構築を前提とせず, Relying Party と OpenID Provider の間での事前予測不可能な形でのインタラクションをサポートする場合には, OpenID Connect Discovery 1.0 (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” August 2015.) [OpenID.Discovery] と OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” August 2015.) [OpenID.Registration] によってこれを実現すべきである (SHOULD).



 TOC 

7.  Security Considerations

以下に挙げたもの以外のセキュリティ上の考慮点については, OpenID Connect Core 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” August 2015.) [OpenID.Core] 仕様を参照すること.



 TOC 

7.1.  TLS Requirements

実装する際は TLS をサポートしなくてはならない (MUST). どのバージョンを実装するかは時期によって異なり, 実装時に広く使われているかと既知のセキュリティ上の脆弱性に依存する. 本ドキュメントを執筆している段階では TLS バージョン 1.2 [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) が最新バージョンであるが, 実際に使われている例は非常に限られており, 実装に利用するツールキットが対応していない可能性もある. TLS version 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) が最も広く使われているバージョンであり, 最も高い相互運用性を提供している.

情報の漏えいや改ざんを防ぐため, TLS を使った機密保護を, 機密性と完全性の保護を提供する暗号スイートを用いて適用しなくてはならない (MUST).

TLS を使用する際は, RFC 6125 (Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March 2011.) [RFC6125] に従い TLS サーバ証明書を検証しなければならない (MUST).



 TOC 

8.  Privacy Considerations



 TOC 

8.1.  Personally Identifiable Information

UserInfo Response は一般的には Personally Identifiable Information (PII) を含む. したがって, 特定の目的のための情報の開示に関する End-User の同意は, 関連する法律に従い, 認可時もしくは認可時に先立って取得されるべきである (SHOULD). 利用目的は一般的には redirect_uris とともに登録される.

必要な UserInfo データだけが Client 側に保管されるべきであり, Client は受信したデータを告知した利用目的と関連づけるべきである (SHOULD).



 TOC 

8.2.  Data Access Monitoring

Resource Server は End-User に対して, 誰が自分のデータにアクセスしたかを監視できよう, 自身の UserInfo へのアクセスログを閲覧可能にべきである (SHOULD).



 TOC 

8.3.  Correlation

Client 間での名寄せの可能性からエンドユーザを保護するため, Pairwise Pseudonymous Identifier (PPID) を sub (subject) として使用することを検討すべきである (SHOULD).



 TOC 

8.4.  Offline Access

オフラインアクセスにより, ユーザが居合せない場合でも Claims にアクセスできるようになるが, これはユーザーが居合わせる場合の Claim アクセスよりも大きなプライバシー上のリスクをもたらす. したがって, リソースへのオフラインアクセスを行う場合には明示的な同意を得ることが賢明である. 本ドキュメントでは, リクエストが各法域 (jurisdiction: 法律用語, ある法律が適用される地域のこと) において処理可能な条件を満たしていることが既知でない場合には, 同意を得るために prompt パラメータを利用することを要求する.

Access Token がフロントチャネルから返って来た時に, トークンが攻撃者にさらされている危険性はおおいにあり, その場合, 攻撃者は後でトークンを使って UserInfo エンドポイントにアクセスできる. Access Token がオフラインアクセスを許可しておらず, Client から送られてきたリクエストがオフラインかオンラインかをサーバが区別することができれば, リスクは十分に軽減できる. したがって本ドキュメントでは, Access Token がフロントチャネルを通して送られてきた場合にはオフラインアクセスのリクエストを無視することを要求する. サーバ側でオンラインとオフラインを区別することは, 特にネイティブクライアントの時は難しいかもしれないことには注意が必要である. サーバ側では試行錯誤が必要になるかもしれない. また, Response Types が code token もしくは token の場合にもフロントチャネルを経由したAccess Tokenのさらされる危険性は同じである. したがって, 実装はどのようなチャネルで Access Token が発行されたかを検知できるよう準備し, トークンがフロントチャネル経由で発行された場合にはオフラインアクセスを拒否するべきである.

これらの規定では prompt パラメータを使って明示的な同意ダイアログを要求するが, ユーザが "accept" ボタンを押したなどの単なる事実では, 有効な同意とみなされないかもしれないことに注意が必要である. 開発者は, 一般的に同意の行為が有効であるためには, 同意項目の影響が End-User によって理解されなければならないこと, 同意は (例えば, 他のオプションが選択可能であるなど) 強制ではなく自由意志でなされなければならないこと, そして同意項目は公正かつ衡平でなければならないことに注意すべきである. 一般的にはサービスは各々の法域で要求されるプライバシー指針に従うこと, そしてリクエストを処理するのに, オンラインのセルフサービスの "explicit consent" は法域によっては有効な同意を形成しないので, 単に明示的な同意以外に依拠することが推奨される.



 TOC 

9.  IANA Considerations

This document makes no requests of IANA.



 TOC 

10.  References



 TOC 

10.1. Normative References

[E.164] International Telecommunication Union, “E.164: The international public telecommunication numbering plan,” 2010.
[IANA.Language] IANA, “Language Subtag Registry.”
[ISO29115] International Organization for Standardization, “ISO/IEC 29115:2013 -- Information technology - Security techniques - Entity authentication assurance framework,” ISO/IEC 29115, March 2013.
[ISO3166-1] International Organization for Standardization, “ISO 3166-1:1997. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes,” 1997.
[ISO639-1] International Organization for Standardization, “ISO 639-1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code,” 2002.
[ISO8601-2004] International Organization for Standardization, “ISO 8601:2004. Data elements and interchange formats - Information interchange - Representation of dates and times,” 2004.
[JWS] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” RFC 7515, DOI 10.17487/RFC7515, May 2015.
[JWT] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” RFC 7519, DOI 10.17487/RFC7519, May 2015.
[OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” August 2015.
[OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” August 2015.
[OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” August 2015.
[RFC20] Cerf, V., “ASCII format for Network Interchange,” STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” RFC 2246, DOI 10.17487/RFC2246, January 1999.
[RFC3339] Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps,” RFC 3339, DOI 10.17487/RFC3339, July 2002.
[RFC3629] Yergeau, F., “UTF-8, a transformation format of ISO 10646,” STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003.
[RFC3966] Schulzrinne, H., “The tel URI for Telephone Numbers,” RFC 3966, DOI 10.17487/RFC3966, December 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005.
[RFC4627] Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” RFC 4627, DOI 10.17487/RFC4627, July 2006.
[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, DOI 10.17487/RFC5246, August 2008.
[RFC5322] Resnick, P., Ed., “Internet Message Format,” RFC 5322, DOI 10.17487/RFC5322, October 2008.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009.
[RFC6125] Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” RFC 6125, DOI 10.17487/RFC6125, March 2011.
[RFC6711] Johansson, L., “An IANA Registry for Level of Assurance (LoA) Profiles,” RFC 6711, DOI 10.17487/RFC6711, August 2012.
[RFC6749] Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” RFC 6749, DOI 10.17487/RFC6749, October 2012.
[RFC6750] Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” RFC 6750, DOI 10.17487/RFC6750, October 2012.
[RFC7159] Bray, T., Ed., “The JavaScript Object Notation (JSON) Data Interchange Format,” RFC 7159, DOI 10.17487/RFC7159, March 2014.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing,” RFC 7230, DOI 10.17487/RFC7230, June 2014.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content,” RFC 7231, DOI 10.17487/RFC7231, June 2014.
[UNICODE] The Unicode Consortium, “The Unicode Standard.”
[USA15] Davis, M. and K. Whistler, “Unicode Normalization Forms,” Unicode Standard Annex 15, 06 2015.
[W3C.REC-html401-19991224] Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 (HTML).
[zoneinfo] Public Domain, “The tz database,” June 2011.


 TOC 

10.2. Informative References

[OpenID.Implicit] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Implicit Client Implementer's Guide 1.0,” July 2015.


 TOC 

10.3. 翻訳プロジェクト

[oidfj] OpenIDファウンデーションジャパン, “OpenIDファウンデーションジャパン.”
[oidfj-github] OpenIDファウンデーションジャパン, “Githubレポジトリー.”
[oidfj-trans] OpenIDファウンデーションジャパン, “翻訳・教育ワーキンググループ.”


 TOC 

Appendix A.  Acknowledgements

The OpenID Community would like to thank the following people for their contributions to this document:

Naveen Agarwal (naa@google.com), Google

Casper Biering (cb@peercraft.com), Peercraft

John Bradley (ve7jtb@ve7jtb.com), Ping Identity

Tim Bray (tbray@textuality.com), Google

Johnny Bufu (jbufu@janrain.com), Janrain

Breno de Medeiros (breno@google.com), Google

Pamela Dingle (pdingle@pingidentity.com), Ping Identity

George Fletcher (george.fletcher@corp.aol.com), AOL

Roland Hedberg (roland.hedberg@adm.umu.se), University of Umea

Ryo Ito (ryo.ito@mixi.co.jp), mixi, Inc.

Edmund Jay (ejay@mgi1.com), Illumila

Michael B. Jones (mbj@microsoft.com), Microsoft

Torsten Lodderstedt (t.lodderstedt@telekom.de), Deutsche Telekom

Nov Matake (nov@matake.jp), Independent

Chuck Mortimore (cmortimore@salesforce.com), Salesforce

Anthony Nadalin (tonynad@microsoft.com), Microsoft

Hideki Nara (hdknr@ic-tact.co.jp), Tact Communications

Axel Nennker (axel.nennker@telekom.de), Deutsche Telekom

David Recordon (dr@fb.com), Facebook

Justin Richer (jricher@mitre.org), MITRE

Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute, Ltd.

Luke Shepard (lshepard@fb.com), Facebook

Andreas Åkre Solberg (andreas.solberg@uninett.no), UNINET

Paul Tarjan (pt@fb.com), Facebook



 TOC 

Appendix B.  Notices

Copyright (c) 2015 The OpenID Foundation.

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.



 TOC 

Appendix C.  Document History

[[ To be removed from the final document ]]

-37

-36

-35

-34

-33

-32

-31

-30

-29

-28

-27

-26

-25

-24

-23

-22

-21

-20

-19

-18

-17

-16

-15

-14

-13

-12

-11

-10

-09

-08

-07

-06

-05

-04

-03

-02

-01



 TOC 

Appendix D.  翻訳者

本ドキュメントの翻訳は, OpenIDファウンデーションジャパン (OpenIDファウンデーションジャパン, “OpenIDファウンデーションジャパン,” .) [oidfj] 翻訳・教育ワーキンググループ (OpenIDファウンデーションジャパン, “翻訳・教育ワーキンググループ,” .) [oidfj‑trans]を主体として, 有志のメンバーによって行われました. 質問や修正依頼などについては, Githubレポジトリー (OpenIDファウンデーションジャパン, “Githubレポジトリー,” .) [oidfj‑github] にご連絡ください.



 TOC 

Authors' Addresses

  Nat Sakimura
  Nomura Research Institute, Ltd.
Email:  n-sakimura@nri.co.jp
URI:  http://nat.sakimura.org/
  
  John Bradley
  Ping Identity
Email:  ve7jtb@ve7jtb.com
URI:  http://www.thread-safe.com/
  
  Michael B. Jones
  Microsoft
Email:  mbj@microsoft.com
URI:  http://self-issued.info/
  
  Breno de Medeiros
  Google
Email:  breno@google.com
URI:  http://stackoverflow.com/users/311376/breno
  
  Chuck Mortimore
  Salesforce
Email:  cmortimore@salesforce.com
URI:  https://twitter.com/cmort