2012年7月22日日曜日

[obsoleted] OpenID Connect Implicit Client Profile 1.0 - draft 02 日本語私訳

Draft: OpenID Connect Implicit Client Profile 1.0 - draft 02

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

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


OpenID Connect Implicit Client Profile 1.0 - draft 02

概要

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

OpenID Connect Implicit Client 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.5.3.  リダイレクトURI応答の例
    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 Implicit 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 Basic Client Profile (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Profile 1.0,” June 2012.) [OpenID.Basic]を参照すること。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トークン
JSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) 認証イベントに関するクレームが含まれている[JWT]

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


 TOC 

2.  プロトコルフロー

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

OpenID Connect Implicit Client Profileは、インプリシットフローを用いるクライアントについてのみ記述している。OpenIDプロバイダは両方のフローをサポートしなければならない(MUST)。認可コードフローを用いたいクライアントとOpenIDプロバイダはOpenID Connect Standard 1.0 Specification (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.  Implicit Flow

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

  1. クライアントが希望する要求パラメータを含む認可要求を準備する。
  2. クライアントは、認可サーバに要求を送信する。
  3. 認可サーバはエンドユーザーを認証する。
  4. 認可サーバは、エンドユーザーの同意／承認を取得する。
  5. 認可サーバは、アクセストークンおよびIDトークンと共にエンドユーザをクライアントに送り戻す。


 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
スペース区切りのリストとして、 tokenとid_tokenを含まなければならない (MUST)。これはアクセストークンとIDトークンの両方がレスポンスのURLフラグメントとして返されることを要求する。

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

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

要求は、下記の任意の、時には必須のパラメータを含めることができる (MAY)。

nonce
IDトークンを持つクライアントセッションを関連付けるためと、リプレイ攻撃を軽減するために使用される文字列値。 値は変更されずにそのままIDトークンに渡されます。 これを達成する一つの方法は、署名されたセッションクッキーとしてランダムな値を格納して、 nonceパラメータの値を渡すことである。その場合には、返されたIDトークンのnonceは、第三者によるIDトークンリプレイを検出するために署名されたセッションクッキーと比較される。
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=token%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj

 TOC 

2.2.2.  クライアントによる認可サーバへの要求の送信

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

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

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

 TOC 

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

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


 TOC 

2.2.4.  認可サーバによるエンドユーザの同意／認可の取得

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

openid スコープは、そのセッション上の認証されたエンドユーザのユーザ識別子へのRPアクセスを許可する。

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


 TOC 

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

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


 TOC 

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

リソースオーナがアクセス要求を付与したとき、認可サーバはアクセストークンを発行し、 OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]の4.2.2節と、OAuth 2.0 Multiple Response Type Encoding Practices (de Medeiros, B., Scurtescu, M., and P. Tarjan, “OAuth 2.0 Multiple Response Type Encoding Practices,” May 2012.) [OAuth.Responses] の定義に従い、 application/x-www-form-urlencoded を用いて、リダイレクトURIのフラグメントコンポーネントに以下のパラメータを追加し、クライアントへ導く。

インプリシットフローでは、全体の応答は、OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0] の4.2.2節で定義されたリダイレクトURLのフラグメントコンポーネントとして返される。

access_token
必須。 ユーザ情報エンドポイントのためのアクセストークン。
token_type
必須。値は "bearer"でなければならない（MUST） 。
id_token
必須。 IDトークン。
state
stateパラメータは、クライアントの認可要求に存在した場合は必須。クライアントは、 state値が認可要求のstateパラメータと正確に一致することを確認しなければならない(MUST)。
expires_in
任意。アクセストークンの秒単位の有効期限。

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

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

HTTP/1.1 302 Found
Location: https://client.example.org/cb#
access_token=SlAV32hkKG
&token_type=bearer
&id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
&expires_in=3600
&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.5.3.  リダイレクトURI応答の例

クライアントは、ユーザーエージェントのために、フラグメントエンコードされた応答を解析し、検証用のWebサーバクライアントにそれをPOSTする方法を提供しなければならない。

以下は、クライアントがそのredirect_uriでホストする可能性のあるJavaScriptファイルの例である。 これは、認可サーバからのリダイレクトによってロードされます。 フラグメントは解析され、受信した情報を検証するURIにPOSTで送信される。

以下は、 リダイレクトURI応答の参考例である。 

GET /cb HTTP/1.1
Host: client.example.org

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

<script type="text/javascript">

// First, parse the query string
var params = {}, postBody = location.hash.substring(1),
    regex = /([^&=]+)=([^&]*)/g, m;
while (m = regex.exec(postBody)) {
  params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
}

// And send the token over to the server
var req = new XMLHttpRequest();
// using POST so query isn't logged
req.open('POST', 'https://' + window.location.host +
                 '/catch_response', true);
req.setRequestHeader('Content-Type',
                     'application/x-www-form-urlencoded');

req.onreadystatechange = function (e) {
  if (req.readyState == 4) {
    if (req.status == 200) {
// If the response from the POST is 200 OK, redirect the user
      window.location = 'https://'
        + window.location.host + '/redirect_after_login'
    }
// if the OAuth response is invalid, generate an error message
    else if (req.status == 400) {
      alert('There was an error processing the token')
    } else {
      alert('Something other than 200 was returned')
    }
  }
};
req.send(postBody);

 TOC 

2.3.  IDトークン

IDトークンは、認証イベントおよび他の要求されたクレームに関するクレームを含むセキュリティトークンである。 IDトークンはJSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT] として表される。 [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] 参照すること。
nonce
IDトークンを持つクライアントセッションを関連付けるためと、リプレイ攻撃を軽減するために使用される文字列値。 値は変更されずにそのまま認可要求からIDトークンへ渡されます。 ID Token (ID Token) 内に存在した場合、クライアントは nonce クレーム値が認可要求で送信したnonce パラメータの値と等しいかを検証しなければならない (MUST)。認可要求に存在する場合、認可サーバーは、認可要求で送信されたナンス値を nonce クレームの値としてID Token (ID Token)に含めなければならない (MUST)。インプリシットフローではnonceは必須である。コードフローでは任意である。
at_hash
インプリシットフローでIDトークンがaccess_tokenと共に発行される場合、必須。この値は、JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.) [JWS] ヘッダのalgパラメータの中で使用されているハッシュと同じ長さのSHA-2ファミリーのハッシュアルゴリズムを使用してaccess_tokenをハッシュ化することによって作成されたハッシュの左から半分をbase64urlエンコードすることによって生成される。例えば、algがHS256の場合、SHA-256でaccess_tokenをハッシュ化し、その左から128bitに対しbase64urlエンコードを行う。

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

IDトークンはJWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.) [JWS]によって署名されなければならない (MUST)。そして必要に応じてJWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.) [JWS] と JWE (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2012.) [JWE]を用いて署名と暗号化の両方をそれぞれ実施する。これによって、認証、完全性、否認防止、および必要に応じて機密性を提供する。

クライアントは、ID Token Verification (ID Token Verification)により、IDトークンの妥当性を直接検証しなければならない (MUST)。


 TOC 

2.4.  IDトークンの検証

認可応答におけるIDトークンの妥当性を検証するために、クライアントは以下を行わなければならない (MUST)。

  1. クライアントはaud (audience) クレーム内のclient_idが、iss (issuer)クレームの値によって識別される発行元が登録したものであることを検証する必要がある(MUST)。aud (audience)の値が発行元に対して有効でない場合は、IDトークンを拒絶しなければならない(MUST)。 (※訳注：client_idはIDトークンの発行元であるOpenIDプロバイダが個々のクライアントに対して払い出すため、クライアントが現在IDトークンをやり取りしているOpenIDプロバイダにとってのクライアント自身を表すclient_idが想定通りかどうかを検証するという意だと思われる。)
  2. クライアントは、JWTヘッダのalgパラメータに指定されたアルゴリズムを用いて、JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.) [JWS]に従ってIDトークンの署名を検証しなければならない (MUST)。
  3. algの値はRS256であるべきである (SHOULD)。他の署名アルゴリズムを用いたトークンの妥当性検証は、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]仕様に記述されている。
  4. クライアントは、発行元によるディスカバリの中で提供される署名キーを使用しなければならない (MUST)。発行元は、iss (issuer)クレームの値と正確に一致しなければならない。
  5. 現在の時刻は exp クレームの値より小さくなければならない。
  6. iat クレームは、攻撃対策のために保存しているナンスの保存時間の上限を制限するために、現在時刻からあまりにも大きく乖離しているときはトークンを拒絶したいといった場合に用いられることがある。 許容範囲は、クライアント次第である。
  7. nonceクレームの値は、認可要求で送信されたものと同じ値であることを検証するためにチェックしなければならない (MUST)。クライアントはリプレイ攻撃のためにnonce値をチェックすべきである (SHOULD)。リプレイ攻撃を検出するための詳細な方法は、クライアント固有のものである。
  8. acrクレームが要求された場合、クライアントは、主張されているクレームの値が適切であることを確認すべきである(SHOULD)。acrクレームの値の意味と処理は、この仕様の範囲外である。 （※訳注：acrの詳細は「OpenID Connect Messages 1.0」を参照）
  9. 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つのメソッドを使って送らなければなりません。
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 (Phillips, A. and M. Davis, "Tags for Identifying Languages," September 2009.) [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 if the End-User's e-mail address has been verified; otherwise 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)。 [OpenID.Registration]. ユーザ情報エンドポイントは、フォーマットを示すために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節で定義されているエラー応答を返す。 OAuthBearer].

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.
[JWE] Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2012.
[JWS] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.
[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.
[OAuth.Responses] de Medeiros, B., Scurtescu, M., and P. Tarjan, “OAuth 2.0 Multiple Response Type Encoding Practices,” May 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.Messages] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 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.Basic] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic 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 ]]

-02

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

-01

  • Removed claims_in_id_token scope value, per decision on June 15, 2012 special working group call

-00

  • Initial version, based upon Basic Client specification version -17
  • Renamed from Basic Client to Implicit Client, per issue #567
  • Changed verified to email_verified, per issue #564
  • Removed Check ID Endpoint and added ID token signature verification text, per issue #570
  • 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)


 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
  
  Edmund Jay
  Illumila
Email:  ejay@mgi1.com
投稿者 時刻:
ラベル: ,

0 件のコメント:

コメントを投稿

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