2012年7月22日日曜日

[obsoleted] OpenID Connect Basic Client Profile 1.0 - draft 20 日本語私訳

Draft: OpenID Connect Basic Client Profile 1.0 - draft 20

「OpenID Connect Basic Client Profile 1.0 - draft 20」を和訳してみました。 原文は http://openid.net/specs/openid-connect-basic-1_0.html です。

 TOC 
DraftN. Sakimura
 NRI
 J. Bradley
 Ping Identity
 M. Jones
 Microsoft
 B. de Medeiros
 Google
 C. Mortimore
 Salesforce
 June 23, 2012


OpenID Connect Basic Client Profile 1.0 - draft 20

概要

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

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


目次

1.  はじめに
    1.1.   要求記法および規則
    1.2.   用語
2.  プロトコルフロー
    2.1.   OpenID Connectスコープ
    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.4.   IDトークンの検証
    2.5.   ユーザ情報エンドポイント
        2.5.1．  ユーザ情報要求
        2.5.2.  ユーザ情報応答
            2.5.2.1.  住所クレーム
            2.5.2.2.  クレームの不変性と一意性
        2.5.3.  ユーザ情報エラー応答
3.  ディスカバリと登録
4.  クエリストリングシリアライゼーション
5.   フォームシリアライゼーション
6.   文字列操作
7.   セキュリティに関する考慮事項
8.  プライバシーに関する考慮事項
9.   IANAに関する考慮事項
10.  文献
    10.1.   規定文献
    10.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,” June 2012.) [OpenID.Standard] の一プロファイルであり、OAuth認可コードグラントタイプを用いた基本的なウェブベースのリライイングパーティについて、実装が容易になるよう作成されている。 OAuthインプリシットグラントタイプを用いた基本的なウェブベースのリライイングパーティのためのプロファイルについては、OpenID Connect Implicit Client Profile 仕様 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Implicit Client Profile 1.0,” June 2012.) [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 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]で定義されている、「アクセストークン」、「リフレッシュトークン」、「認可コード」、「認可グラント」、「認可サーバ」、「認可エンドポイント」、「クライアント」、「クライアント識別子」、「クライアントシークレット」、「保護リソース」、「リソース所有者」、「リソースサーバ」、「トークンエンドポイント」という用語を用いる。また当仕様では、以下の用語について定義する。

リライイングパーティ (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トークン (ID Token)
JSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) 認証イベントに関するクレームが含まれている[JWT]

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


 TOC 

2.  プロトコルフロー

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

OpenID Connect Basic Client profileは、コードフローを用いるクライアントについてのみ記述している。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,” June 2012.) [OpenID.Standard]を参照すべきである。


 TOC 

2.1. OpenID Connectスコープ

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

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

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

複数のスコープが、スペース区切りで、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トークンの両方が、コードとの交換でトークンエンドポイントから返されることを要求する。

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

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

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

state
推奨。 要求とコールバック間で状態を維持するために使用する不明瞭な値は、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)と認可サーバに通知する。エンドユーザーがまだ認証されていないか、またはクライアントが要求されたscopeに対して事前設定された同意を保持していない場合は、エラーが返される。これは、既存の認証および/または同意が存在するかを確認するための手段として使用することができる。
login
認可サーバは、再認証のためにエンドユーザーにプロンプ​​トを表示しなければならない。
consent
認可サーバは、クライアントに情報を返す前にエンドユーザーに同意のためのプロンプ​​トを表示しなければならない (MUST)。
select_account
認可サーバは、エンドユーザにユーザーアカウントを選択するためのプロンプ​​トを表示しなければならない (MUST)。これは、認可サーバで複数のアカウントを持つユーザーは、彼らが現在のセッションを持っているかもしれない複数のアカウントの間で選択することを許可する。
promptパラメータは、エンドユーザーが現在のセッションのためにまだ存在していることを確認するためか、または要求に注意を喚起するためにクライアントで使用がすることができる。 このパラメータにnoneが他のなんらかの値と共に含まれていた場合、エラーが返される。

以下は、認可要求の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リダイレクト、ハイパーリンク、またはユーザエージェントをその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 スコープは、そのセッション上の認証されたエンドユーザのユーザ識別子へのRPアクセスを許可する。

他のすべてのスコープはオプションである。 openid 以外のスコープの認可をエンドユーザが拒否した場合に、エラーを返すべきかの判断はOpenIDプロバイダ次第である。


 TOC 

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

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


 TOC 

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

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

code
必須。 OAuth 2.0 認可コード。
state
stateパラメータは、クライアントの認可要求に存在した場合は必須。クライアントは、 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 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June2012.) [OAuth2.0]の4.1.2.1節に定義されているエラー認可応答を返さなければならない(MUST)。その他のパラメータは返されるべきではない(SHOULD)。


 TOC 

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

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


 TOC 

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

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

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

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

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

 TOC 

2.2.6.2.  クライアントによるトークンの受信

access_token
必須。 ユーザ情報エンドポイントのためのアクセストークン。
token_type
必須。値は "bearer"でなければならない（MUST） 。
id_token
必須。 IDトークン。
expires_in
任意。アクセストークンの秒単位の有効期限。
refresh_token
任意。リフレッシュトークン。

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

以下は、 参考例である。 （表示目的のためだけの次の行への折り返しがある）。

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
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,” May 2012.) [JWT] として表される。

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

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

iss
必須。応答の発行元の発行元識別子。
user_id
必須。クライアントによって消費されることを意図している、発行元内でローカルユニークな再割り当てされないエンドユーザの識別子。 例： 24400320 または AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4 。 長さはASCIIで255文字を超えてはならない（MUST NOT）。
aud
必須。このメンバは、このIDトークンが意図している聴衆を識別する。 それはクライアントのOAuth 2.0のclient_id でなければならない (MUST)。
exp
必須。整数型。それ以降は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
必須。整数型。iat (issued at) クレームは、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] 参照すること。

追加の任意のクレームが、IDトークン内に存在するかもしれない。


 TOC 

2.4. IDトークンの検証

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

  1. クライアントはaud (audience) クレーム内のclient_idが、iss (issuer)クレームの値によって識別される発行元が登録したものであることを検証する必要がある(MUST)。aud (audience)の値が発行元に対して有効でない場合は、IDトークンを拒絶しなければならない(MUST)。 (※訳注：client_idはIDトークンの発行元であるOpenIDプロバイダが個々のクライアントに対して払い出すため、クライアントが現在IDトークンをやり取りしているOpenIDプロバイダにとってのクライアント自身を表すclient_idが想定通りかどうかを検証するという意だと思われる。)
  2. 現在の時刻は exp クレームの値より小さくなければならない。
  3. iat クレームは、攻撃対策のために保存しているナンスの保存時間の上限を制限するために、現在時刻からあまりにも大きく乖離しているときはトークンを拒絶したいといった場合に用いられることがある。 許容範囲は、クライアント次第である。
  4. acrクレームが要求された場合、クライアントは、主張されているクレームの値が適切であることを確認すべきである(SHOULD)。acrクレームの値の意味と処理は、この仕様の範囲外である。 （※訳注：acrの詳細は「OpenID Connect Messages 1.0」を参照）
  5. auth_timeクレームが要求されていた場合、クライアントは、最後のユーザ認証から経過した時間があまりに大きいと判断した場合、値の検証と再認証の要求を行うべきである(SHOULD)。


 TOC 

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

追加の属性とトークンを取得するには、クライアントはユーザ情報エンドポイントへの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トークンの user_id 要素によって識別される対話を行ったユーザに関するものなのかについては保証されてない。ユーザ情報エンドポイント応答内の user_id クレームは、追加のユーザ情報エンドポイントのクレームを使用する前に、IDトークン内の user_id クレームと正確に一致していなければならない(MUST)。


 TOC 

2.5.1．ユーザ情報要求

クライアントは、エンドユーザの詳細情報を取得するためにユーザ情報エンドポイントに以降のパラメータを使用して要求を送るかもしれない (MAY)。ユーザ情報エンドポイントは、OAuth 2.0 Bearer Tokens (Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” June 2012.) [OAuthBearer] 仕様に準拠した OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0] の保護リソースである。このように、アクセストークンは、HTTP Authorizationヘッダを使用して指定する必要があります (SHOULD)。

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

以下は、 参考例である。 

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

 TOC 

2.5.2.ユーザ情報応答

要求されたスキーマが openid の場合、応答は下記に定義されているクレームのフルセットまたはサブセットを含むJSONオブジェクトを返す必要がある (MUST)。（下記に示されていない）追加のクレームも返されるかもしれない (MAY)。

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

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


メンバー型説明
user_id 文字列 発行元内でエンドユーザーを示す必須識別子。
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.5.2.2 (Claim Stability and Uniqueness) 参照)
profile 文字列 エンドユーザのプロファイルページのURL。
picture 文字列 エンドユーザのプロファイル画像のURL。
website 文字列 エンドユーザのウェブページまたはブログのURL。
email 文字列 エンドユーザの優先電子メールアドレス。RPは、この値の一意性に依存してはならない (MUST NOT)。 (Section 2.5.2.2 (Claim Stability and Uniqueness) 参照)
email_verified 真偽値 エンドユーザーの電子メールアドレスが検証されている場合はtrue、それ以外の場合はfalse。
gender 文字列 エンドユーザの性別：この仕様で定義されている値は female と male である。 定義されている値のいずれも適用できない場合は他の値が使用されるかもしれない (MAY)。
birthday 文字列 エンドユーザの誕生日。MM/DD/YYYY形式の日付文字列として表される。省略されていることを示すため、年には 0000 が指定されるかもしれない (MAY)。
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] を推奨。 例： +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: 予約済みメンバーの定義

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

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

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


 TOC 

2.5.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.5.2.2.  クレームの不変性と一意性

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

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

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


 TOC 

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

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

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

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


 TOC 

3.  ディスカバリと登録

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

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


 TOC 

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

クエリストリングシリアライゼーションを使用してパラメータをシリアライズするためには、クライアントが、 [W3C.REC-html401-19991224] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.) に定義されている application/x-www-form-urlencoded を使用してクエリコンポーネントにパラメータと値を追加することによって文字列を構築する。

以下は、 このようなシリアライゼーションの参考例である。 

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 

5. フォームシリアライゼーション

パラメータとその値は、[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 

6. 文字列操作

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

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

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

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


 TOC 

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

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


 TOC 

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

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

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

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

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


 TOC 

9. IANAに関する考慮事項

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


 TOC 

10.  文献


 TOC 

10.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.
[JWT] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.
[OAuth.Bearer] Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” June 2012.
[OAuth2.0] Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.
[OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” May 2012.
[OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” May 2012.
[OpenID.Standard] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” June 2012.
[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).
[USA15] Davis, M., Whistler, K., and M. Durst, “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 

10.2. 参考文献

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

 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) 2012 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 ]]

-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 paramater 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)