2013年2月18日月曜日

OpenID Connect Basic Client Profile 1.0 - draft 23 日本語私訳

Draft: OpenID Connect Basic Client Profile 1.0 - draft 23
 TOC 
DraftN. Sakimura
 NRI
 J. Bradley
 Ping Identity
 M. Jones
 Microsoft
 B. de Medeiros
 Google
 C. Mortimore
 Salesforce
 January 22, 2013


OpenID Connect Basic Client Profile 1.0 - draft 23

Abstract

OpenID Connect 1.0は、OAuth 2.0上に作られたシンプルなアイデンティティ層である。そして、相互運用可能でRESTfulな方法により、エンドユーザに関する基本的なプロファイル情報の取得と同様に、認可サーバによる認証に基づくエンドユーザのアイデンティティの検証も、クライアントに対し可能とする。

OpenID Connect Basic Clinet Profile 1.0は、OpenID Connect Standard 1.0仕様の一プロファイ ルであり、OAuth認可コードグラントタイプを用いた基本的なウェブベースのリライイングパーティについて、理解と実装を容易にすることを狙いとしている。 OpenIDプロバイダに関しては、Standard仕様を参照すること。当プロファイルはOpenIDプロバイダの実装とセキュリティに関する考慮事項については除外している。


Table of Contents

1.  はじめに
    1.1.  要求記法および規則
    1.2.  用語
2.   プロトコルフロー
    2.1.  OpenID Connect Scope値
    2.2.  コードフロー
        2.2.1.  クライアントによる認可要求の準備
        2.2.2.  クライアントによる認可サーバへの要求の送信
        2.2.3.  認可サーバによるエンドユーザの認証
        2.2.4.   認可サーバは、エンドユーザの同意／承認を取得する。
        2.2.5.  認可サーバによるエンドユーザのクライアントへの返却
            2.2.5.1.  エンドユーザによる認可の許可
            2.2.5.2.  エンドユーザによる認可の拒否または無効な要求
        2.2.6.  クライアントによるIDトークンとアクセストークンの取得
            2.2.6.1.  クライアントによるコードの送信
            2.2.6.2.  クライアントによるトークンの受信
    2.3.  IDトークン
        2.3.1.  IDトークンの検証
    2.4.  ユーザ情報エンドポイント
        2.4.1.  ユーザ情報要求
        2.4.2.  ユーザ情報応答
            2.4.2.1.  住所クレーム
            2.4.2.2.  クレームの不変性と一意性
        2.4.3.  ユーザ情報エラー応答
3.  シリアライゼーション
    3.1.  クエリストリングシリアライゼーション
    3.2.  フォームシリアライゼーション
4.  文字列操作
5.   実装に関する考慮事項
    5.1.  ディスカバリと登録
6.  セキュリティに関する考慮事項
7.   プライバシーに関する考慮事項
8.  IANAに関する考慮事項
9.  文献
    9.1.  規定文献
    9.2.  参考文献
Appendix A.  謝辞
Appendix B.  通知
Appendix C.  文書履歴
§  著者のアドレス



 TOC 

1. はじめに

OpenID Connect Basic Clinet Profileは、OpenID Connect Standard 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” January 2013.) [OpenID.Standard] 仕様 の一プロファイルであり、OAuth認可コードグラントタイプを用いた基本的なウェブベースのリライイングパーティについて、理解と実装が容易になるよう作成されている。 OAuthインプリシットグラントタイプを用いた基本的なウェブベースのリライイングパーティのためのプロファイルについては、OpenID Connect Implicit Client Profile 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Implicit Client Profile 1.0,” January 2013.) [OpenID.Implicit] 仕様を参照すること。OpenIDプロバ イダおよび非ウェブベースのアプリケーションについてはStandard仕様を参照すること。 当プロファイルはOpenIDプロバイダの実装とセキュリティに関する考慮事項については除外している。


 TOC 

1.1. 要求記法および規則

本文書で用いられる各キーワード「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.) で述べられている通りに解釈されるべきものである。

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


 TOC 

1.2. 用語

当仕様は、OAuth 2.0 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749]で定義されている、「アクセストークン」、「リフレッシュトークン」、「認可コード」、「認可グラント」、「認可サーバ」、「認可エンドポイント」、「クライアント」、「クライアント識別子」、「クライアントシークレット」、「保護リソース」、「リソース所有者」、「リソースサーバ」、「トークンエンドポイント」という用語を用いる。また当仕様では、以下の用語についても定義する。

リライイングパーティ (Relying Party (RP))
OpenIDプロバイダからクレームを要求するアプリケーション
OpenIDプロバイダ (OpenID Provider (OP))
リライイングパーティに対し、クレームを提供する能力を持つサービス。
クレーム (Claim)
クレームプロバイダが、あるエンティティについて主張する、そのエンティティに関する情報の一部
クレームプロバイダ (Claims Provider)
エンティティに関するクレームを返すことが可能なサーバ
エンドユーザ (End-User)
リソースオーナーである人
エンティティ (Entity)
独立した別個の存在を持ち、あるコンテキストの中で識別することが可能な何か。エンドユーザはエンティティの一例である。
個人識別情報 (Personally Identifiable Information (PII))
(a) その情報に関連する自然人を識別するのに用いられる情報。(b)その情報に関連する自然人に直接的・間接的に関連付けられているかもしれない情報。
仮名識別子 (Pairwise Pseudonymous Identifier (PPID))
他のリライイングパーティにおけるエンティティのPPIDとは関連付けることができない、一つのリライイングパーティに対して用いられるエンティティを識別する識別子
IDトークン
認証イベントに関するクレームが含まれているJSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012.) [JWT]

発行元 (Issuer)
クレームのセットを発行するエンティティ
発行元識別子
発行元を検証可能な識別子として機能するHTTPS URL
ユーザ情報エンドポイント
クライアントがアクセストークンを提示した際に、対応する認可グラントによって表される、エンドユーザに関して認可された情報を返す、保護リソース


 TOC 

2. プロトコルフロー

認可要求は、インプリシットフローと認可コードフローの二種類のうちのいずれか一つを用いる。認可コードフローはクライアントと認可サーバ間で用いられるクライアントシークレットを安全に保持することが可能なクライアントに適している。一方、インプリシットフローはそれが不可能なクライアントに適している。TLSをサポートしていないクライアントは、アクセストークンの盗聴を防ぐために認可コードフローを用いなければならない(MUST)。

当仕様はコードフローを用いるクライアントについてのみ文書化する。OpenIDプロバイダは両方のフローをサポートしなければならない(MUST)。インプリシットフローを使用するクライアントとOpenIDプロバイダは、OpenID Connect Standard 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” January 2013.) [OpenID.Standard] 仕様を参照すべきである。


 TOC 

2.1.OpenID Connect Scope値

OpenID Connectのクライアントは、OAuth 2.0 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749]の3.3節で定義されているscope値を、アクセストークンに要求するアクセス権限を示すのに用いる。アクセストークンに関連付けられたスコープは、OAuth 2.0によって保護されているエンドポイントへアクセスする際にどんなリソースを利用することができるかを決定する。OpenID Connectのスコープは、ユーザ情報エンドポイントで利用可能な情報のセットを要求するために用いられる。OAuth 2.0は、拡張機能として、追加のスコープ値を指定することができる。当仕様では、OpenID Connectで利用されるscope値のみ記載している。

以下のスコープで要求されたクレームは、認可サーバに任意として扱われる。

OpenID Request Object (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” January 2013.) [OpenID.Messages] を用いることにより、クレームは必須として扱われることができる。

OpenID Connectでは、以下のscope値が定義されている。

openid
必須 (REQUIRED)。クライアントは、認可サーバに対し、OpenID Connect要求を行っていることを通知する。もしopenidスコープ値が存在しなかった場合、その要求はOpenID Connect要求として扱ってはならない(MUST NOT)。
profile
任意 (OPTIONAL)。このスコープ値は、発行されたアクセストークンによって与えられる、ユーザ情報エンドポイントでのエンドユーザのデフォルトのprofile クレーム (Reserved Member Definitions)アクセスを要求する。これらのクレームは以下の通り: name、 family_name、 given_name、 middle_name、 nickname、 preferred_username、 profile、 picture、 website、 gender、 birthdate、 zoneinfo、 locale、 updated_time。
email
このスコープ値は、発行されたアクセストークンによって与えられる、ユーザ情報エンドポイントでのemailとemail_verifiedクレームへのアクセスを要求する。
address
このスコープ値は、発行されたアクセストークンによって与えられる、ユーザ情報エンドポイントでのaddressクレームへのアクセスを要求する。
phone
任意 (OPTIONAL)。このスコープ値は、発行されたアクセストークンによって与えられる、ユーザ情報エンドポイントに対する、phone_numberクレームへのアクセスを要求する。
offline_access
任意 (OPTIONAL)。このスコープ値は、ユーザが不在 (ログインしていない) のときでもエンドユーザのユーザ情報エンドポイントへアクセスするためのアクセストークンを取得できるOAuth 2.0リフレッシュトークンの発行を要求する。

ASCIIの大文字小文字を区別したスコープ値をスペース区切りでリスト化することにより、複数のスコープ値が使用されるかもしれない (MAY)。

いくつかのケースでは、エンドユーザーは、クライアントによって要求された一部またはすべての情報の提供をOpenIDプロバイダに拒否させるためのオプションが表示される。ユーザが開示を求められる情報量を最小化するために、クライアントは、ユーザ情報エンドポイントから入手可能な情報のサブセットのみを要求することを選択するかもしれない。

以下は、 scope要求の参考例である。

  scope=openid profile email phone

 TOC 

2.2. コードフロー

インプリシットフローは以下の手順で構成される:

  1. クライアントは、希望する要求パラメータを含む認可要求を準備する。
  2. クライアントは、認可サーバに要求を送信する。
  3. 認可サーバはエンドユーザーを認証する。
  4. 認可サーバは、エンドユーザーの同意／承認を取得する。
  5. 認可サーバは、 codeと共にエンドユーザをクライアントに戻す。
  6. クライアントは、応答としてアクセストークンとIDトークンを受信するために、トークンエンドポイントへcodeを送信する。


 TOC 

2.2.1. クライアントによる認可要求の準備

エンドユーザが保護リソースにアクセスしようとした際に、エンドユーザーの認可をまだ取得していない場合、クライアントは、認可エンドポイントへの認可要求の準備をする。

認可エンドポイントURLで使用されるスキームは、HTTPSでなければならない (MUST)。

クライアントは RFC 2616 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] で定義されているHTTP GET またはHTTP POST を用いて要求を構築してもよい (MAY)。

HTTP GETメソッドを用いる場合、要求パラメータは クエリストリングシリアライゼーション (Query String Serialization)によってシリアライゼーションされる。HTTP POST メソッドを用いた場合、要求パラメータは、[W3C.REC‑html401‑19991224] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.) で定義されている application/x-www-form-urlencoded フォーマットを用いてHTTP要求エンティティボディに追加される。

このプロファイルは、さらに以下の要求パラメータを規定する。

response_type
この値はcodeでなければならない (MUST)。これは、アクセストークンとIDトークンの両方が、codeとの交換でトークンエンドポイントから返されることを要求する。

要求内の他の必須 (REQUIRED) パラメータは以下の通り。

client_id
OAuth 2.0クライアント識別子。
scope
OAuth 2.0 scope 値。これは、スペースで区切られたASCII文字列の一つとしてopenidを含まなければならない (MUST)。任意 (OPTIONAL) scope値として profile、email、address、phone、offline_accessも定義されている。
redirect_uri
応答が送信されるリダイレクト先のURI。これは、プロバイダと共にあらかじめ登録しなければならない (MUST)。

要求は以下の任意 (OPTIONAL) パラメータを含めてもよい (MAY)。

state
推奨 (RECOMMENDED)。要求とコールバック間で状態を維持するために使用する不明瞭な値は、XSRF攻撃に対する保護の役割を果たす。
display
認可サーバがエンドユーザに対して、認証と同意のユーザインタフェース画面を表示する方法を指定するASCII文字列値。次の値がサポートされている。
page
認可サーバは、ユーザエージェントの（ポップアップとかではない）完全な画面として認証と同意のUIを表示すべきである (SHOULD)。displayパラメータが指定されていない場合、これがデフォルトの表示モードである。
popup
認可サーバは、ユーザエージェントのポップアップウィンドウとして認証と同意のUIを表示すべきである (SHOULD)。ポップアップユーザエージェントウィンドウは幅450ピクセル、高さ500ピクセルであるべきである (SHOULD)。
touch
認可サーバは、タッチインタフェースを活用したデバイス向けのUIを表示すべきである (SHOULD)。認可サーバは、タッチデバイスの検出を試み、さらにインターフェースをカスタマイズしてもよい (MAY)。
wap
認可サーバは、フィーチャーフォンの画面向けの認証と同意のUIを表示すべきである (SHOULD)。
prompt
認可サーバが再認証と同意のためにエンドユーザに対しプロンプトを表示するかどうかを指定する、スペース区切りの大文字小文字を区別したASCII文字列値のリスト。設定可能な値は以下のとおり。
none
認可サーバは、認証も同意もユーザインタフェース画面を表示してはならない(MUST NOT)。エンドユーザがまだ認証されていないか、またはクライアントが要求された{0}scope{/0}に対して事前設定された同意を保持していない場合は、エラーが返される。これは、既存の認証および/または同意が存在するかを確認するための手段として使用することができる。
login
認可サーバは、再認証のためにエンドユーザにプロンプトを表示しなければならない。
consent
認可サーバは、クライアントに情報を返す前にエンドユーザに同意のためのプロンプトを表示しなければならない (MUST)。
select_account
認可サーバは、エンドユーザにユーザアカウントを選択するためのプロンプトを表示しなければならない (MUST)。これは、認可サーバで複数のアカウントを持つユーザは、彼らが現在のセッションを持っているかもしれない複数のアカウントの間で選択することを許可する。
promptパラメータは、エンドユーザが現在のセッションのためにまだ存在していることを確認するためか、または要求に注意を喚起するためにクライアントで使用することができる。
nonce
IDトークンを持つクライアントセッションを関連付けるためと、リプレイ攻撃を軽減するために使用される文字列値。値は変更されずにそのまま認可要求からIDトークンへ渡されます。コードフローを用いる場合、nonceの使用は任意 (OPTIONAL) である。
login_hint
(必要に応じて) ユーザが認可サービスでの認証に用いるかもしれないログイン識別子に関して、認可サービスに対して与えるヒント。 このヒントは、ユーザに対して初めにユーザのEメールアドレス (またはその他の識別子) を求め、それをディスカバリした認可サービスに対しヒントとして受け渡す場合に、RPによって用いられる。ヒント値はディスカバリに用いた値とマッチしていることが推奨される。このパラメータの使用はOPの裁量に任されている。

以下は、認可要求の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.2.2. クライアントによる認可サーバへの要求の送信

認可要求を構築した後、クライアントはそれをHTTPS認可エンドポイントに送信する。これは、HTTPSリダイレクト、ハイパーリンク、またはユーザエージェントをそのURLへ導く他の安全な手段を介して行ってもよい (MAY)。

以下は、HTTPリダイレクトを使用した参考例である（表示上だけの行折り返りを含む）:

  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

 TOC 

2.2.3. 認可サーバによるエンドユーザの認証

認可サーバは、同意が正しいパーティからのものであるかを確認するために、リソースオーナーを認証する。 認証が実行される方法の正確な方法はこの仕様の範囲外である。


 TOC 

2.2.4. 認可サーバは、エンドユーザの同意／承認を取得する。

認可サーバは、要求されたスコープに対して、認可決定を取得する。 これは、エンドユーザに対し、同意の内容を認識させた上で同意を得るための対話をエンドユーザーに提示することによって行うか、または他の手段（例えば、事前に管理上の手段による同意を経由）を介して同意を確立することによって、実施できる。 。

openid スコープ値は、このOAuth 2.0要求がOpenID Connect要求であることを宣言する。その他の全てのスコープ値の使用は任意 (OPTIONAL) である。


 TOC 

2.2.5. 認可サーバによるエンドユーザのクライアントへの返却

認可が決定されると、認可サーバは、正常応答またはエラー応答を返す。


 TOC 

2.2.5.1. エンドユーザによる認可の許可

リソースオーナがアクセス要求を付与したとき、認可サーバーは code を発行し、 OAuth 2.0 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の4.1.2節に定義された application/x-www-form-urlencoded を用いて、リダイレクトURLのクエリコンポーネントに以下のクエリパラメータを追加し、クライアントへ導く。

code
必須 (REQUIRED)。OAuth 2.0 認可コード。
state
OAuth 2.0 scope 値。stateパラメータは、クライアントの認可要求に存在した場合は必須 (REQUIRED)。クライアントは、 state値が認可要求のstateパラメータと正確に一致することを確認しなければならない(MUST)。

以下は、参考例である（表示上だけの行折り返しを含む）:

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

 TOC 

2.2.5.2. エンドユーザによる認可の拒否または無効な要求

エンドユーザーが認可を拒否するか、またはエンドユーザーの認証が失敗した場合、認可サーバは、OAuth 2.0 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の4.1.2.1節に定義されているエラー認可応答を返さなければならない(MUST)。その他のパラメータは返されるべきではない(SHOULD)。


 TOC 

2.2.6. クライアントによるIDトークンとアクセストークンの取得

code を取得した後、クライアントは以下のようにトークンエンドポイントに対し、トークンを要求する。


 TOC 

2.2.6.1. クライアントによるコードの送信

OAuth 2.0 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の4.1.3節の記述通り、クライアントはトークンエンドポイントへ要求を行う。

以下は、 トークン要求の参考例である（表示目的のためだけの行折り返しがある）: 

  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.2.6.2. クライアントによるトークンの受信

OAuth 2.0 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の4.1.4節の記述通り、クライアントは以下のパラメータとともに応答を受信する。この応答はUTF-8を用いてエンコードされるべきである。

access_token
必須 (REQUIRED)。ユーザ情報エンドポイントのためのアクセストークン。
token_type
必須 (REQUIRED)。OAuth 2.0のトークンタイプ値。この値は "bearer" か、クライアントが認可サーバとネゴシエートしたその他の token_type でなければならない (MUST)。このプロファイルを実装するクライアントは、OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] 仕様をサポートしなければならない (MUST)。当プロファイルではベアラトークンの仕様についてのみ記述する。
id_token
必須 (REQUIRED)。IDトークン。
expires_in
任意 (OPTIONAL)。アクセストークンの秒単位の有効期限。
refresh_token
任意 (OPTIONAL)。リフレッシュトークン。

クライアントは、リソースサーバ上の保護リソースにアクセスするためにアクセストークンを使用することができる。

以下は、参考例である（表示上だけの行折り返しを含む）:

  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: 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.3. IDトークン

IDトークンは、認証イベントおよび他の要求されたクレームに関するクレームを含むセキュリティトークンである。IDトークンはJSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012.) [JWT] として表される。

IDトークンは、認証イベントおよびユーザ識別子を管理するために使用され、aud (audience) および nonce クレームを介して特定のクライアントをスコープとしている。

以下のクレームは、IDトークン内で必須である (REQUIRED)。

iss
必須 (REQUIRED)。応答の発行元の発行元識別子。
sub
必須 (REQUIRED)。主体の識別子。クライアントによって消費されることを意図している、発行元内でローカルユニークな再割り当てされないエンドユーザの識別子。 例： 24400320 または AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4 。 長さはASCIIで255文字を超えてはならない（MUST NOT）。
aud
必須 (REQUIRED)。このIDトークンが意図している聴衆。それはクライアントのOAuth 2.0のclient_id でなければならない (MUST)。
azp
任意 (OPTIONAL)。認可された当事者。IDトークンを要求したクライアントとは異なる場合、このメンバーは、OAuthアクセストークンとしてこのIDトークンを使用するよう認可されたOAuth 2.0クライアントを識別する。認可された当事者のclient_idを含まなければならない (MUST)。
exp
必須 (REQUIRED)。それ以降はIDトークンを処理のために受け入れてはならない（MUST NOT）ことを示す有効期限。このパラメータの処理は、現在の日時が、記載されている有効期限の日時より前でなければならない (MUST) ことが要求される。実装者は、クロックスキューを考慮するために、通常数分を超えない程度のずれを許容してもよい(MAY)。値は、UTCの1970-01-01T0:0:0Zから要望する日時までの秒数である。一般に日時についての詳細、特にUTCに関しては、RFC 3339 (Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.) [RFC3339] を参照すること。
iat
必須 (REQUIRED)。 JWTが発行された時刻。 値は、UTCの1970-01-01T0:0:0Zから要望する日時までの秒数である。一般に日時についての詳細、特にUTCに関しては、RFC 3339 (Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.) [RFC3339] を参照すること。
auth_time
任意 (OPTIONAL)。UTCの1970-01-01T0:0:0Zから、エンドユーザー認証が発生した日時までの秒数である。

JWTは、それを利用している全ての当事者によって認識されるその他のクレームを含むかもしれない (MAY)。

以下は、base64urlデコードされたIDトークンの参考例である（表示上だけの行折り返しを含む）: 

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

 TOC 

2.3.1. IDトークンの検証

クライアントは、トークンエンドポイント応答内のIDトークンを検証しなければならない (MUST)。このためにクライアントは、ピリオド(".")文字でid_tokenを分割し、2つ目のセグメントを取得、そしてそれに対し、IDトークンのクレームを含むJSONオブジェクトを取得するためにbase64urlデコードを行うだろう。そして次のように検証されなければならない(MUST):

  1. クライアントは、iss (issuer) クレームが、id_tokenの送信元であるトークンエンドポイントと適合しているか検証しなければならない (MUST)。
  2. クライアントは、iss (issuer)クレームの値によって識別される発行元が聴衆として登録したclient_idが、aud (audience) クレームに含まれていることを検証しなければならない (MUST)。IDトークンにそのクライアントが有効な聴衆であると列挙されていないか、そのクライアントが信頼していない追加の聴衆が含まれていた場合、IDトークンを拒絶しなければならない (MUST)。
  3. 現在の時刻は exp クレームの値より小さくなければならない（場合により、クロックスキューのため、多少のズレを許可する）。
  4. iat クレームは、攻撃対策のために保存しているナンスの保存時間の上限を制限するために、現在時刻からあまりにも大きく乖離しているときはトークンを拒絶したいといった場合に用いられることができる。許容範囲は、クライアント次第である。
  5. acrクレームが要求された場合、クライアントは、主張されているクレームの値が適切であることを確認すべきである(SHOULD)。acrクレームの値の意味と処理は、この仕様の範囲外である。 （※訳注：acrの詳細は「OpenID Connect Messages 1.0」を参照）
  6. auth_timeクレームが要求されていた場合、クライアントは、最後のユーザ認証から経過した時間があまりに大きいと判断した場合、値の検証と再認証の要求を行うべきである(SHOULD)。


 TOC 

2.4. ユーザ情報エンドポイント

追加の属性とトークンを取得するには、クライアントはユーザ情報エンドポイントへのGETまたはPOST要求を行う。

ユーザ情報エンドポイントサーバはトランスポート層セキュリティ機構の使用を必須としなければならない (MUST)。ユーザ情報エンドポイントサーバはTLS 1.2 RFC 5246 (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] および／または TLS 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) をサポートしなければならない (MUST)。また、同等のセキュリティを持つ、他のトランスポート層セキュリティ機構をサポートしてもよい (MAY)。

注：ユーザ情報エンドポイント応答が、IDトークンの sub (subject) 要素によって識別される対話を行ったユーザに関するものなのかについては保証されてない。ユーザ情報エンドポイント応答内の sub クレームは、追加のユーザ情報エンドポイントのクレームを使用する前に、IDトークン内の sub クレームと正確に一致していなければならない(MUST)。


 TOC 

2.4.1. ユーザ情報要求

クライアントは、エンドユーザの詳細情報を取得するためにユーザ情報エンドポイントに以降のパラメータを使用して要求を送るかもしれない (MAY)。ユーザ情報エンドポイントは、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., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749]の保護リソースである。このように、アクセストークンは、HTTP Authorizationヘッダを使用して指定する必要があります (SHOULD)。

access_token
必須 (REQUIRED)。アクセストークンは、OpenID Connectの認証要求から取得されます。このパラメータは、HTTP AuthorizationヘッダーまたはフォームエンコードされたHTTP POSTのボディ·パラメータのいずれかを介して1つのメソッドを使って送らなければなりません。
schema
必須 (REQUIRED)。返されるデータのスキーマ。唯一の定義されたschema値は openid である。
id
この識別子は予約されている。 これは、openid スキーマが使用されているときは、エンドポイントで無視しなければならない (MUST)。

以下は、 参考例である。

  GET /userinfo?schema=openid HTTP/1.1
  Host: server.example.com
  Authorization: Bearer SlAV32hkKG

 TOC 

2.4.2. ユーザ情報応答

要求されたスキーマがopenidの場合、ユーザ情報クレームがJSONオブジェクトのメンバーとして返却されなければならない (MUST)。応答ボディはUTF-8を用いてエンコードされるべきである (SHOULD)。下記で定義されたクレームが返されるかもしれないし、(以下に定義されていない) 追加のクレームが返されるかもしれない。

クレームが返されない場合、そのクレームの名前は、クレームのセットを表すJSONオブジェクトから省略されるべきであり (SHOULD)、nullまたは空の文字列値を持つべきではない (SHOULD NOT)。

メンバは複数の言語とスクリプトで表されるかもしれない (MAY)。言語とスクリプトを指定するため、BCP47 (Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.) [RFC5646] 言語タグに対し、区切られた各メンバ名を # で区切って加えなければならない (MUST)。例えば、日本語のカタカナで家族名を表現するには family_name#ja-Kana-JP と指定する。これは、 family_name#ja-Hani-JP として表現される漢字表記に対する発音に基づいたインデックスとして一般的に用いられる。


メンバ型説明
sub 文字列 発行元内でエンドユーザを示す必須識別子。sub (subject) クレームは、ユーザ情報応答に必ず含まれなければならない (MUST)。
name 文字列 エンドユーザのロケールと設定に応じて順序づけられた、エンドユーザのすべての名前のパートを含む表示可能な形式でのフルネーム。
given_name 文字列 エンドユーザの名。
family_name 文字列 エンドユーザの姓。
middle_name 文字列 エンドユーザのミドルネーム。
nickname 文字列 エンドユーザのカジュアルな名前。given_name と同じであるかもしれないし、同じではないかもしれない (MAY)。例えば、 Mike という nickname 値 が、Michael という given_name 値と一緒に返される可能性がある。
preferred_username 文字列 janedoe や j.doe のような、エンドユーザーがRP側で希望する、簡略化された名前。この値は @ や / や空白のような特殊文字を含む任意の有効なJSON文字列であるかもしれない (MAY)。RPは、この値の一意性に依存してはならない (MUST NOT)。 (Section 2.4.2.2 (Claim Stability and Uniqueness)参照)
profile 文字列 エンドユーザのプロファイルページのURL。
picture 文字列 エンドユーザのプロファイル画像のURL。
website 文字列 エンドユーザのウェブページまたはブログのURL。
email 文字列 エンドユーザの優先電子メールアドレス。RPは、この値の一意性に依存してはならない (MUST NOT)。 (Section 2.4.2.2 (Claim Stability and Uniqueness)参照)
email_verified 真偽値 エンドユーザの電子メールアドレスが検証されている場合はtrue、それ以外の場合はfalse。
gender 文字列 エンドユーザの性別。この仕様で定義されている値は female と male である。定義されている値のいずれも適用できない場合は他の値が使用されるかもしれない (MAY)。
birthdate 文字列 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 フォーマットで表されたエンドユーザの誕生日。省略されていることを示すため、年には 9999 が指定されるかもしれない (MAY)。年のみを表現するために、YYYYフォーマットが許可される。プラットフォームの日付関連関数に依存している場合、年のみを指定することは様々な月日となってしまう可能性があるため、実装者は正確に日付を処理するためにこの要因を考慮するべきという点に注意すること。
zoneinfo 文字列 エンドユーザのタイムゾーンを表したゾーン情報 [zoneinfo] (Public Domain, “The tz database,” June 2011.) タイムゾーンデータベースに示された文字列。例： Europe/Paris や America/Los_Angeles。
locale 文字列 エンドユーザのロケール。BCP47 (Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.) の言語タグとして表現される。これは通常、ダッシュで区切られた、 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のように、ダッシュ以外の区切り文字としてアンダースコアを使用している。実装は、同様にこのロケールの構文を受け入れることを選んでもよい (MAY)。
phone_number 文字列 エンドユーザの優先電話番号。このクレームのフォーマットは 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 。
address JSONオブジェクト エンドユーザの優先アドレス。 address メンバの値は、 JSON (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627] の Section 2.5.2.1 (Address Claim) に定義されているメンバのいくつか、またはすべてを含むJSON構造体である。
updated_time 文字列 RFC 3339 (Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.) [RFC3339] で定義された日時で表された、エンドユーザの情報の最終更新日時。例： 2011-01-03T23:58:42+0000 。

表1: 予約済みメンバの定義

以下は、 応答の参考例である。 

  {
   "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"
  }

[OpenID.Registration] (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” January 2013.) で異なるフォーマットが規定されない限り、ユーザ情報エンドポイントは、JSONフォーマットでクレームを返さなければならない (MUST)。ユーザ情報エンドポイントは、フォーマットを示すためにContent-Typeヘッダーを返さなければならない (MUST)。以下は、受け入れられるコンテントタイプである。

Content-Type返されるフォーマット
application/json plain text JSON object
application/jwt JSON Web Token (JWT)


 TOC 

2.4.2.1.  住所クレーム

物理的な郵送先住所のコンポーネント。 実装では、入手可能な情報とエンドユーザのプライバシー設定に応じて、 addressのフィールドのサブセットのみを返すかもしれない (MAY)。たとえば、 countryやregionは、より詳細なアドレス情報なしで、返されるかもしれない。

実装では、formatted サブフィールド中に単一の文字列だけで完全なアドレスを返してもよい (MAY)、またはその他のサブフィールドを用いて、個々のコンポーネントのフィールドを返してもよい (MAY)、またはそれらの両方を返すかもしれない (MAY)。両方の変数が返された場合、formattedアドレスは複数のコンポーネントフィールドをどのように組み合わせるべき (SHOULD) かを示し、双方は同等のアドレスを示しているべきである (SHOULD)。

formatted
表示や宛名ラベルで使用するためにフォーマットされた完全な住所。このフィールドは改行を含むかもしれない (MAY)。 これは、このフィールドにおける、並べ替えやフィルタリングに用いられる際の最優先のサブフィールドである。
street_address
家番号、ストリート名、私書箱、複数行の拡張された住所情報を含むことができる完全な住所コンポーネント。 このフィールドは改行を含むかもしれない (MAY)。
locality
都市や地域のコンポーネント。
region
州、地方、県や地域のコンポーネント。
postal_code
ZIPコードまたは郵便番号コンポーネント。
country
国の名前のコンポーネント。


 TOC 

2.4.2.2. クレームの不変性と一意性

sub (subject) クレームは、2.3 (ID Token) 節の記述のとおり、ある特定のエンドユーザに対し、ローカルユニークでかつ、決して再割り当てされない (MUST) ため、クライアントが不変であるという前提を置ける唯一のクレームである。

したがって、ある特定のエンドユーザに対し、一意性が保証された唯一の識別子は、発行元の識別子と sub クレームの組み合わせであり、preferred_usernameやemailなどの他のフィールドは、ある特定のエンドユーザに対する一意の識別子として使用してはならない (MUST NOT)。

他のすべてのクレームは、異なる発行元間で不変性またはユーザ間での一意性の保証はできない。そして発行元は、ローカルな制限とポリシーを適用することが許される。 たとえば、発行元は、異なる時点の異なるエンドユーザ間で、与えられたpreferred_usernameまたはemail アドレスクレームを再利用するかもしれない (MAY)。そして、ある特定のエンドユーザについて、主張したpreferred_usernameやemailアドレスが変わるかもしれない (MAY)。


 TOC 

2.4.3. ユーザ情報エラー応答

エラー状態が発生した際、ユーザ情報エンドポイントは OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] の3節で定義されているエラー応答を返す。

OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] の3.1節に定義されているエラーコードに加え、当仕様では以下のエラーコードを定義する:

invalid_schema
要求されたスキーマは無効またはサポートされていない。


 TOC 

3. シリアライゼーション

要求メッセージは、以下の方法の一つを用いてシリアライゼーションされるかもしれない (MAY)。

  1. クエリストリングシリアライゼーション
  2. フォームシリアライゼーション


 TOC 

3.1. クエリストリングシリアライゼーション

クエリストリングシリアライゼーションを用いてパラメータをシリアライゼーションするために、クライアントは、[W3C.REC‑html401‑19991224] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.)に定義されたapplication/x-www-form-urlencodedフォーマットを用いて、URLのクエリコンポーネントにパラメータと値を追加して文字列を構築する。クエリストリングのシリアライゼーションは、通常、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. フォームシリアライゼーション

パラメータと値は、[W3C.REC‑html401‑19991224] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.)に定義されたapplication/x-www-form-urlencodedフォーマットを用いて、HTTP要求のエンティティボディにパラメータと値を追加することによってフォームシリアライゼーションされる。フォームのシリアライゼーションは、通常、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. 文字列操作

いくつかのOpenID Connectメッセージを処理すると、既知の値とメッセージの値を比較する必要がある。たとえば、ユーザ情報エンドポイントによって返されたクレームの名前は、sub のような特定のクレームの名前と比較されることがある。しかし、Unicode文字列を比較すると、重要なセキュリティ上の影響がある。

そのため、JSON文字列や他のUnicode文字列の比較は以下のように実施しなければならない (MUST):

  1. Unicodeコードポイントの配列を生成するエスケープが適用されているJSONを削除する。
  2. Unicode Normalization (Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” 09 2009.) [USA15] は、JSON文字列とその比較対象の文字列のいずれにも適用されない (MUST NOT)。
  3. 二つの文字列の比較は、Unicodeコードポイントとしての等価比較を行わなければならない (MUST)。

いくつかの場所で、この仕様は、文字列のスペース区切りリストを使用します。 全てのそのようなケースで、ASCII空白文字(0x20)のみが、この目的のために使用されるかもしれません (MAY)。


 TOC 

5. 実装に関する考慮事項

当仕様では、OAuthコードグラントタイプを用いたリライイングパーティによって使用される機能を定義する。これらのリライイングパーティはいずれも、当仕様で必須 (REQUIRED) または MUSTと記述されている機能を実装しなければならない (MUST)。


 TOC 

5.1. ディスカバリと登録

いくつかのOpenID Connect環境では、OpenIDプロバイダ、および/またはリライイングパーティの事前設定済みのセットを使用することができる。これらのケースでは、アイデンティティやサービス、またはクライアントの動的登録に関する情報の動的ディスカバリをサポートする必要はない。

しかし、事前設定で連携されていないリライイングパーティとOpenIDプロバイダ間で、予定していなかった対話をサポートすることを選択する場合、OpenID Connect Discovery 1.0 (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” January 2013.) [OpenID.Discovery] および OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” January 2013.)[OpenID.Registration] に定義されている機能を実装すべきである (SHOULD)。


 TOC 

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

セキュリティに関する考慮事項については、OpenID Connect Standard 1.0 仕様 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” January 2013.) [OpenID.Standard] を参照すること。


 TOC 

7. プライバシーに関する考慮事項

ユーザ情報応答は、通常、個人識別情報 (PII) が含まれている。このように、指定目的のための情報リリースに対するエンドユーザーの同意は、該当する規則に従って認可時または事前に取得するべきである (SHOULD)。 使用目的は通常 redirect_uri に関連付けて登録されている。

必要なユーザ情報データのみがクライアントに格納されているべきであり (SHOULD)、クライアントは使用目的の宣言と受信したデータを関連付けておくべきである (SHOULD)。

エンドユーザが自分のデータに誰がアクセスしたかを監視できるように、リソースサーバはエンドユーザに対し、ユーザ情報アクセスログを利用できるようにすべきである (SHOULD)。

クライアント間の相関関係の危険性からエンドユーザを保護するために sub (subject) として、仮名識別子(PPID)の使用を考慮する必要がある。


 TOC 

8. IANAに関する考慮事項

この文書ではIANAへの要求はない。


 TOC 

9. 文献


 TOC 

9.1. 規定文献

[E.164] International Telecommunication Union, “E.164: The international public telecommunication numbering plan,” 2010.
[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.
[JWT] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” draft-ietf-oauth-json-web-token (work in progress), December 2012 (HTML).
[OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” January 2013.
[OpenID.Messages] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” January 2013.
[OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” January 2013.
[OpenID.Standard] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” January 2013.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2246] Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” RFC 2246, January 1999 (TXT).
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616, June 1999 (TXT, PS, PDF, HTML, XML).
[RFC3339] Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” RFC 3339, July 2002 (TXT, HTML, XML).
[RFC4627] Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” RFC 4627, July 2006 (TXT).
[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT).
[RFC5646] Phillips, A. and M. Davis, “Tags for Identifying Languages,” BCP 47, RFC 5646, September 2009 (TXT).
[RFC6749] Hardt, D., “The OAuth 2.0 Authorization Framework,” RFC 6749, October 2012 (TXT).
[RFC6750] Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” RFC 6750, October 2012 (TXT).
[USA15] Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” Unicode Standard Annex 15, 09 2009.
[W3C.REC-html401-19991224] Hors, A., Raggett, D., 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 

9.2. 参考文献

[OpenID.Implicit] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Implicit Client Profile 1.0,” January 2013.

 TOC 

Appendix A. 謝辞

The OpenID Community would like to thank the following people for the work they've done in the drafting and editing of this specification.

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

Anthony Nadalin (tonynad@microsoft.com), Microsoft

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

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

Casper Biering (cb@peercraft.com), Peercraft

Chuck Mortimore (cmortimore@salesforce.com), Salesforce

David Recordon (dr@fb.com), Facebook

Edmund Jay (ejay@mgi1.com), Illumila

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

Hideki Nara (hideki.nara@gmail.com), Takt Communications

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

Johnny Bufu (jbufu@janrain.com), Janrain

Justin Richer (jricher@mitre.org), Mitre

Luke Shepard (lshepard@fb.com), Facebook

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

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

Nov Matake (nov@matake.jp), Independent

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

Paul Tarjan (pt@fb.com), Facebook

Roland Hedberg (roland.hedberg@adm.umu.se), Independent

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

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


 TOC 

Appendix B. 通知

Copyright (c) 2013 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. 文書履歴

[[ To be removed from the final specification ]]

-23

  • Fixed #620 - Update Section 2.2.6.2. to allow for other token types, but make bearer mandatory to support for basic clients.
  • Added Implementation Considerations section.
  • Fixed #698 - Inconsistent use of articles.
  • Added auth_time definition to ID Token schema.
  • Fixed #655 - Specify UTF-8 as encoding scheme whenever necessary.

-22

  • Fixed #687 - Inconsistency between user_id and prn claims. The fix changed these names: user_id -> sub, user_id_types_supported -> subject_types_supported, user_id_type -> subject_type, and prn -> sub.
  • Fixed #689 - Track JWT change that allows JWTs to have multiple audiences.
  • Fixed #660 - Clarified that returning the sub value from the UserInfo endpoint is mandatory.
  • Fixed #636 - ID Token authorized party claim.
  • Fixed #539 - Add scope for offline access.
  • Fixed #689 - added caution about unrecognized audiences.
  • Fixed #693 Added login_hint
  • Updated scopes text.

-21

  • added informative definition of nonce in 2.2.1
  • Clarified that the client MUST check that the issuer is valid for the token endpoint
  • RE #607 add example decoded id_token for non self-issued.
  • Fixed #666 - JWS signature validation vs. verification.
  • Fixed #682 - Change remaining uses of "birthday" to "birthdate".
  • Referenced OAuth 2.0 RFCs -- RFC 6749 and RFC 6750.

-20

  • Added preferred_username claim under profile scope
  • Added ID Token section to describe required claims
  • Added section on claim stability

-19

  • Fixed Section 2.2.5.1 to return code in a query parameter rather than a fragment
  • Removed claims_in_id_token scope value, per decision on June 15, 2012 special working group call

-18

  • Use "code" response_type instead of "token id_token" in Basic Profile, per issue #567
  • Changed verified to email_verified, per issue #564
  • Removed Check ID Endpoint, per issue #570
  • Removed requirement for ID Token signature validation from Basic Profile, per issue #568
  • Removed use of nonce from Basic Profile, per issue #569
  • Changed client.example.com to client.example.org, per issue #251
  • Added claims_in_id_token scope definition to Basic and Implicit, per issue #594
  • Use standards track version of JSON Web Token spec (draft-ietf-oauth-json-web-token)

-17

  • Removed "embedded" display type, since its semantics were not well defined, per issue #514
  • Add hash and hash check of access_token and code to id_token, per issue #510
  • Add example JS code for client
  • Updated Notices
  • Updated References

-16

  • Added iat as a required claim in ID Tokens
  • Enumerated claims requested by the "profile" scope value
  • Added text about implicit flow to Abstract

-15

  • Removed definition and usage for assertion and claim object
  • email scope allows access to the 'verified' claim
  • Removed language pertaining to custom userinfo schemas
  • Moved display=none to prompt=none
  • Added additional 'display' parameter options
  • Redefined 'nonce' in Authorization Request. Changed to REQUIRED parameter.
  • Changed usage of "approval" to "consent"
  • Use RFC 6125 to verify TLS endpoints
  • Allow other gender strings in UserInfo schema
  • ID Token MUST be JWT
  • RECOMMENDED E.164 format for UserInfo 'phone_number' claim
  • Changed UserInfo Error Response to augment and return OAuth 2.0 Bearer Token Error Response
  • Check ID Endpoint SHOULD use POST
  • Added section about string comparison rules needed
  • Added Response Encoding according to Multiple Response Types spec
  • Make openid scope provide user_id from userinfo endpoint
  • Changed Security Considerations to refer to corresponding section in Standard
  • Check ID Endpoint uses ID Token as Access Token according to Bearer Token spec
  • Update John Bradley email and affiliation for Implementer's Draft
  • Removed invalid_id_token error codes
  • Replace queryString with postBody variable in example JS

-14

  • Changed section 3.2.1 to refer to access_token ticket #134.
  • Bumped version + date.
  • Changed 7.4 in security considerations to show none is REQUIRED.
  • Changed 3.2.4.1 User Info to UserInfo per Ticket #137.
  • Changed formatting of 7.1 per ticket #140.

-13

  • Changed check_session to check_id.
  • schema=openid now required when requesting UserInfo.
  • Removed issued_to, since not well defined.
  • Removed display values popup, touch, and mobile, since not well defined.

-12

  • Ticket #48 Changed Check Session to take the id_token as a parameter.

-11

  • Renamed from "Lite" to "Basic Client".
  • Numerous cleanups, including updating references.

-10

  • Add back id_token to the response type per issue 27.
  • Changed endpoint name in example from id_token to check_session.
  • Added token_type to the response and explanations of the optional parameters.

-09

  • Clean up typos.
  • Clean up scope explanation.
  • Fix 3.2.4.1 to include id_token in response.

-08

  • Added note about OP needing to read the full spec.
  • Reverted back to GET for introspection based on Google feedback.
  • Changed scopes to openid, profile, address, and email to make them additive.
  • Changed introspection to Check Session Endpoint to be consistent with session management.
  • Changed validation rules, the Check session endpoint will return an error for expired or invalid tokens, so the Client doesn't need to check expiration.
  • Added explanation of why an id_token is used to verify identity rather than the userinfo Access Token.

-07

  • Changed introspection to post
  • Changed userinfo from id to user_id to be consistent with introspection endpoint.
  • Fixed introspection example to use id_token rather than access token.
  • Removed asking for id_token in response type.
  • Fixed Section 3 to be clear it is client secret that is maintained between the client and the OP.

-06

  • Only require the token flow in Lite. Removed code flow.
  • Make id_token required. The id_token is treated as opaque.
  • Rearranged sections for readability.
  • Dropped the schema parameter to the Introspection endpoint, which was formerly a string with the value user_id. This is unnecessary since the id_token parameter already can be used to disambiguate the intended uses(s) of the endpoint.
  • Dropped the requested audience from the Lite spec, which was formerly the identifier of the target audience of the response. This could be part of the Standard spec, but is an advanced scenario, and so not appropriate for Lite.
  • Reference the Discovery and Registration specs, since they're needed for interaction between non-pre-configured parties (so that OpenID Connect installations can be Open).

-05

  • Corrected issues raised by Casper Biering.
  • Created the OpenID Connect Lite specification.

-04

  • Correct issues raised by Pam Dingle and discussed on the mailing list after the 7-Jul-11 working group call.
  • Adopted long_names.

-03

  • Correct issues raised by Johnny Bufu and discussed on the 7-Jul-11 working group call.

-02

  • Consistency and cleanup pass, including removing unused references.

-01

  • Initial draft

 TOC 

著者アドレス

  Nat Sakimura
  Nomura Research Institute, Ltd.
Email:  n-sakimura@nri.co.jp
  
  John Bradley
  Ping Identity
Email:  ve7jtb@ve7jtb.com
  
  Michael B. Jones
  Microsoft
Email:  mbj@microsoft.com
  
  Breno de Medeiros
  Google
Email:  breno@google.com
  
  Chuck Mortimore
  Salesforce
Email:  cmortimore@salesforce.com
投稿者 時刻:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)