「OpenID Connect Dynamic Client Registration 1.0 - draft 11」も和訳してみました。 原文は http://openid.net/specs/openid-connect-registration-1_0.html です。
| TOC |
|
OpenID Connect
Dynamic Client Registration 1.0 - draft 11
概要
OpenID Connect 1.0は、OAuth 2.0上に作られたシンプルなアイデンティティ層である。そして、相互運用可能でRESTfulな方法により、エンドユーザに関する基本的なプロファイル情報の取得と同様に、認可サーバによる認証に基づくエンドユーザのアイデンティティの検証も、クライアントに対し可能とする。
この仕様は、OpenIDクライアントが、OpenID Connectプロトコル群で必要となるクライアントクレデンシャルを取得する方法について述べる。
目次
1.
はじめに
1.1.
要求記法および規則
1.2.
用語
2.
クライアント登録エンドポイント
2.1.
クライアント登録要求
2.1.1.
sector_identifier_url検証
2.2.
クライアント登録応答
2.2.1.
クライアントアソシエーションまたはシークレットローテーション応答
2.2.2.
クライアント更新
2.3.
クライアント登録エラー応答
3.
文字列操作
4.
IANAに関する考慮事項
5.
セキュリティに関する考慮事項
6.
規定文献
Appendix A.
謝辞
Appendix B.
通知
Appendix C.
文書履歴
§
著者アドレス
| TOC |
1. はじめに
ユーザに対しOpenIDサービスを提供するOpenID Connectクライアントは、クライアントIDと共有鍵を取得するために、OpenIDプロバイダに登録する必要がある。このドキュメントでは、新たなクライアントがどのようにプロバイダに登録することができ、またすでにclient_idを所有しているクライアントがどのように更新された登録情報を取得できるかについて述べている。
クライアント登録エンドポイントは、いくつかの配備で最適化の観点から、トークンエンドポイントと共存する可能性がある。
| 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.) [RFC2119]で述べられている通りに解釈されるべきものである。 .
本文書では、書いてあるままに解釈されるべき値は引用符 ("") で囲んで示している。プロトコルメッセージの中でこれらの値を使用する場合は、値の一部として引用符を用いてはならない (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]で定義されている、「アクセストークン」、「リフレッシュトークン」、「認可コード」、「認可グラント」、「認可サーバ」、「認可エンドポイント」、「クライアント」、「クライアント識別子」、「クライアントシークレット」、「保護リソース」、「リソース所有者」、「リソースサーバ」、「トークンエンドポイント」という用語と、OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2012.) [OpenID.Messages]で定義されている用語を用いる。追加の用語は定義していない。
| TOC |
2. クライアント登録エンドポイント
クライアント登録エンドポイントは、クライアントが自身の構成情報をOpenIDプロバイダに対し登録するためのOAuth2.0保護リソースである。OpenIDプロバイダは、登録されたクライアントのみに登録要求を制限するためにアウトオブバンドで（この仕様の範囲外のある方法で）プロビジョニングされたアクセストークンを要求する場合がある。
オープンな登録をサポートするために、クライアント登録ポイントは、OAuth 2.0アクセストークンなしでの要求を受け入れるべきである (SHOULD)。 アクセストークンがクライアントの登録に必要な場合、クライアント登録エンドポイントは、OAuth 2.0 Bearer Tokens (Jones, M., Hardt, D., and D. Recordon, “OAuth 2.0 Protocol: Bearer Tokens,” April 2012.) [OAuth.Bearer]仕様に記載の方法でアクセストークンを受け入れられなければならない (MUST)。
| TOC |
2.1. クライアント登録要求
クライアントは、 "application/x-www-form-urlencoded"形式でHTTP要求エンティティボディに以下のパラメータを追加し、POSTで要求を送信しなければならない (MUST)。
- type
- 必須。値は、client_associate （新規登録用）、rotate_secret （client_secretのローテーションを要求）、client_update （既存のclient_idのパラメータの更新用）。rotate_secretが使用された場合、 client_idとclient_secret以外のパラメータは要求に含まれているべきではない。
- client_id
- 任意。このclient_idの登録パラメータが更新される。client_updateと共に使用される。
- client_secret
- 任意。client_secretは、typeパラメータの値が、client_updateである要求を認証するために使用される。
- access_token
- 任意。登録を認可するアウトオブバンドで取得したアクセストークン。このパラメータは、クライアントがアウトオブバンドでアクセストークンを提供されている場合のみ使用される。OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2012.) [OAuth2.0]の7.1節での記述のとおり、アクセストークンをHTTP Authorizationヘッダで送る場合、このパラメータを送信してはならない (MUST NOT)。Authorizationヘッダ内のアクセストークンは、OAuth 2.0 Bearer Tokens (Jones, M., Hardt, D., and D. Recordon, “OAuth 2.0 Protocol: Bearer Tokens,” April 2012.) [OAuth.Bearer]でなければならない。
- contacts
- 任意。このクライアントの情報の管理を許可された人々のメールアドレスのスペース区切りのリスト。これは、クライアント情報の変更のためのウェブUIを有効にするために、いくつかのプロバイダによって使用される。
- application_type
- 任意。nativeまたはweb。
- application_name
- 任意。ユーザに提示するクライアントの名前。 必要に応じて、異なる言語、スクリプトの中でこのクレームの表現が、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2012.) [OpenID.Messages] の2.1.2.1.1.1.節の"claims"メンバでセットされたルールを適用することによって得られる。
- logo_url
- 任意。クライアントアプリケーションのロゴを参照するURL。
- redirect_uris
- クエリパラメータでエンコードされた応答と共にcodeフローを使用するクライアントでは推奨。OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2012.) [OAuth2.0]に定義されたインプリシットフローのフラグメントエンコードされた応答を要求するクライアントでは必須。リダイレクトURIのスペース区切りリスト。URLのいずれかが、認可要求の中のredirect_uriに対し、スキーム、ホスト、パス部分が一致しなければならない (MUST)。
- token_endpoint_auth_type
- 任意。トークンエンドポイントのために要求される認証タイプ。 オプションは、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2012.) [OpenID.Messages]の2.2.1節に記述されているclient_secret_post、client_secret_basic、client_secret_jwt、private_key_jwtである。他の認証方法は、拡張によって定義されるかもしれない。未指定または省略された場合、デフォルトは、OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2012.) [OAuth2.0]の2.3.1節に定義されたclient_secret_basic HTTP基本認証スキームである。
- policy_url
- 任意。プロファイルデータがどのように使用されるかについて、リライイングパーティクライアントがエンドユーザに示すためのURL。 指定された場合、OpenIDプロバイダは、エンドユーザにこのURLを表示すべきである (SHOULD)。
- jwk_url
- 任意。トークンエンドポイント要求とOpenID要求オブジェクトの署名に用いる、クライアントのJSON Web Key (Jones, M., “JSON Web Key (JWK),” May 2012.) [JWK]ドキュメントのURL。jwk_encryption_urlが提供されていない場合、クライアントへのIDトークンとユーザ情報エンドポイント応答の暗号化にも用いられる。クライアントがx509_urlとjwk_urlの両方を登録する場合、両方のフォーマットに含まれている鍵は同じでなければならない (SHOULD)。
- jwk_encryption_url
- 任意。クライアントへのIDトークンとユーザ情報エンドポイント応答の暗号化に用いる、クライアントのJSON Web Key (Jones, M., “JSON Web Key (JWK),” May 2012.) [JWK]のURL。クライアントがjwk_encryption_urlとx509_encryption_urlの両方を登録する場合、両方のフォーマットに含まれている鍵は同じでなければならない (SHOULD)。
- x509_url
- 任意。トークンエンドポイント要求とOpenID要求オブジェクトの署名に用いる、クライアントのPEMエンコードされたX.509証明書か証明書チェーンのURL。x509_encryption_urlが提供されていない場合、クライアントへのIDトークンとユーザ情報エンドポイント応答の暗号化にもx509_urlは用いられる。クライアントがx509_urlとjwk_urlの両方を登録する場合、両方のフォーマットに含まれている鍵は同じでなければならない (SHOULD)。
- x509_encryption_url
- 任意。クライアントへのIDトークンとユーザ情報エンドポイント応答の暗号化に用いる、クライアントのPEMエンコードされたX.590証明書か証明書チェーンのURL。クライアントがjwk_encryption_urlとx509_encryption_urlの両方を登録する場合、両方のフォーマットに含まれている鍵は同じでなければならない (SHOULD)。
- sector_identifier_url
- 任意。 OPによって仮名識別子を計算する際に用いられるHTTPSスキームのURL。このURLは、redirect_uri値を示すJSON配列が一つ含まれたファイルを示している。Section 2.1.1 (sector_identifier_url Verification)を参照。
- user_id_type
- 任意。このclient_idへの応答に用いるよう要求されたuser_id_type。ディスカバリのuser_id_types_supported要素は、このサーバーでサポートされているuser_id_type値のリストが含まれている。有効なタイプはpairwiseとpublic。
- require_signed_request_object
- 任意。認可サーバによって要求されなければならない (MUST)、JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.) [JWS] alg アルゴリズム [JWA] (Jones, M., “JSON Web Algorithms,” May 2012.)。有効な値は、JWA (Jones, M., “JSON Web Algorithms,” May 2012.) [JWA]の3.1節にリストされている。このアルゴリズムで署名されていない場合、このclient_idからのすべてのOpenID要求オブジェクトは拒否されなければならない (MUST)。サーバはRS256サポートすべきである (SHOULD)。
- userinfo_signed_response_alg
- 任意。ユーザ情報応答の署名に要求されるJWS algアルゴリズム[JWA] (Jones, M., “JSON Web Algorithms,” May 2012.)。有効な値は、JWA (Jones, M., “JSON Web Algorithms,” May 2012.) [JWA]の3.1節にリストされている。これが指定されていた場合、応答はJWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT]によってシリアライズされ、JWSによって署名される。
- userinfo_encrypted_response_alg
- 任意。ユーザ情報応答の暗号化に要求されるJWE (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2012.) [JWE] algアルゴリズム[JWA] (Jones, M., “JSON Web Algorithms,” May 2012.)。有効な値は、JWA (Jones, M., “JSON Web Algorithms,” May 2012.) [JWA]の3.1節にリストされている。応答への署名と共に要求された場合、暗号化の後に署名される。これが指定されていた場合、応答はJWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT]によってシリアライズされ、JWEによって暗号化される。
- userinfo_encrypted_response_enc
- 任意。ユーザ情報応答の対称鍵暗号化に必要なJWE encアルゴリズム[JWA] (Jones, M., “JSON Web Algorithms,” May 2012.)。有効な値は、JWA (Jones, M., “JSON Web Algorithms,” May 2012.) [JWA]の3.1節にリストされている。"userinfo_encrypted_response_alg"が指定されている場合、この値のデフォルトはA128CBCである。応答への署名と共に要求された場合、暗号化の後に署名される。これが指定されていた場合、応答はJWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT]によってシリアライズされ、JWEによって暗号化される。
- userinfo_encrypted_response_int
- 任意。ユーザ情報応答の完全性に必要なJWE intアルゴリズム[JWA] (Jones, M., “JSON Web Algorithms,” May 2012.)。有効なHMAC値は、JWA (Jones, M., “JSON Web Algorithms,” May 2012.) [JWA]の4.3節にリストされている。"userinfo_encrypted_response_alg"が指定され、"userinfo_encrypted_response_enc"がAEADアルゴリズムでなかった場合、この値のデフォルトはHS256である。応答への署名と共に要求された場合、暗号化の後に署名される。これが指定されていた場合、応答はJWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT]によってシリアライズされ、JWEによって暗号化される。
- id_token_signed_response_alg
- 任意。このclient_idに対し発行するIDトークンの署名に必要なJWS algアルゴリズム[JWA] (Jones, M., “JSON Web Algorithms,” May 2012.)。有効な値は、JWA (Jones, M., “JSON Web Algorithms,” May 2012.) [JWA]の3.1節にリストされている。指定されていない場合のデフォルトはRS256である。署名を検証するための公開鍵は、ディスカバリの時のjwk_url要素またはx509_url要素からドキュメントを取得することによって得られる。
- id_token_encrypted_response_alg
- 任意。このclient_idに対し発行するIDトークンの暗号化に必要なJWE algアルゴリズム[JWA] (Jones, M., “JSON Web Algorithms,” May 2012.)。有効な値は、JWA (Jones, M., “JSON Web Algorithms,” May 2012.) [JWA]の3.1節にリストされている。これが要求された場合、応答は暗号化の後に署名される。指定されていない場合、デフォルトでは暗号化しない。
- id_token_encrypted_response_enc
- 任意。このclient_idに対し発行するIDトークンの対称鍵暗号化に必要なJWE encアルゴリズム[JWA] (Jones, M., “JSON Web Algorithms,” May 2012.)。有効な値は、JWA (Jones, M., “JSON Web Algorithms,” May 2012.) [JWA]の3.1節にリストされている。"id_token_encrypted_response_alg"が指定されている場合、この値のデフォルトはA128CBCである。応答への署名と共に要求された場合、暗号化の後に署名される。これが指定されていた場合、応答はJWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT]によってシリアライズされ、JWEによって暗号化される。
- id_token_encrypted_response_int
- 任意。このclient_idに対し発行するIDトークンの完全性に必要なJWE intアルゴリズム[JWA] (Jones, M., “JSON Web Algorithms,” May 2012.)。有効なHMAC値は、JWA (Jones, M., “JSON Web Algorithms,” May 2012.) [JWA]の4.3節にリストされている。"id_token_encrypted_response_alg"が指定され、"id_token_encrypted_response_enc"がAEADアルゴリズムでなかった場合、この値のデフォルトはHS256である。応答への署名と共に要求された場合、暗号化の後に署名される。これが指定されていた場合、応答はJWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT]によってシリアライズされ、JWEによって暗号化される。
- default_max_age
- 任意。（デフォルトの最大認証期限）: 型:整数 - 全ての既存の認証が、指定した秒数よりも古い場合、エンドユーザーを積極的に認証する必要があることを示す。（max_age要求パラメータはOpenID 2.0 PAPE max_auth_age要求パラメータに対応している。） 要求オブジェクト内のmax_ageクレームは、このデフォルト値を上書きする。
- require_auth_time
- 任意。（デフォルトの最大認証期限（※訳注：「（デフォルトの）auth_timeの有無」か何かの誤りと思われる））: 型:論理 - 値がtrueの場合、id_token内のauth_timeクレームは必須である (REQUIRED)。返されたクレームの値は、UTCの1970-01-01T0:0:0Zから、エンドユーザー認証が発生した日時までの秒数である。（auth_timeクレームは、意味的にはOpenID 2.0 PAPE auth_time応答パラメータに対応する。） 要求オブジェクト内のauth_timeクレーム要求は、この設定を上書きします。
- default_acr
- 任意。（デフォルトの認証コンテキストクラス参照）: 型:文字列 - 認可サーバが、このクライアントからの要求を処理するために使用しなければならないデフォルトの値を示す。ディスカバリのacrs_supported要素は、このサーバでサポートされているacr値のリストが含まれている。要求オブジェクト内のacrクレームは、このデフォルト値を上書きする。
クライアント登録エンドポイントは、認可されたクライアントのみに登録要求を制限するため、アクセストークンを必要とするかもしれないOAuth 2.0保護リソースである。クライアント登録エンドポイントがアクセストークンを必要とする場合、OAuth 2.0 Bearer Tokens (Jones, M., Hardt, D., and D. Recordon, “OAuth 2.0 Protocol: Bearer Tokens,” April 2012.) [OAuth.Bearer]のアクセストークンを受け入れるべきである (SHOULD)。
以下は、要求の参考例である（表示上だけの行折り返りを含む）:
POST /connect/register HTTP/1.1 Accept: application/x-www-form-urlencoded Host: server.example.com Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X type=client_associate &redirect_uris=https://client.example.org/callback %20https://client.example.org/callback2 &logo_url=https://client.example.org/logo.png &user_id_type=pairwise §or_identifier_url= https://othercompany.com/file_of_redirect_uris_for_our_sites.js &token_endpoint_auth_type=client_secret_basic &jwk_url=https://client.example.org/my_rsa_public_key.jwk &userinfo_encrypted_response_alg=RSA1_5 &userinfo_encrypted_response_enc=A128CBC &userinfo_encrypted_response_int=HS256
| TOC |
2.1.1. sector_identifier_url検証
pairwiseのuser_id値を使用するプロバイダは、この要素をサポートすべきである (SHOULD)。
個々のドメイン名から独立して、pairwiseのuser_id値の一貫性を、単一の管理下にあるウェブサイトのグループに提供する。また、彼らの持つすべてのユーザーについて再登録なしで、redirect_uriドメインを変更するための方法も提供する。
OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2012.) [OpenID.Messages]の2.4.1節に詳細を記載している。
sector_identifier_urlの値は、redirect_uri値の配列が含まれたJSONファイルを示すHTTPSスキームのURLでなければならない。クライアントは、RFC 6125 (Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March 2011.) [RFC6125]に従って、TLS/SSLサーバ証明書の確認を行わなければならない (MUST)。
登録されたredirect_urisの値は、配列の要素に含まれている必要があるか、または登録失敗としなければならない (MUST)。
GET /connect/sector_identifier.js HTTP/1.1 Accept: application/json Host: client.example.org HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store Pragma: no-cache [ "https://client.example.org/callback", "https://client.example.org/callback2", "https://client.other_company.example.net/callback" ]
| TOC |
2.2. クライアント登録応答
応答は、トップレベルの要素として、すべてのパラメータを持つJSONオブジェクトとして返される。
| TOC |
2.2.1. クライアントアソシエーションまたはシークレットローテーション応答
リクエストのtypeの値が、client_associateまたはrotate_secretの場合、以下を返します。
- client_id
- 必須。一意なクライアント識別子。
- client_secret
- 必須。クライアントシークレット。これは、client_id毎に一意でなければならない (MUST)。
- expires_at
- 必須。client_idおよびclient_secretの有効期限を示す、UTCの1970-01-01T0:0:0Zからの秒数、または有効期限がない場合は0。一般に日時についての詳細、特にUTCに関しては、RFC 3339 (Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.) [RFC3339] 参照すること。
以下は、 応答の参考例である:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"client_id":"s6BhdRkqt3",
"client_secret":
"cf136dc3c1fd9153029bb9c6cc9ecead918bad9887fce6c93f31185e5885805d",
"expires_at":2893276800
}| TOC |
2.2.2. クライアント更新
要求の型の値がclient_updateであった場合。
- client_id
- 必須。一意なクライアント識別子。
以下は、 応答の参考例である:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"client_id":"s6BhdRkqt3"
}| TOC |
2.3. クライアント登録エラー応答
エラー条件が発生した場合、クライアント登録エンドポイントは、OAuth 2.0 Bearer Tokens (Jones, M., Hardt, D., and D. Recordon, “OAuth 2.0 Protocol: Bearer Tokens,” April 2012.) [OAuth.Bearer]仕様の3節に定義されたエラー応答を返す。
OAuth 2.0 Bearer Tokens (Jones, M., Hardt, D., and D. Recordon, “OAuth 2.0 Protocol: Bearer Tokens,” April 2012.) [OAuth.Bearer]の3.1節に定義されたエラーコードに加え、この仕様では以下のエラーコードを定義する:
- invalid_type
- typeの値が無効またはサポートされていない。
- invalid_client_id
- client_idの値が無効である。
- invalid_client_secret
- client_updateのために提供されたclient_secretが、提供されたclient_idに対し無効である。
- invalid_configuration_parameter
- 構成パラメータのいずれかの値が無効である。
以下は、 エラー応答の参考例である:
HTTP/1.1 400 Bad Request WWW-Authenticate: Bearer realm="example.com", error="invalid_client_secret", error_description="The client_secret is wrong for this client_id"
| TOC |
3. 文字列操作
いくつかのOpenID Connectメッセージを処理すると、既知の値とメッセージの値を比較する必要がある。たとえば、クライアント登録応答のメンバ名は、client_idなどの特定のメンバ名と比較されることがある。しかし、Unicode文字列を比較すると、重要なセキュリティ上の影響がある。
そのため、JSON文字列や他のUnicode文字列の比較は以下のように実施しなければならない (MUST):
- Unicodeコードポイントの配列を生成するエスケープが適用されているJSONを削除する。
- Unicode Normalization (Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” 09 2009.) [USA15] は、JSON文字列とその比較対象の文字列のいずれにも適用されない (MUST NOT)。
- 二つの文字列の比較は、Unicodeコードポイントとしての等価比較を行わなければならない (MUST)。
いくつかの場所で、この仕様は、文字列のスペース区切りリストを使用します。 全てのそのようなケースで、ASCII空白文字(0x20)のみが、この目的のために使用されるかもしれません (MAY)。
| TOC |
4. IANAに関する考慮事項
この文書ではIANAへの要求はない。
| TOC |
5. セキュリティに関する考慮事項
クライアント登録エンドポイントへの要求は（HTTP要求と応答での）クリアテキストのクレデンシャルの送信となるため、登録エンドポイントへの要求送信の際、サーバーはトランスポート層セキュリティ機構の使用を必須としなければならない (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)。TLSを用いる場合、クライアントは、RFC 6125 (Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March 2011.) [RFC6125]に従って、TLS/SSLサーバ証明書の確認を行わなければならない (MUST)。
client_updateのための登録エンドポイントへの要求は、繰り返しのアクセス試行によるクライアントシークレットの探索を防ぐため、時間当たりの試行失敗回数に制限を持たせなければならない (MUST)。
認可サーバーがオープンクライアント登録をサポートしている場合、ユーザに表示するクライアント提供のURL（例えばlogo_urlとpolicy_url）に関して、非常に慎重に取り扱わなければならない。不正なクライアントが、policy_urlでドライブバイダウンロードへの参照を登録要求に指定することがありうる。認可サーバーは、logo_urlとpolicy_urlのホストがredirect_urisの配列内で定義されているホストと同じであるかを検証すべきである。
| TOC |
6.規定文献
| TOC |
Appendix A. 謝辞
| 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 ]]
-11
- Made rotate_secret a separate registration request type and stop client secret changing with every response, per issue #363
- Changed default ID Token signing algorithm to RS256, per issue #571
- Changed client.example.com to client.example.org, per issue #251
- Added text for authz to the registration endpoint, per issue #587
- Use standards track version of JSON Web Token spec (draft-ietf-oauth-json-web-token)
-10
- Split encrypted response configurations into separate parameters for alg, enc, int
- Removed extra "s" from signed response parameter names
- Add reference to JWA
- Updated Notices
- Updated References
-09
- Removed erroneous spanx declarations from example
- Fixed example in Sec 2.2 to show expires_at
- Fixed Sec 2.1.1 to clarify it is the registration server doing the certificate check
- Fixed Sec 2.1.1 example to include http portion of response
- Fixed #542 Sec 2.1 userinfo_signed_response_algs fixed to say signature. Clarify response is signed.
- Fixed Sec 2.1 userinfo_encrypted_response_algs Clarify response is JWE containing JWT
- Fixes #529 Sec 2.3 Clarify error response is Bearer and fix example
- Add default_max_age registration parameter
- Add default_acr registration parameter
- Add require_auth_time registration parameter
-08
- Replaced token_endpoint with a defined term Token Endpoint [OAuth 2.0]
- Added policy_url parameter
- Renamed expires_in but expires_at
- Registration Endpoint can be OAuth Protected
- Added parameters for requiring encryption and/or signing of OpenID Request Object, UserInfo and ID Token
- Added token_endpoint_auth_type and list of valid authentication types
- Added JWK and X509 URLs for signature and encryption
- Added user_id_type
- Changed sector_identifier to sector_identifier_url and added URL verification
- Use RFC 6125 to verify TLS endpoints
- Changed 'contact' to 'contacts', 'redirect_uri' to 'redirect_uris'
- Changed redirect_uris to RECOMMENDED for code flow and REQUIRED for implicit flow Clients
- Removed js_origin_uri
- Added section about string comparison rules needed
- Clarified redirect_uris matching
- Update John Bradley email and affiliation for Implementer's Draft
-07
- Changed request from posting a JSON object to being HTTP Form encoded.
- Added x509_url to support optional encryption.
-06
- Changes associated with renaming "Lite" to "Basic Client" and replacing "Core" and "Framework" with "Messages" and "Standard".
- Numerous cleanups, including updating references.
-05
- Changed redirect_url to redirect_uri and js_origin_url to js_origin_uri.
-04
- Correct issues raised by Johnny Bufu and discussed on the 7-Jul-11 working group call.
-03
- Incorporate working group decisions from 5-Jul-11 spec call.
- Consistency and cleanup pass, including removing unused references.
-02
- Incorporate working group decisions from 23-Jun-11 spec call.
-01
- Initial version.
| 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 |
