identity 1.0 documentation

OpenID Connect Discovery 1.0

«  OpenID Connect Dynamic Client Registration 1.0   ::   Contents   ::   OpenID Connect Session Management 1.0  »

OpenID Connect Discovery 1.0

Based on OpenID Connect Discovery 1.0 - draft 17 ( July 5, 2013 )

Abstract

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and RESTful manner.

This specification provides a mechanism for the OpenID Connect client to discover the user‘s OpenID Provider as well as the necessary endpoints used by the OpenID Connect protocol suite.

Note

  • May 25, 2012, Draft 09 is available

1. Introduction

In order for an OpenID Client to utilize OpenID Connect services for a user, the Client needs to know where the OpenID Provider is. OpenID Connect uses Simple Web Discovery [SWD] to locate the OpenID Provider for an End-User.

Once an OpenID Provider is identified, the endpoint and other configuration information for that OP is retrieved from a well-known location as a JSON document.

(draft 07, Dec ,22, 2011)

1.1. Requirements Notation and Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 [RFC2119].

Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.

(Draft 07, Dec 22,2011 )

1.2. Terminology

This specification uses the terms “Access Token”, “Refresh Token”, “Authorization Code”, “Authorization Grant”, “Authorization Server”, “Authorization Endpoint”, “Client”, “Client Identifier”, “Client Secret”, “Protected Resource”, “Resource Owner”, “Resource Server”, and “Token Endpoint” defined by OAuth 2.0 [OAuth2.0], and the terms defined by OpenID Connect Messages 1.0 [OpenID.Messages]. This specification also defines the following terms:

Principal
An Entity that is the target of a request in Simple Web Discovery.
Identifier
An Identifier is either an http or https URI (commonly referred to as a URL within this document), or an account URI. This document defines various kinds of Identifiers, designed for use in different contexts.

(draft 07, Dec 22,2011 )

2. OpenID Provider Discovery

OpenID Provider discovery is OPTIONAL; if a Relying Party knows the OP information through an out-of-band mechanism, they can skip this step and proceed to Section 4.

Provider discovery requires the following information to make a discovery request:

resource
Identifier of the target End-User that is the subject of the discovery request.
host
Server where a WebFinger service is hosted.
rel
URI identifying the type of service whose location is requested.

OpenID Connect uses the following discoverable rel value in WebFinger [I‑D.ietf‑appsawg‑webfinger]:

Rel Type URI
OpenID Connect Issuer http://openid.net/specs/connect/1.0/issuer

To start discovery of OpenID endpoints, the End-User supplies an Identifier to the Client or Relying Party.

The Client applies the normalization rules to the Identifier to determine the Resource and Host.

Then it makes an HTTPS GET request to the Host’s WebFinger [I‑D.ietf‑appsawg‑webfinger] endpoint with the resource and rel parameters to obtain the location of the requested service.

The Issuer MUST be returned in the response.

This includes a URI scheme (which MUST be https), a Host, and OPTIONALLY, a port.

Note

  1. ユーザーが識別子をRPに入力 (識別子は https://op.net/path )
  2. RPは識別子を正規化 ( -> Resource + Host )
  3. WebFingerでHTTP GET

( http://openid.bitbucket.org/openid-connect-discovery-1_0.html#ProviderDisc )

2.1. Identifier Normalization

The purpose of normalization is to determine a normalized Resource and Host from the user input Identifier. This is then used as input to WebFinger to discover the Issuer.

The user input Identifier SHOULD be a URL or URI relative reference defined in RFC 3986 [RFC3986]. The user input Identifier MUST include the authority component.

Note: A URI relative reference includes a string that looks like an e-mail address in the form of userinfo@host. This is a valid authority component of a URI but excludes various possible extra strings allowed in addr-spec syntax of RFC 5322 [RFC5322].

The Identifier normalization rules MAY be extended by additional specifications to enable other identifier types such as telephone numbers or XRIs [XRI_Syntax_2.0] to also be used.

( http://openid.bitbucket.org/openid-connect-discovery-1_0.html#IdentifierTypes )

2.1.1. User Input Identifier Types

A user input Identifier can be categorized into the following types, which require different normalization processes:

  1. User input Identifiers starting with the XRI [XRI_Syntax_2.0] global context symbols (‘=’,’@’, and ‘!’) are RESERVED. Processing of these identifiers is out of scope for this specification.
  2. All other user input Identifiers MUST be treated as a URI in one of the forms scheme ”://” authority path-abempty [ ”?” query ] [ “#” fragment ] or authority path-abempty [ ”?” query ] [ “#” fragment ] or scheme ”:” path-rootless per RFC 3986 [RFC3986].

Note: The user input Identifier MAY be in the form of userinfo@host. For the End-User, this would normally be perceived as being an e-mail address. However, it is also a valid userpart “@” host section of an acct URI [I‑D.ietf‑appsawg‑acct‑uri], and this specification treats it such as to exclude various extra strings allowed in addr-spec of RFC 5322 [RFC5322].

( http://openid.bitbucket.org/openid-connect-discovery-1_0.html#IdentifierTypes )

2.1.2. Normalization Steps

A string of any other type is interpreted as a URI in one of the forms scheme ”://” authority path-abempty [ ”?” query ] [ “#” fragment ] or authority path-abempty [ ”?” query ] [ “#” fragment ] or scheme ”:” path-rootless per RFC 3986 [RFC3986] and is normalized according to the following rules:

  1. If the user input Identifier does not have an RFC 3986 [RFC3986] scheme portion, the string is interpreted as [userinfo “@”] host [”:” port] path-abempty [ ”?” query ] [ “#” fragment ] per RFC 3986 [RFC3986].

  2. If the userinfo component is present and all of the scheme component, path component, query component, and port component are empty, the acct scheme is assumed.

    In this case, the normalized URI is formed by prefixing acct: to the string as the scheme. Per the ‘acct’ URI Scheme [I‑D.ietf‑appsawg‑acct‑uri], if there is an at-sign character (‘@’) in the userinfo component, it needs to be percent-encoded as described in RFC 3986 [RFC3986].

  3. For all other inputs without a scheme portion, the https scheme is assumed, and the normalized URI is formed by prefixing https:// to the string as the scheme.

  4. When the input contains an explicit scheme such as acct that matches the RFC 3986 scheme ”:” path-rootless syntax, no input normalization is performed.

  5. If the resulting URI contains a fragment portion, it MUST be stripped off together with the fragment delimiter character “#”.

    The WebFinger [I‑D.ietf‑appsawg‑webfinger] Resource in this case is the resulting URI, and the WebFinger Host is the authority component.

Note: Since the definition of authority in RFC 3986 [RFC3986] is [ userinfo “@” ] host [ ”:” port ], it is legal to have a user input identifier like userinfo@host:port, e.g., alice@example.com:8080.

( http://openid.bitbucket.org/openid-connect-discovery-1_0.html#NormalizationSteps )

2.1.3. URL

A URL Identifier is normalized according to the following rules:

  • If the URL does not have an RFC 3986 [RFC3986] “scheme” portion, the “https” scheme is prefixed to the URL, with the “scheme” portion being separated from the “authority” portion by a ”://” delimiter string. [1]
  • If the URL contains a fragment portion, it MUST be stripped off together with the fragment delimiter character “#”. [2]
  • The resulting URL is used as the SWD principal. The SWD host value is extracted from the “authority” portion (as defined by RFC 3986 [RFC3986]) of the URL by concatenating the RFC 3986 host and port values of the URL. See Section 2.2.3 for a non-normative example.
[1]hoge.com -> https://hoge.com
[2]http://hoge.com#id=hogehoge -> http://hoge.com

Todo

Check RFC 3986

2.2. Non-Normative Examples

( http://openid.bitbucket.org/openid-connect-discovery-1_0.html#Examples )

2.2.1. User Input Using E-Mail Address Syntax

To find the Issuer for the given user input in the form of an e-mail address joe@example.com, the WebFinger parameters are as follows:

WebFinger Parameter Value
resource acct:joe@example.com
host example.com
rel http://openid.net/specs/connect/1.0/issuer

Note that in this case, the acct: scheme [I‑D.ietf‑appsawg‑acct‑uri] is prepended to the Identifier.

Following the WebFinger specification, the Client would make the following request to get the discovery information (with line wraps within lines for display purposes only):

GET /.well-known/webfinger
  ?resource=acct%3Ajoe%40example.com
  &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
  HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: application/jrd+json

{
 "subject": "acct:joe@example.com",
 "links":
  [
   {
    "rel": "http://openid.net/specs/connect/1.0/issuer",
    "href": "https://server.example.com"
   }
  ]
}

( http://openid.bitbucket.org/openid-connect-discovery-1_0.html#EmailSyntax )

2.2.2. User Input Using URL Syntax

To find the Issuer for the given URL, https://example.com/joe, the WebFinger parameters are as follows:

WebFinger Parameter Value
resource https://example.com/joe
host example.com
rel http://openid.net/specs/connect/1.0/issuer

Following the WebFinger specification, the Client would make the following request to get the discovery information (with line wraps within lines for display purposes only):

GET /.well-known/webfinger
  ?resource=https%3A%2F%2Fexample.com%2Fjoe
  &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
  HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: application/jrd+json

{
 "subject": "https://example.com/joe",
 "links":
  [
   {
    "rel": "http://openid.net/specs/connect/1.0/issuer",
    "href": "https://server.example.com"
   }
  ]
}

( http://openid.bitbucket.org/openid-connect-discovery-1_0.html#URLSyntax )

2.2.3. User Input Using Hostname and Port Syntax

If the user input is in the form of host:port, e.g., example.com:8080, then it is assumed as the authority component of the URL.

To find the Issuer for the given hostname, example.com:8080, the WebFinger parameters are as follows:

WebFinger Parameter Value
resource https://example.com:8080/
host example.com:8080
rel http://openid.net/specs/connect/1.0/issuer

Following the WebFinger specification, the Client would make the following request to get the discovery information (with line wraps within lines for display purposes only):

GET /.well-known/webfinger
  ?resource=https%3A%2F%2Fexample.com%3A8080%2F
  &rel=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/jrd+json

{
 "subject": "https://example.com:8080/",
 "links":
  [
   {
    "rel": "http://openid.net/specs/connect/1.0/issuer",
    "href": "https://server.example.com"
   }
  ]
}

( http://openid.bitbucket.org/openid-connect-discovery-1_0.html#host.port.example )

2.2.4. User Input Using “acct” URI Syntax

To find the Issuer for the given user input in the form of an account URI acct:juliet%40capulet.example@shoppingsite.example.com, the WebFinger parameters are as follows:

WebFinger Parameter Value
resource acct:juliet%40capulet.example@shoppingsite.example.com
host shoppingsite.example.com
rel http://openid.net/specs/connect/1.0/issuer

Following the WebFinger specification, the Client would make the following request to get the discovery information (with line wraps within lines for display purposes only):

GET /.well-known/webfinger
  ?resource=acct%3Ajuliet%2540capulet.example%40shoppingsite.example.com
  &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
  HTTP/1.1
Host: shoppingsite.example.com

HTTP/1.1 200 OK
Content-Type: application/jrd+json

{
 "subject": "acct:juliet%40capulet.example@shoppingsite.example.com",
 "links":
  [
   {
    "rel": "http://openid.net/specs/connect/1.0/issuer",
    "href": "https://server.example.com"
   }
  ]
}

Note: It is common for sites to use e-mail addresses as local identifiers for accounts at those sites, even though the domain in the e-mail address one controlled by the site. For instance, the site example.org might have a local account named joe@example.com. As of the time of this writing, a discussion is ongoing among WebFinger contributors about the syntax that should be used when discovering information about such accounts with WebFinger. The current thinking seems to be that such accounts would be represented by quoting the ‘@’ character in the userinfo portion of the account identifier when constructing the acct: URI representing the account. Such an example is acct:joe%40example.com@example.org. In a future version of this specification, it is possible that normalization rules will be defined allowing End-Users to input values like joe@example.com@example.org to initiate discovery on such accounts.

( http://openid.bitbucket.org/openid-connect-discovery-1_0.html#AcctURISyntax )

2.3. Redirection

In cases where the SWD request is to be handled at a host or location other than the one derived from the End-User’s Identifier, the host will return a JSON object containing the new location. (Support for service redirection is a required feature of Simple Web Discovery [SWD].)

To enable service level redirection, a SWD server MAY return a 200 OK to an HTTPS request with a content type of application/json (or whatever other content type has been negotiated) that contains a JSON object that contains a member pair whose name is the string “SWD_service_redirect” whose value is a JSON object with a member pair whose name is “location” and whose value is a string that encodes a URI. Optionally the JSON object value of “SWD_service_redirect” MAY also contain a member whose name is “expires” and whose value is a JSON number that encodes an integer.

The “location” member identifies the URI that the caller MUST redirect all SWD requests for that domain to until the “expires” time is met. SWD requests for the redirected domain MUST be constructed by taking the URI returned in the “location” and using it as the base URI to which the SWD form arguments are then added as query parameters. The location URI MUST NOT include a query component.

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“]

}

3. OpenID Provider Metadata

OpenID Providers have metadata describing their configuration. The OpenID Provider Metadata values used by OpenID Connect are:

issuer

REQUIRED.

URL using the https scheme with no query or fragment component that the OP asserts as its Issuer Identifier.

authorization_endpoint
OPTIONAL. URL of the OP’s Authentication and Authorization Endpoint [OpenID.Messages].
token_endpoint
OPTIONAL. URL of the OP’s OAuth 2.0 Token Endpoint [OpenID.Messages].
userinfo_endpoint
RECOMMENDED. URL of the OP’s UserInfo Endpoint [OpenID.Messages]. This URL MUST use the https scheme and MAY contain port, path, and query parameter components.
check_session_iframe
OPTIONAL. URL of an OP endpoint that provides a page to support cross-origin communications for session state information with the RP Client, using the HTML5 postMessage API. The page is loaded from an invisible iframe embedded in an RP page so that it can run in the OP’s security context. See [OpenID.Session].
end_session_endpoint
OPTIONAL. URL of the OP’s endpoint that initiates logging out the End-User. See [OpenID.Session].
jwks_uri
REQUIRED. URL of the OP’s JSON Web Key Set [JWK] document. This contains the signing key(s) the Client uses to validate signatures from the OP. The JWK Set MAY also contain the Server’s encryption key(s), which are used by Clients to encrypt requests to the Server. When both signing and encryption keys are made available, a use (Key Use) parameter value is REQUIRED for all keys in the document to indicate each key’s intended usage.
registration_endpoint
RECOMMENDED. URL of the OP’s Dynamic Client Registration Endpoint [OpenID.Registration].
scopes_supported
RECOMMENDED. JSON array containing a list of the OAuth 2.0 [RFC6749] scope values that this server supports. The server MUST support the openid scope value.
response_types_supported
REQUIRED. JSON array containing a list of the OAuth 2.0 response_type values that this server supports. The server MUST support the code, id_token, and the token id_token response type values.
grant_types_supported
OPTIONAL. JSON array containing a list of the OAuth 2.0 grant type values that this server supports. The server MUST support the authorization_code and implicit grant type values and MAY support the urn:ietf:params:oauth:grant-type:jwt-bearer grant type defined in OAuth JWT Bearer Token Profiles [OAuth.JWT]. If omitted, the default value is [“authorization_code”, “implicit”].
acr_values_supported
OPTIONAL. JSON array containing a list of the Authentication Context Class References that this server supports.
subject_types_supported
REQUIRED. JSON array containing a list of the subject identifier types that this server supports. Valid types include pairwise and public.
userinfo_signing_alg_values_supported
OPTIONAL. JSON array containing a list of the JWS [JWS] signing algorithms (alg values) [JWA] supported by the UserInfo Endpoint to encode the Claims in a JWT [JWT].
userinfo_encryption_alg_values_supported
OPTIONAL. JSON array containing a list of the JWE [JWE] encryption algorithms (alg values) [JWA] supported by the UserInfo Endpoint to encode the Claims in a JWT [JWT].
userinfo_encryption_enc_values_supported
OPTIONAL. JSON array containing a list of the JWE encryption algorithms (enc values) [JWA] supported by the UserInfo Endpoint to encode the Claims in a JWT [JWT].
id_token_signing_alg_values_supported
REQUIRED. JSON array containing a list of the JWS signing algorithms (alg values) supported by the Authorization Server for the ID Token to encode the Claims in a JWT [JWT].
id_token_encryption_alg_values_supported
OPTIONAL. JSON array containing a list of the JWE encryption algorithms (alg values) supported by the Authorization Server for the ID Token to encode the Claims in a JWT [JWT].
id_token_encryption_enc_values_supported
OPTIONAL. JSON array containing a list of the JWE encryption algorithms (enc values) supported by the Authorization Server for the ID Token to encode the Claims in a JWT [JWT].
request_object_signing_alg_values_supported
OPTIONAL. JSON array containing a list of the JWS signing algorithms (alg values) supported by the Authorization Server for the Request Object described in Section 2.9 of OpenID Connect Messages 1.0 [OpenID.Messages]. These algorithms are used both when the Request Object is passed by value (using the request parameter) and when it is passed by reference (using the request_uri parameter). Servers SHOULD support none and RS256.
request_object_encryption_alg_values_supported
OPTIONAL. JSON array containing a list of the JWE encryption algorithms (alg values) supported by the Authorization Server for the Request Object described in Section 2.9 of OpenID Connect Messages 1.0 [OpenID.Messages]. These algorithms are used both when the Request Object is passed by value and when it is passed by reference.
request_object_encryption_enc_values_supported
OPTIONAL. JSON array containing a list of the JWE encryption algorithms (enc values) supported by the Authorization Server for the Request Object described in Section 2.9 of OpenID Connect Messages 1.0 [OpenID.Messages]. These algorithms are used both when the Request Object is passed by value and when it is passed by reference.
token_endpoint_auth_methods_supported
OPTIONAL. JSON array containing a list of authentication methods supported by this Token Endpoint. The options are client_secret_post, client_secret_basic, client_secret_jwt, and private_key_jwt, as described in Section 2.2.1 of OpenID Connect Messages 1.0 [OpenID.Messages]. Other authentication methods MAY be defined by extensions. If omitted, the default is client_secret_basic – the HTTP Basic Authentication Scheme as specified in Section 2.3.1 of OAuth 2.0 [RFC6749].
token_endpoint_auth_signing_alg_values_supported
OPTIONAL. JSON array containing a list of the JWS signing algorithms (alg values) supported by the Token Endpoint for the private_key_jwt and client_secret_jwt methods to encode the JWT [JWT]. Servers SHOULD support RS256.
display_values_supported
OPTIONAL. JSON array containing a list of the display parameter values that the OpenID Provider supports. These values are described in Section 2.1.1 of OpenID Connect Messages 1.0 [OpenID.Messages].
claim_types_supported
OPTIONAL. JSON array containing a list of the Claim Types that the OpenID Provider supports. These Claim Types are described in Section 2.6 of OpenID Connect Messages 1.0 [OpenID.Messages]. Values defined by this specification are normal, aggregated, and distributed. If not specified, the implementation supports only normal Claims.
claims_supported
RECOMMENDED. JSON array containing a list of the Claim Names of the Claims that the OpenID Provider MAY be able to supply values for. Note that for privacy or other reasons, this might not be an exhaustive list.
service_documentation
OPTIONAL. URL of a page containing human-readable information that developers might want or need to know when using the OpenID Provider. In particular, if the OpenID Provider does not support Dynamic Client Registration, then information on how to register Clients needs to be provided in this documentation.
claims_locales_supported
OPTIONAL. Languages and scripts supported for values in Claims being returned, represented as a JSON array of BCP47 [RFC5646] language tag values. Not all languages and scripts are necessarily supported for all Claim values.
ui_locales_supported
OPTIONAL. Languages and scripts supported for the user interface, represented as a JSON array of BCP47 [RFC5646] language tag values.
claims_parameter_supported
OPTIONAL. Boolean value specifying whether the OP supports use of the claims parameter, with true indicating support. If omitted, the default value is false.
request_parameter_supported
OPTIONAL. Boolean value specifying whether the OP supports use of the request parameter, with true indicating support. If omitted, the default value is false.
request_uri_parameter_supported
OPTIONAL. Boolean value specifying whether the OP supports use of the request_uri parameter, with true indicating support. If omitted, the default value is true.
require_request_uri_registration
OPTIONAL. Boolean value specifying whether the OP requires any request_uri values used to be pre-registered using the request_uris registration parameter. Pre-registration is REQUIRED when the value is true. If omitted, the default value is false.
op_policy_uri
OPTIONAL. URL that the OpenID Provider provides to the person registering the Client to read about the OP’s requirements on how the Relying Party can use the data provided by the OP. The registration process SHOULD display this URL to the person registering the Client if it is given.
op_tos_uri
OPTIONAL. URL that the OpenID Provider provides to the person registering the Client to read about OpenID Provider’s terms of service. The registration process SHOULD display this URL to the person registering the Client if it is given.

( draft 17, http://openid.bitbucket.org/openid-connect-discovery-1_0.html#ProviderMetadata )

OPOPについて

Note

On Premis OP Sample。設定は以下の2つがあり得る

  • OPOPで設定してRESTでRegistryに転送
  • RegistryのUIで設定

RESTで設定する場合、 OP Discovery のJsonをPOSTで送信する。アクセストークンは

  • 初期に提供されるトークンをそのまま使う
  • Jwkの登録が終わっていたら、そのキーを使って client_assertionの Client Credential でトークンを取得して使う

の2つ。

registory.net が信頼フレームワークの中心にあり、RPがmycompany.comのOPOPでID Tokenをもらう配置のディスカバリ情報の例。

mycompany.comのDNSエントリはエンドユーザーの企業内ネットワークで管理されているので、信頼できない。 また、IPアドレスのままのケースがあるかもしれない。 SSLは使われていないかもしれないし、使われていたとしてもmycompany.comはオレオレ証明書があり得る。

registory.netが信頼フレームワークの中心にあるということは

  1. RPが registory.net でクライアント登録し、( OpenID Connect Dynamic Client Registration 1.0 ) client_id をもらっている

    • registory.netと mycompany.comの間で client_id, ならびに メタ情報を共有する (ただしクレデンシャルは除く )
  2. OPOPがregistory.net でRP情報を確認する為に、mycompany.comの管理者は registory.netにアカウント登録する。 アカウント登録が行われると、メールで情報が送られる。

    • 初期アクセストークン
    • 登録エンドポイント

    登録エンドポイント詳細登録のUIエンドポイントのこともあるし、OPOPの管理画面でRESTで登録する場合のエンドポイントかもしれない。 実装によってはインストーラで処理を行うかもしれない

  3. RPがOPOPでログインするにあたり、OPの識別子として https://registroy.net/mycomapny.com を使い、これで OpenID Connect Discovery 1.0 する。 本ノートはこのディスカバリ情報で返されるJSONの例を書いています。このJSONはRESTでOPOPをRegistryに登録する場合も使うものとする。

    • OPOPのディスカバリ情報は、registory.net の Web UI で行った方が良いかと思う。
  4. RPはregistory.net を信頼しているので、クライアント登録をする。 registroy.netのサーバー証明書を確認すること。 信頼しているregistory.netからダウンロードされるJWK Setは信頼出来るものとする。 つまり、mycompany.com のOPOP自体は、JWK のベアキーを使ってよいとする。

  5. mycompany.com へのregistory.netの信頼は

    • B2Bで課金していること。
    • 正しいアクセストークンでRESTサービスにアクセスしていること。
    • RESTサービスを使ってJWK を適切にローテーションしていること。
    • 必要であれば、アクセストークン毎にRESTのIPアドレス制限をすること。

サンプル Discovery

Metadata Claim 登録要求Json 登録後情報Json Note
issuer null https://registry.net/mycompay.com registory が発行するものをもらうので、登録リクエストの時は指定しない
authorization_endpoint http://192.168.1.1/auth/ <= 同じ OPOPプライベートネットワークにある
token_endpoint null https://registry.net/mycompan.com/token code フローの場合、Token Endpointは Registoryが提供。 Implictの場合はToken Endpointはありません。
userinfo_endpoint null null UserInfoはID Tokenに入れられます。
check_session_iframe null null サポートしない
end_session_endpoint null null サポートしない
jwks_uri null https://registry.net/mycompay.com/jwk_set Registryがキーを提供します。JWK Set JSONを返すURL。
registration_endpoint null https://registry.net/mycompay.com/reg RPはOn Premis OP に直接登録するのではなく、レジストリサービスに代理登録する。
scopes_supported [“opeid”,”profile”,”email”] [“opeid”,”profile”,”email”] 通常のOPと同じ。openid は必ず指定。他はオプション
response_types_supported [“code”,”id_token”] [“code”,”id_token”] ID Tokenは必須
grant_types_supported [“code”,”implicit”] [“code”,”implicit”] codeフローの場合は Registryがトークン処理を行う。
acr_values_supported [“1”,”2” ] [“1”,”2” ] オプション ( TODO:要調査 )
subject_types_supported [“public”, “pairwise”] [“public”, “pairwise”] 通常のOPと同じくOPが指定
userinfo_signing_alg_values_supported null null 通常のOPと同じくOPが指定
userinfo_encryption_alg_values_supported null null 通常のOPと同じくOPが指定
userinfo_encryption_enc_values_supported null null 通常のOPと同じくOPが指定
id_token_signing_alg_values_supported [“RS256” ] [“RS256” ] 通常のOPと同じくOPが指定
id_token_encryption_alg_values_supported [“RSA1_5”, “A128KW”] [“RSA1_5”, “A128KW”] 通常のOPと同じくOPが指定
id_token_encryption_enc_values_supported [“A128CBC+HS256”, “A128GCM”] [“A128CBC+HS256”, “A128GCM”] 通常のOPと同じくOPが指定
request_object_signing_alg_values_supported [“none”, “RS256”, “ES256”] [“none”, “RS256”, “ES256”] 通常のOPと同じくOPが指定
request_object_encryption_alg_values_supported [“RSA1_5”, “A128KW”] [“RSA1_5”, “A128KW”] 通常のOPと同じくOPが指定
request_object_encryption_enc_values_supported [“A128CBC+HS256”, “A128GCM”] [“A128CBC+HS256”, “A128GCM”] 通常のOPと同じくOPが指定
token_endpoint_auth_methods_supported null null Token Endpoint はRegistoryが提供
token_endpoint_auth_signing_alg_values_supported null null Token Endpoint はRegistoryが提供
display_values_supported TODO TODO TODO あとで調べる
claim_types_supported [“normal”,”aggregated”] [“normal”,”aggregated”] distributed は無いでしょう (TODO後で調べる)
claims_supported [“sub”, “iss”, “auth_time”, “acr”, ] [“sub”, “iss”, “auth_time”, “acr”, ] 通常のOPと同じくOPが指定
service_documentation null https://registry.net/mycompay.com/docs Registryが提供
claims_locales_supported “ja” “ja” 通常のOPと同じくOPが指定
ui_locales_supported “ja” “ja” 通常のOPと同じくOPが指定
claims_parameter_supported false false falseがデフォルト。Request URI でやるべきだろう
request_parameter_supported false false falseがデフォルト。Request URI でやるべきだろう
request_uri_parameter_supported true true 信頼フレームワークとしてRPがregistory.netに登録が行われている前提で、request_uriは https://registry.net で始めるものとする。
require_request_uri_registration true true 信頼フレームワークとしてRPがregistory.netに登録が行われている前提とする。
op_policy_uri null https://registry.net/mycompay.com/policy Registryが提供
op_tos_uri https://192.168.1.1/tos https://192.168.1.1/tos OPOP でログインしようとしているユーザーに表示するURL

4. String Operations

Processing some OpenID Connect messages requires comparing values in the messages to known values. For example, the member names in the provider configuration response might be compared to specific member names such as issuer. Comparing Unicode strings, however, has significant security implications.

Therefore, comparisons between JSON strings and other Unicode strings MUST be performed as specified below:

  • Remove any JSON applied escaping to produce an array of Unicode code points.
  • Unicode Normalization [USA15] MUST NOT be applied at any point to either the JSON string or to the string it is to be compared against.
  • Comparisons between the two strings MUST be performed as a Unicode code point to code point equality comparison.

In several places, this specification uses space delimited lists of strings. In all such cases, only the ASCII space character (0x20) MAY be used for this purpose.

(draft 07, Dec 22, 2011 )

4.1. OpenID Provider Configuration Request

An OpenID Provider Configuration Document MUST be queried using an HTTPS GET request at the previously specified path.

The Client would make the following request to the Issuer to get the Configuration information, if the Issuer contains no path component.

GET /.well-known/openid-configuration HTTP/1.1
Host: example.com

If the Issuer value contains a path component, any terminating / MUST be removed before appending /.well-known/openid-configuration.

The Client would make the following request to the Issuer to get the Configuration information, if the Issuer string were https://example.com/issuer1

GET /issuer1/.well-known/openid-configuration HTTP/1.1
Host: example.com

Path components are allowed to support multiple issuers per host. This is required in some multi-tenant hosting configurations.

This use of .well-known is for supporting multiple issuers per host, and unlike its use in RFC 5785 [RFC5785], it does not provide general information about the host.

( draft 17, http://openid.bitbucket.org/openid-connect-discovery-1_0.html#ProviderConfigurationRequest )

4.2. OpenID Provider Configuration Response

The response is a set of Claims about the OpenID Provider’s configuration, including all necessary endpoints, supported scopes, and public key location information. The response MUST return the 200 OK response code and a plain text JSON object using the application/json content type that contains a set of Claims as its members that are a subset of the Metadata values defined in Section 3. Other Claims MAY also be returned.

Claims that return multiple values are represented as JSON arrays. Claims with zero elements MUST be omitted from the response.

The following is a non-normative example response:

HTTP/1.1 200 OK
Content-Type: application/json

{
 "issuer":
   "https://server.example.com",
 "authorization_endpoint":
   "https://server.example.com/connect/authorize",
 "token_endpoint":
   "https://server.example.com/connect/token",
 "token_endpoint_auth_methods_supported":
   ["client_secret_basic", "private_key_jwt"],
 "token_endpoint_auth_signing_alg_values_supported":
   ["RS256", "ES256"],
 "userinfo_endpoint":
   "https://server.example.com/connect/userinfo",
 "check_session_iframe":
   "https://server.example.com/connect/check_session",
 "end_session_endpoint":
   "https://server.example.com/connect/end_session",
 "jwks_uri":
   "https://server.example.com/jwks.json",
 "registration_endpoint":
   "https://server.example.com/connect/register",
 "scopes_supported":
   ["openid", "profile", "email", "address",
    "phone", "offline_access"],
 "response_types_supported":
   ["code", "code id_token", "id_token", "token id_token"],
 "acr_values_supported":
   ["urn:mace:incommon:iap:silver",
    "urn:mace:incommon:iap:bronze"],
 "subject_types_supported":
   ["public", "pairwise"],
 "userinfo_signing_alg_values_supported":
   ["RS256", "ES256", "HS256"],
 "userinfo_encryption_alg_values_supported":
   ["RSA1_5", "A128KW"],
 "userinfo_encryption_enc_values_supported":
   ["A128CBC-HS256", "A128GCM"],
 "id_token_signing_alg_values_supported":
   ["RS256", "ES256", "HS256"],
 "id_token_encryption_alg_values_supported":
   ["RSA1_5", "A128KW"],
 "id_token_encryption_enc_values_supported":
   ["A128CBC-HS256", "A128GCM"],
 "request_object_signing_alg_values_supported":
   ["none", "RS256", "ES256"],
 "display_values_supported":
   ["page", "popup"],
 "claim_types_supported":
   ["normal", "distributed"],
 "claims_supported":
   ["sub", "iss", "auth_time", "acr",
    "name", "given_name", "family_name", "nickname",
    "profile", "picture", "website",
    "email", "email_verified", "locale", "zoneinfo",
    "http://example.info/claims/groups"],
 "claims_parameter_supported":
   true,
 "service_documentation":
   "http://server.example.com/connect/service_documentation.html",
 "ui_locales_supported":
   ["en-US", "en-GB", "en-CA", "fr-FR", "fr-CA"]
}

( draft 17, http://openid.bitbucket.org/openid-connect-discovery-1_0.html#ProviderConfigurationResponse )

4.3. OpenID Provider Configuration Validation

If any of the validation procedures defined in this specification fail, any operations requiring the information that failed to correctly validate MUST be aborted and the information that failed to validate MUST NOT be used.

If the configuration response contains the Issuer element, the value MUST exactly match the Issuer for the URL that was directly used to retrieve the configuration. Since the discovery process allows for multiple levels of redirection, this Issuer URL MAY be different from the one originally used to begin the discovery process.

( draft 17, http://openid.bitbucket.org/openid-connect-discovery-1_0.html#ProviderConfigurationValidation )

7. References

(draft 07, Dec 22, 2011 )

7.1. Normative References

JWE
Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” December 2011.
JWK
Jones, M., “JSON Web Key (JWK),” December 2011.
JWS
Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signature,” December 2011.
JWT
Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” December 2011.
OAuth2.0
Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” September 2011.
OpenID.Messages
Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” December 2011.
OpenID.Registration
Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” December 2011.
OpenID.Session
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Session Management 1.0,” December 2011.
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).
RFC3986
Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML).
RFC5246
Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT).
RFC5322
Resnick, P., Ed., “Internet Message Format,” RFC 5322, October 2008 (TXT, HTML, XML).
RFC5785
Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known Uniform Resource Identifiers (URIs),” RFC 5785, April 2010 (TXT).
RFC6125
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),” RFC 6125, March 2011 (TXT).
SWD
Jones, M. and Y. Goland, “Simple Web Discovery,” December 2011.
USA15
Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” Unicode Standard Annex 15, 09 2009.

(draft 07, Dec 22,2011 )

7.2. Informative References

XRI_Syntax_2.0

Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” November 2005 (HTML, PDF).

(draft 07, Dec 22 ,2011 )

8. References

(draft 07)

8.1. Normative References

JWE
Jones, M., Bradley, J., and N. Sakimura, “JSON Web Encryption,” October 2011.
JWK
Jones, M., “JSON Web Key (JWK),” October 2011.
JWS
Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” October 2011.
JWT
Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” October 2011.
OAuth2.0
Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” September 2011.
OpenID.Messages
Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” September 2011.
OpenID.Registration
Sakimura, N., Bradley, J., Ed., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” September 2011.
OpenID.Session
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Session Management 1.0,” September 2011.
RFC2119
Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
RFC3986
Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML).
RFC5246
Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT).
RFC5322
Resnick, P., Ed., “Internet Message Format,” RFC 5322, October 2008 (TXT, HTML, XML).
RFC5785
Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known Uniform Resource Identifiers (URIs),” RFC 5785, April 2010 (TXT).
RFC6125
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),” RFC 6125, March 2011 (TXT).
SWD
Jones, M., Ed. and Y. Goland, “Simple Web Discovery,” July 2011.
USA15
Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” Unicode Standard Annex 15, 09 2009.

(draft 07)

8.2. Informative References

XRI_Syntax_2.0
Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” November 2005 (HTML, PDF).

(draft 07)

«  OpenID Connect Dynamic Client Registration 1.0   ::   Contents   ::   OpenID Connect Session Management 1.0  »