「OpenID Connect Discovery 1.0 - draft 09」も和訳してみました。 原文は http://openid.net/specs/openid-connect-implicit-1_0.html です。
| TOC |
|
OpenID Connect Discovery 1.0 - draft 09
概要
OpenID Connect 1.0は、OAuth 2.0上に作られたシンプルなアイデンティティ層である。そして、相互運用可能でRESTfulな方法により、エンドユーザに関する基本的なプロファイル情報の取得と同様に、認可サーバによる認証に基づくエンドユーザのアイデンティティの検証も、クライアントに対し可能とする。
この仕様は、OpenID Connectプロトコル群によって使用される必要なエンドポイントと同様に、OpenID ConnectクライアントがユーザのOpenIDプロバイダを発見するための機構を提供する。
目次
1.
はじめに
1.1.
要求記法および規則
1.2.
用語
2.
プロバイダディスカバリ
2.1.
識別子の正規化
2.1.1.
識別子のタイプ
2.1.2.
メールアドレス
2.1.3.
URL
2.2.
参考例
2.2.1.
メールアドレス
2.2.2.
URL
2.2.3.
ホスト名とポート
2.3.
リダイクレション
3.
プロバイダ構成情報
3.1.
プロバイダ構成要求
3.2.
プロバイダ構成応答
3.3.
プロバイダ構成検証
4.
文字列操作
5.
IANAに関する考慮事項
6.
セキュリティに関する考慮事項
7.
文献
7.1.
規定文献
7.2.
参考文献
Appendix A.
謝辞
Appendix B.
通知
Appendix C.
文書履歴
§
著者アドレス
| TOC |
1. はじめに
ユーザーに対しOpenID Connectサービスを利用させるためには、OpenIDクライアントはOpenIDプロバイダがどこにあるかを知っている必要がある。OpenID Connectは、エンドユーザが利用するOpenIDプロバイダの場所を探すためにSimple Web Discovery (Jones, M. and Y. Goland, “Simple Web Discovery,” December 2011.) [SWD]を用いる。
OpenIDプロバイダが識別されると、そのOPのエンドポイントおよびその他の構成情報は、JSONドキュメントのためのウェルノウンロケーションから取得される。
| 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]で定義されている、「アクセストークン」、「リフレッシュトークン」、「認可コード」、「認可グラント」、「認可サーバ」、「認可エンドポイント」、「クライアント」、「クライアント識別子」、「クライアントシークレット」、「保護リソース」、「リソース所有者」、「リソースサーバ」、「トークンエンドポイント」という用語と、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]で定義されている用語をを用いる。また当仕様では、以下の用語についても定義する。
- 主体 (Principal)
- Simple Web Discoveryの要求のターゲットであるエンティティ。
- 識別子 (Identifier)
- 識別子はhttpまたはhttps URI （一般に、この文書の範囲ではURLとも呼ばれる）、またはアカウントのURIである。 このドキュメントでは、異なるコンテキストで使用するために設計された様々な種類の識別子を定義する。
| TOC |
2. プロバイダディスカバリ
OpenIDプロバイダのディスカバリはオプションである。リライイングパーティは、アウトオブバンド機構を介してOPの情報を知っていれば、このステップをスキップしてSection 3 (Provider Configuration Information)に進むことができる。
プロバイダディスカバリは、ディスカバリの要求を行うため、次の情報が必要である。
- 主体 (Principal)
- ディスカバリ要求の対象であるエンドユーザの識別子
- ホスト (Host)
- Simple Web Discoveryサービスがホストされているサーバ
- サービス (Service)
- ロケーションを要求されたサービスのタイプを識別するURI
OpenID ConnectはSimple Web Discovery (Jones, M. and Y. Goland, “Simple Web Discovery,” December 2011.) [SWD]の中で下記のサービスタイプを利用する。
| Service Type | URI |
|---|---|
| OpenID Connect Issuer | http://openid.net/specs/connect/1.0/issuer |
OpenIDエンドポイントのディスカバリを開始するには、エンドユーザがクライアントまたはリライイングパーティに識別子を提供する。クライアントは主体とホストを抽出するために識別子に正規化ルールを適用する。そして、要求されたサービスのロケーションを取得するためにprincipalとserviceパラメータと共に、ホストのSimple Web Discovery (Jones, M. and Y. Goland, “Simple Web Discovery,” December 2011.) [SWD]エンドポイントに対し、HTTPS要求を行う。クライアントは、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)。
応答で必ず返さなければならない (MUST) のはissuerである。これには、URIスキーム、ホスト、および任意でポートが含まれている。
| TOC |
2.1. 識別子の正規化
正規化の目的は、ユーザ入力から正規化されたプリンシパルとホストを抽出することである。そして、これはissuerを発見するためにSWDへの入力として使用される。
ユーザ識別子は、次のいずれかである。
- メールアドレス
- URL
識別子の正規化ルールは、電話番号やXRIs (Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” November 2005.) [XRI_Syntax_2.0]のような、他の種類の識別子を有効にする追加仕様によって拡張されるかもしれない (MAY)。
"host"部分なしのURLはこの仕様ではサポートされない。
| TOC |
2.1.1. 識別子のタイプ
- XRI (Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” November 2005.) [XRI_Syntax_2.0] のグローバルコンテキストシンボル('='、'@'、'!')で始まる識別子は予約されている (RESERVED)。 これらの識別子の処理はこの仕様の範囲外である。
- 先頭以外の位置に '@'文字を含んでいる任意の識別子は、メールアドレスとして扱わなければならない (MUST)。
- 他のすべての識別子はURLとして扱わなければならない。'@'を含むURLは、'@'を全て%40とエスケープしなければならない。
| TOC |
2.1.2. メールアドレス
メールアドレス構文を用いた識別子は、RFC 5322 (Resnick, P., Ed., “Internet Message Format,” October 2008.) [RFC5322]の"addr-spec"構文に従わなければならない (MUST)。そして、その仕様は廃止されたものとして、その仕様で規定されたその他の構文は含んでいてはならない (MUST NOT)。識別子がメールアドレスの場合、SWDの主体の値はメールアドレス全体であり、SWDのホストの値は、 "addr-spec"の "domain"部分である。
| TOC |
2.1.3. URL
URL識別子は、次の規則に従って正規化される:
- URLにRFC 3986 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [RFC3986]の"scheme"部分が含まれていなかった場合、"https"スキームがURLのプリフィックスとなる。"scheme"部分は、"://"を区切り文字として"authority"部分と分離されている。
- URLにフラグメント部分が含まれている場合は、フラグメントの区切り文字"#"と共に取り除かなければならない (MUST)。
- 結果のURLは、SWDの主体として使用される。SWDのホスト値は、 RFC 3986 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [RFC3986]で定義されているURLの"authority"部分に含まれる"host"と"port"部分をコロン(':')を区切り文字として結合することで抽出できる。参考例については、Section 2.2.3 (Hostname & Port) 節を参照。
| TOC |
2.2. 参考例
| TOC |
2.2.1. メール アドレス:
joe@example.comというメールアドレスからissuerを探すためのSWD パラメータは以下のとおりである:
| SWDパラメータ | 値 |
|---|---|
| principal | joe@example.com |
| host | example.com |
| service | http://openid.net/specs/connect/1.0/issuer |
SWD仕様に従ってディスカバリ情報を取得するために、クライアントは以下の要求を行います （表示目的のためだけに行の折り返しをしている）:
GET /.well-known/simple-web-discovery?principal=joe%40example.com &service=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1 Host: example.com HTTP/1.1 200 OK Content-Type: application/json { "locations":["https://server.example.com"] }
| TOC |
2.2.2. URL
https://example.com/joeというURLからissuerを探すためのSWD パラメータは以下のとおりである:
| SWDパラメータ | 値 |
|---|---|
| principal | https://example.com/joe |
| host | example.com |
| service | http://openid.net/specs/connect/1.0/issuer |
SWD仕様に従ってディスカバリ情報を取得するために、クライアントは以下の要求を行います （表示目的のためだけに行の折り返しをしている）:
GET /.well-known/simple-web-discovery ?principal=https%3A%2F%2Fexample.com%2Fjoe &service=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1 Host: example.com HTTP/1.1 200 OK Content-Type: application/json { "locations":["https://server.example.com"] }
| TOC |
2.2.3. ホスト名とポート
example.com:8080というホスト名からissuerを探すためのSWD パラメータは以下のとおりである:
| SWDパラメータ | 値 |
|---|---|
| principal | https://example.com:8080/ |
| host | example.com:8080 |
| service | http://openid.net/specs/connect/1.0/issuer |
SWD仕様に従ってディスカバリ情報を取得するために、クライアントは以下の要求を行います （表示目的のためだけに行の折り返しをしている）:
GET /.well-known/simple-web-discovery ?principal=https%3A%2F%2Fexample.com%3A8080%2F &service=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1 Host: example.com:8080 HTTP/1.1 200 OK Content-Type: application/json { "locations":["https://server.example.com"] }
| TOC |
2.3. リダイクレション
SWD要求がエンドユーザの識別子から導出したホストやロケーション以外で処理する場合には、ホストは新しいロケーションを含むJSONオブジェクトを返す。(サービスリダイレクションのサポートは、Simple Web Discovery (Jones, M. and Y. Goland, “Simple Web Discovery,” December 2011.)の必須機能である） [SWD].)
サービスレベルリダイレクションを有効にするために、SWDサーバは、HTTPS要求に対し、application/jsonというコンテントタイプ（またはネゴシエートされた他の任意のコンテントタイプ）と共に200 OKを返すかもしれない (MAY)。この応答は、名前がlocation、値がエンコードされたURIというメンバを含むJSONオブジェクトを値として持つSWD_service_redirectという名前のメンバを含むJSONオブジェクトとなる。必要に応じて、SWD_service_redirectのJSONオブジェクトの値は、整数をエンコードしたJSON数値を値として持つexpireという名前のメンバを含むかもしれない (MAY)。
locaitonメンバは、expiresで示された時間になるまで、そのドメイン宛てのすべてのSWD要求を呼出し元はリダイレクトしなければならない(MUST)ということを示すURIである。リダイレクトドメイン宛てのSWD要求は、 locationで示されたURIをベースURIとし、それに対し、SWDの引数をクエリパラメータとして追加することによって構築しなければならない (MUST)。locationで示されたURIは、クエリコンポーネントを含んでいてはならない (MUST NOT)。
GET /.well-known/simple-web-discovery?principal=joe%40example.com &service=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1 Host: example.com HTTP/1.1 200 OK Content-Type: application/json { "SWD_service_redirect": { "location":"https://example.net/swd_server" } } GET /swd_server?principal=joe%40example.com &service=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1 Host: example.net HTTP/1.1 200 OK Content-Type: application/json { "locations":["https://server.example.com"] }
| TOC |
3. プロバイダ構成情報
この手順は任意である。OpenIDプロバイダのエンドポイントおよび構成情報は、アウトオブバンドで取得することもありうる。
Section 2 (Provider Discovery)によるディスカバリか、設定で直接取得したissuerを用いて、OpenIDプロバイダの構成を取得することができる。
OpenIDプロバイダは、 issuerに/.well-known/openid-configurationを連結することで得られるパスで利用可能な、JSONドキュメントを作成する必要がある (MUST)。.well-knownの構文と意味は、RFC 5785 (Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known Uniform Resource Identifiers (URIs),” April 2010.) [RFC5785]で定義されている。 openid-configurationは、この仕様とJSONドキュメントに準拠して示す必要がある。
OpenIDプロバイダは、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.)経由のSWD要求受信をサポートしなければならない(MUST)。また、同等のセキュリティを持つ、他のトランスポート層セキュリティ機構をサポートしてもよい (MAY)。
| TOC |
3.1. プロバイダ構成要求
OpenIDプロバイダの構成文書は、事前に指定したパスにHTTPS GET要求を使用して照会しなければならない (MUST)。 クライアントは、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)。
issuerにパスコンポーネントが含まれていない場合、クライアントは、構成情報を取得するためにissuerに対し、以下の要求を行う。
GET /.well-known/openid-configuration HTTP/1.1 Host: example.com
issuerの値にパスコンポーネントが含まれていた場合、/.well-known/openid-configurationを追加する前に終端の/を取り除かなければならない (MUST)。issuerがhttps://example.com/issuer1の場合、クライアントは、構成情報を取得するためにissuerに対し、以下の要求を行う。
GET /issuer1/.well-known/openid-configuration HTTP/1.1 Host: example.com
| TOC |
3.2. プロバイダ構成応答
応答は、全ての必要なエンドポイント、サポートされているスコープ、公開鍵のロケーションなどを含む、OpenIDプロバイダの構成に関するクレームのセットである。
応答は、以下に定義されているもののサブセットであるクレームセットを含むプレーンテキストのJSONオブジェクトを返さなければならない (MUST)。
複数の値を返すクレームはJSONの配列である。要素数が0のクレームは、応答から省略する必要がある。
他のクレームが、返される可能性もある (MAY)。
| 表1: 予約済みクレームの定義 |
応答例:
{ "authorization_endpoint": "https://server.example.com/connect/authorize", "issuer": "https://server.example.com", "token_endpoint": "https://server.example.com/connect/token", "token_endpoint_auth_types_supported": ["client_secret_basic", "private_key_jwt"], "userinfo_endpoint": "https://server.example.com/connect/user", "refresh_session_endpoint": "https://server.example.com/connect/refresh_session", "end_session_endpoint": "https://server.example.com/connect/end_session", "jwk_url": "https://server.example.com/jwk.json", "registration_endpoint": "https://server.example.com/connect/register", "scopes_supported": ["openid", "profile", "email", "address", "phone"], "response_types_supported": ["code", "code id_token", "token id_token"], "acrs_supported": ["1","2","http://id.incommon.org/assurance/bronze"], "user_id_types_supported": ["public", "pairwise"], "userinfo_algs_supported": ["HS256", "RS256", "A128CBC", "A128KW", "RSA1_5"], "id_token_algs_supported": ["HS256", "RS256", "A128CBC", "A128KW", "RSA1_5"], "request_object_algs_supported": ["HS256", "RS256", "A128CBC", "A128KW", "RSA1_5"] }
| TOC |
3.3. プロバイダ構成検証
構成応答にissuer要素が含まれていた場合、値は、構成を取り出すのに直接用いられたURLのissuerと正確に一致しなければならない (MUST)。検出プロセスは複数レベルのredirection (Redirection)を許可するため、このissuerのURLは、初めにディスカバリのプロセスを開始したときのものとは異なることもあり得る。
| TOC |
4. 文字列操作
いくつかのOpenID Connectメッセージを処理すると、既知の値とメッセージの値を比較する必要がある。たとえば、プロバイダ構成応答のメンバ名は、issuerなどの特定のメンバ名と比較されることがある。しかし、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 |
5. IANAに関する考慮事項
RFC 5785 (Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known Uniform Resource Identifiers (URIs),” April 2010.) [RFC5785]に従い、以下の登録が要求される:
- URIサフィックス
- openid-configuration
- 変更制御者
- OpenID Foundation
- 仕様書
- 当ドキュメント
| TOC |
6. セキュリティに関する考慮事項
未定
| TOC |
7. References
| TOC |
7.1. 規定文献
| TOC |
7.2. 参考文献
| [XRI_Syntax_2.0] | Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” November 2005 (HTML, PDF). |
| 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 ]]
-09
- Removed Check ID Endpoint, per issue #570
- Added PAPE Reference to the Informative References, per issue #574
- Added "id_token" response type as being MTI for OpenID Providers
- Changed default OpenID Request Object signing algorithm to RS256, per issue #571
- Use standards track version of JSON Web Token spec (draft-ietf-oauth-json-web-token)
-08
- Remove the no path component restriction from issuer, per issue #513
- Updated Notices
- Updated References
-07
- Rename iso29115_supported to acrs_supported
- Rename jwk_document to jwk_url
- specify full email address to be used for the principal parameter
- Added token_endpoint_auth_types_supported for list of Token Endpoint authentication types
- Added token_endpoint_auth_algs_supported for Token Endpoint supported authentication algorithms
- Added 'pairwise' and 'public' to supported identifier types
- Added valid signature and encryption algorithms for OpenID Request Object
- Added URLs for JWK and X509 encryption keys
- Use RFC 6125 to verify TLS endpoints
- Removed fallback mechanism when discovery endpoint is unreachable
- Removed Account URI scheme
- Changed 'contact' to 'contacts', 'redirect_uri' to 'redirect_uris'
- Added section about string comparison rules needed
- Allows extensions to identifier normalization via specifications
- Clarifies the host in a URL
- Update John Bradley email and affiliation for Implementer's Draft
- Change flows_supported to response_types_supported
- Register openid-configuration .well-known path in IANA Considerations
- Corrected instances of x509_url_encryption to x509_encryption_url and jwk_url_encryption to jwk_encryption_url
-06
- Changed Check Session Endpoint to Check ID Endpoint to match Basic.
- Changed certs_url to x509_url to match registration and JWE format.
-05
- Ticket #46 Added text to 3.3
- Deleted duplicate check session endpoint from 4.2
- Ticket #40 Added clarification of issuer url to 4.2
- Ticket #39 Cleaned up issuer examples and added verification text.
-04
- Changes associated with renaming "Lite" to "Basic Client" and replacing "Core" and "Framework" with "Messages" and "Standard".
- Numerous cleanups, including updating references.
-03
- Corrected examples.
-02
- Correct issues raised by Johnny Bufu and discussed on the 7-Jul-11 working group call.
-01
- Incorporate working group decisions from 5-Jul-11 spec call.
- Consistency and cleanup pass, including removing unused references.
-00
- Initial version based upon former openid-connect-swd-1_0 spec.
| 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 |
| Edmund Jay | |
| Illumila | |
| Email: | ejay@mgi1.com |
0 件のコメント:
コメントを投稿