TOC |
|
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 describes how an OpenID Client can obtain the necessary client credentials required by the OpenID Connect protocol suite.
1.
Introduction
1.1.
Requirements Notation and Conventions
1.2.
Terminology
2.
Client Registration Endpoint
2.1.
Client Registration and Client Update Request
2.1.1.
"sector_identifier_url" Validation
2.2.
Client Registration Response
2.2.1.
Client Register Operation Response
2.2.2.
Rotate Secret Operation Response
2.2.3.
Client Update Operation Response
2.3.
Client Registration Error Response
3.
String Operations
4.
Implementation Considerations
5.
Security Considerations
6.
IANA Considerations
7.
References
7.1.
Normative References
7.2.
Informative References
Appendix A.
Acknowledgements
Appendix B.
Notices
Appendix C.
Document History
§
Authors' Addresses
TOC |
In order for an OpenID Connect Client to utilize OpenID services for a user, the Client needs to register with the OpenID Provider to acquire a Client ID and shared secret. This document describes how a new Client can register with the provider, and how a Client already in possession of a client_id can retrieve updated registration information.
The Client Registration Endpoint may be co-resident with the token endpoint as an optimization in some deployments.
Note: This specification will likely be modified to use the OAuth Dynamic Client Registration Protocol (Richer, J., Bradley, J., Jones, M., and M. Machulak, “OAuth Dynamic Client Registration Protocol,” January 2013.) [I‑D.ietf‑oauth‑dyn‑reg] once the OAuth registration draft is stable. While currently self-contained, this specification intentionally uses the same syntax and identifiers as the current version of the OAuth registration draft as of the time that this specification was last updated.
TOC |
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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.
TOC |
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 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749], and the terms defined by OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” January 2013.) [OpenID.Messages]. It defines no additional terms.
TOC |
The Client Registration Endpoint is an OAuth 2.0 Protected Resource that returns registration information for the Client to configure itself for the OpenID Provider. The OpenID Provider may require an Access Token that is provisioned out-of-band (in a manner that is out of scope for this specification) in order to restrict registration requests to only authorized Clients.
In order to support open registration, the Client Registration Endpoint SHOULD accept requests without OAuth 2.0 Access Tokens. If an Access Token is required for Client registration, the Client Registration Endpoint MUST be able to accept Access Tokens in the manner described in the OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] specification.
TOC |
Client Update Requests replace all previous parameters set for a client_id.
Clients MUST send requests encoded as a POST with the following parameters added to the HTTP request entity-body using "application/x-www-form-urlencoded" format:
- operation
- REQUIRED. Registration operation being performed. Values are client_register (for new registrations), rotate_secret to request rotation of the client_secret, and client_update (for updating parameters of an existing client_id). If rotate_secret is used no optional parameters other than access_token may be included in the request.
- redirect_uris
- REQUIRED. Space-delimited list of redirect URIs. One of the URL MUST match the Scheme, Host, and Path segments of the redirect_uri in the authorization request.
- application_type
- OPTIONAL. Kind of the application. The default if not specified is web. The defined values are native or web. Web clients MUST only register https: Scheme redirect_uris that do not use localhost as the hostname. Native clients MUST only register redirect_uris using custom URI schemes or http: scheme URI using localhost as the hostname. Authorization Servers may place additional constraints on Native such as not supporting the token response_type. The Authorization server MUST verify that all the registered redirect_uris conform to the constraints. This prevents sharing a client_id across different types of clients.
- access_token
- OPTIONAL. If this is a client_register request, this is an Access Token obtained out of band to authorize the registrant. If this is a client_update request, this is the registration_access_token returned in the client_register or rotate_secret response. This parameter MUST NOT be sent if the Access Token is sent in the HTTP Authorization header as described in Section 7.1 of OAuth 2.0 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749]. Access Tokens sent in the authorization header must be bearer tokens [RFC6750] (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.).
- contacts
- OPTIONAL. Space delimited list of e-mail addresses for people allowed to administer the information for this Client. This is used by some providers to enable a web UI to modify the Client information.
- client_name
- OPTIONAL. Name of the Client to be presented to the user. If desired, representation of this claim in different languages and scripts is obtained by applying the rules set in Section 2.1.1.1.3 ("claims" member) of OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” January 2013.) [OpenID.Messages].
- logo_url
- OPTIONAL. URL that references a logo for the Client application.
- token_endpoint_auth_method
- OPTIONAL. Requested authentication method for the 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 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” January 2013.) [OpenID.Messages]. Other Authentication methods may be defined by extension. If unspecified or omitted, the default is client_secret_basic HTTP Basic Authentication Scheme as specified in Section 2.3.1 of OAuth 2.0 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749].
- policy_url
- OPTIONAL. URL location that the Relying Party Client provides to the End-User to read about the how the profile data will be used. The OpenID Provider SHOULD display this URL to the End-User if it is given.
- tos_url
- OPTIONAL. URL location that the Relying Party Client provides to the End-User to read about the Relying Party's terms of service. The OpenID Provider SHOULD display this URL to the End-User if it is given.
- jwk_url
- OPTIONAL. URL for the Client's JSON Web Key Set [JWK] (Jones, M., “JSON Web Key (JWK),” December 2012.) document containing key(s) that are used for signing Token Endpoint Requests and OpenID Request Objects. If jwk_encryption_url is not provided it is also used to encrypt the ID Token and User Info Endpoint Responses to the Client. If the Client registers both x509_url and jwk_url, the keys contained in both formats SHOULD be the same.
- jwk_encryption_url
- OPTIONAL. URL for the Client's JSON Web Key Set [JWK] (Jones, M., “JSON Web Key (JWK),” December 2012.) document containing key(s) that are used to encrypt the ID Token and User Info Endpoint Responses to the Client. If the Client registers both jwk_encryption_url and x509_encryption_url, the keys contained in both formats SHOULD be the same.
- x509_url
- OPTIONAL. URL for the Client's PEM encoded X.509 Certificate or Certificate chain that is used for signing Token Endpoint Requests and OpenID Request Objects. If x509_encryption_url is not provided, x509_url it is also used to encrypt the ID Token and User Info Endpoint Responses to the Client. If the Client registers both x509_url and jwk_url, the keys contained in both formats SHOULD be the same.
- x509_encryption_url
- OPTIONAL. URL for the Client's PEM encoded X.509 Certificate or Certificate chain that is used to encrypt the ID Token and User Info Endpoint Responses to the Client. If the Client registers both jwk_encryption_url and x509_encryption_url, the keys contained in both formats SHOULD be the same.
- sector_identifier_url
- OPTIONAL. URL using the https: scheme to be used in calculating Pseudonymous Identifiers by the OP. The URL references a file with a single JSON array of redirect_uri values. Please see Section 2.1.1 ("sector_identifier_url" Validation).
- subject_type
- OPTIONAL. subject_type requested for responses to this client_id. The subject_types_supported element of discovery contains a list of the supported subject_type values for this server. Valid types include pairwise and public.
- request_object_signing_alg
- OPTIONAL. JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” December 2012.) [JWS] alg algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) that MUST be required by the Authorization Server. The valid values are listed in Section 3.1 of JWA (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) [JWA]. All OpenID Request Objects from this client_id MUST be rejected if not signed by this algorithm. Servers SHOULD support RS256.
- userinfo_signed_response_alg
- OPTIONAL. JWS alg algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) required for UserInfo responses. The valid values are listed in Section 3.1 of JWA (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) [JWA]. If this is specified the response will be JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012.) [JWT] serialized, and signed using JWS.
- userinfo_encrypted_response_alg
- OPTIONAL. JWE (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” December 2012.) [JWE] alg algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) required for encrypting UserInfo responses. The valid values are listed in Section 4.1 of JWA (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) [JWA]. If this is requested in combination with signing the response will be signed then encrypted. If this is specified the response will be JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012.) [JWT] serialized, and encrypted using JWE.
- userinfo_encrypted_response_enc
- OPTIONAL. JWE enc algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) required for symmetric encryption of UserInfo responses. The valid values are listed in Section 4.2 JWA (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) [JWA]. If "userinfo_encrypted_response_alg" is specified the default for this value is A128CBC+HS256. If this is requested in combination with signing the response will be signed then encrypted. If this is specified the response will be JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012.) [JWT] serialized, and encrypted using JWE.
- id_token_signed_response_alg
- OPTIONAL. JWS alg algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) required for the ID Token issued to this client_id. The valid values are listed in Section 3.1 of JWA (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) [JWA]. The default if not specified is RS256. The public key for validating the signature is provided by retrieving the document from the jwk_url element or the x509_url element from discovery.
- id_token_encrypted_response_alg
- OPTIONAL. JWE alg algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) required for encrypting the ID Token issued to this client_id. The valid values are listed in Section 4.1 of JWA (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) [JWA]. If this is requested the response will be signed then encrypted. The default if not specified is no encryption.
- id_token_encrypted_response_enc
- OPTIONAL. JWE enc algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) required for symmetric encryption of the ID Token issued to this client_id. The valid values are listed in Section 4.2 of JWA (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) [JWA]. If "id_token_encrypted_response_alg" is specified the default for this value is A128CBC+HS256. If this is requested in combination with signing the response will be signed then encrypted. If this is specified the response will be JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012.) [JWT] serialized, and encrypted using JWE.
- default_max_age
- OPTIONAL. Default max authentication age that specifies that the End-User must be actively authenticated if any present authentication is older than the specified number of seconds represented as an integer. (The max_age request parameter corresponds to the OpenID 2.0 PAPE max_auth_age request parameter.) The max_age claim in the request object overrides this default value.
- require_auth_time
- OPTIONAL. Boolean value specifying whether the auth_time claim in the id_token is REQUIRED. It is REQUIRED when the value is true. The auth_time claim request in the request object overrides this setting.
- default_acr
- OPTIONAL. Default authentication context class reference value. String that specifies the default value that the Authorization Server must use for processing requests from this client. The acr_values_supported element of discovery contains a list of the supported acr values for this server. The acr claim in the request object overrides this default value.
- initiate_login_uri
- OPTIONAL. URI using the https: scheme that the authorization server can call to initiate a login at the client. The URI MUST accept requests via both GET and POST. The client MUST understand the login_hint and iss parameters and SHOULD support the target_link_uri parameter.
- post_logout_redirect_url
- OPTIONAL. URL supplied by the RP to request that the user be redirected to this location after a logout has been performed, as specified in OpenID Connect Session Management 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and N. Agarwal, “OpenID Connect Session Management 1.0,” January 2013.) [OpenID.Session].
The Client Registration Endpoint is an OAuth 2.0 Protected Resource that may require an Access Token for client_register requests in order to restrict registration requests to only authorized Clients.
For client_update requests the registration_access_token is used as the Access Token to restrict update access to only the registered client.
The Client Registration Endpoint MUST accept Access Tokens as OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750].
Following is a non-normative example request (with line wraps for display purposes only):
POST /connect/register HTTP/1.1 Content-Type: application/x-www-form-urlencoded Host: server.example.com Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... operation=client_register &application_type=web &redirect_uris=https://client.example.org/callback %20https://client.example.org/callback2 &client_name=My%20Example%20 &client_name%23ja-Jpan-JP= ワタシ用の例 &logo_url=https://client.example.org/logo.png &subject_type=pairwise §or_identifier_url= https://othercompany.com/file_of_redirect_uris.json &token_endpoint_auth_method=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+HS256
TOC |
Providers who use pairwise sub (subject) values SHOULD support this element.
It provides a way for a group of websites under a single administrative control to have consistent pairwise sub values independent of the individual domain names. It also provides a way for Clients to change redirect_uri domains without having to reregister all of their users.
This is further described in Section 2.4.1 of OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” January 2013.) [OpenID.Messages].
The value of the sector_identifier_url must be a URL using the https: scheme that references a JSON file containing an array containing redirect_uri values. The Registration Server MUST perform a TLS/SSL server certificate check, per 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].
The values of the registered redirect_uris must be included in the elements of the array, or registration MUST fail.
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 |
The response is returned as a JSON object with all the parameters as top level elements.
TOC |
If the value of operation in the request was client_register then return the following.
- client_id
- REQUIRED. Unique Client identifier.
- client_secret
- OPTIONAL. Client secret. This MUST be unique for each client_id. This value is used by confidential clients. It is not required for clients selecting a token_endpoint_auth_method of private_key_jwt.
- registration_access_token
- REQUIRED. Access token used by the client to perform client_update requests.
- expires_at
- OPTIONAL. Time at which the client_secret will expire or 0 if it will not expire. The time is represented as the number of seconds from 1970-01-01T0:0:0Z as measured in UTC. See RFC 3339 (Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.) [RFC3339] for details regarding date/times in general and UTC in particular.
Additionally, the server MUST include all registered metadata about a client as described in Section 2.1 (Client Registration and Client Update Request), including any fields that the server has provisioned on the client's behalf.
Following is a non-normative example response (line breaks are for display purposes only):
HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "client_id": "s6BhdRkqt3", "client_secret": "cf136dc3c1fd9153029bb9c6cc9ecead 918bad9887fce6c93f31185e5885805d", "registration_access_token": "this.is.an.access.token.value.ffx83", "token_endpoint_auth_method": "client_secret_basic", "expires_at":2893276800, "application_type": "web", "redirect_uris": "https://client.example.org/callback https://client.example.org/callback2", "client_name": "My Example", "client_name#ja-Jpan-JP": "ワタシ用の例", "logo_url": "https://client.example.org/logo.png", "subject_type": "pairwise" "sector_identifier_url": "https://othercompany.com/file_of_redirect_uris.json" "jwk_url": "https://client.example.org/my_rsa_public_key.jwk", "userinfo_encrypted_response_alg": "RSA1_5", "userinfo_encrypted_response_enc": "A128CBC+HS256" }
TOC |
If the value of operation in the request was rotate_secret then return the following.
- client_id
- REQUIRED. Unique Client identifier.
- client_secret
- OPTIONAL. Client secret. This MUST be unique for each client_id. This value is used by confidential clients. It is not required for Clients selecting a token_endpoint_auth_method of private_key_jwt.
- registration_access_token
- REQUIRED. Access Token used by the Client to perform client_update requests.
- expires_at
- OPTIONAL. Number of seconds from 1970-01-01T0:0:0Z as measured in UTC at which the client_secret will expire or 0 if it will not expire. See RFC 3339 (Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.) [RFC3339] for details regarding date/times in general and UTC in particular.
Following is a non-normative example response:
HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "client_id": "s6BhdRkqt3", "client_secret": "cf136dc3c1fd9153029bb9c6cc9ecead 918bad9887fce6c93f31185e5885805d", "registration_access_token": "this.is.an.access.token.value.ffx83", "expires_at":2893276800 }
TOC |
If the value of operation in the request was client_update.
- client_id
- REQUIRED. Unique Client identifier.
Additionally, the server MUST include all registered metadata about a client as described in Section 2.1 (Client Registration and Client Update Request), including any fields that the server has provisioned on the client's behalf.
Following is a non-normative example response (line breaks are for display purposes only):
HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "client_id": "s6BhdRkqt3" "token_endpoint_auth_method": "client_secret_basic", "expires_at":2893276800, "application_type": "web", "redirect_uris": "https://client.example.org/callback https://client.example.org/callback2", "client_name": "My Example", "client_name#ja-Jpan-JP": "ワタシ用の例", "logo_url": "https://client.example.org/logo.png", "subject_type": "pairwise" "sector_identifier_url": "https://othercompany.com/file_of_redirect_uris.json" "jwk_url": "https://client.example.org/my_rsa_public_key.jwk", "userinfo_encrypted_response_alg": "RSA1_5", "userinfo_encrypted_response_enc": "A128CBC+HS256" }
TOC |
When an OAuth error condition occurs, the Client Registration Endpoint returns an Error Response as defined in Section 3 of the OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] specification.
When a registration error condition occurs, the Client Registration Endpoint returns a HTTP 400 status code including a JSON object describing the error in the response body.
The JSON object contains two members:
- error_code
- Error code.
- error_description
- Additional text description of the error for debugging.
This specification defines the following error codes:
- invalid_operation
- Value of operation is invalid or not supported.
- invalid_client_id
- Value of client_id is invalid.
- invalid_client_secret
- client_secret provided for a client_update or rotate_secret is not valid for the provided client_id.
- invalid_redirect_uri
- Value of one or more redirect_uris is invalid.
- invalid_configuration_parameter
- Value of one of the configuration parameters is invalid.
Following is a non-normative example of an error response:
HTTP/1.1 400 Bad Request Content-Type: application/json Cache-Control: no-store { "error_code": "invalid_operation", "error_description": "The value of the operation parameter must be one of client_register, rotate_secret or client_update." }
TOC |
Processing some OpenID Connect messages requires comparing values in the messages to known values. For example, the member names in the Client registration response might be compared to specific member names such as client_id. Comparing Unicode strings, however, has significant security implications.
Therefore, comparisons between JSON strings and other Unicode strings MUST be performed as specified below:
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.
TOC |
This specification defines features used by both Relying Parties and OpenID Providers that choose to implement Dynamic Client Registration. All of these Relying Parties and OpenID Providers MUST implement the features that are listed in this specification as being "REQUIRED" or are described with a "MUST". No other implementation considerations for implementations of Dynamic Client Registration are defined by this specification.
TOC |
Since requests to the Client Registration Endpoint result in the transmission of clear-text credentials (in the HTTP request and response), the server MUST require the use of a transport-layer security mechanism when sending requests to the Registration Endpoint. The server MUST support TLS 1.2 RFC 5246 (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] and/or TLS 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) and MAY support additional transport-layer mechanisms meeting its security requirements. When using TLS, the Client MUST perform a TLS/SSL server certificate check, per 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].
Requests to the Registration Endpoint for client_update MUST have some rate limiting on failures to prevent the Client secret from being disclosed though repeated access attempts.
A rogue RP might use the logo for the legitimate RP, which it is trying to impersonate. An OP needs to take steps to mitigate this phishing risk, since the logo could confuse users into thinking they're logging in to the legitimate RP. An OP could also warn if the domain/site of the logo doesn't match the domain/site of redirect URIs. An OP can also make warnings against untrusted RPs in all cases, especially if they're dynamically registered, have not been trusted by any users at the OP before, and want to use the logo feature.
In a situation where the Authorization Server is supporting open Client registration, it must be extremely careful with any URL provided by the Client that will be displayed to the user (e.g. logo_url and policy_url). A rogue Client could specify a registration request with a reference to a drive-by download in the policy_url. The Authorization Server should check to see if the logo_url and policy_url have the same host as the hosts defined in the array of redirect_uris.
TOC |
This document makes no requests of IANA.
TOC |
TOC |
[JWA] | Jones, M., “JSON Web Algorithms (JWA),” draft-ietf-jose-json-web-algorithms (work in progress), December 2012 (HTML). |
[JWE] | Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” draft-ietf-jose-json-web-encryption (work in progress), December 2012 (HTML). |
[JWK] | Jones, M., “JSON Web Key (JWK),” draft-ietf-jose-json-web-key (work in progress), December 2012 (HTML). |
[JWS] | Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” draft-ietf-jose-json-web-signature (work in progress), December 2012 (HTML). |
[JWT] | Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” draft-ietf-oauth-json-web-token (work in progress), December 2012 (HTML). |
[OpenID.Messages] | Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” January 2013. |
[OpenID.Session] | Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and N. Agarwal, “OpenID Connect Session Management 1.0,” January 2013. |
[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). |
[RFC3339] | Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” RFC 3339, July 2002 (TXT, HTML, XML). |
[RFC5246] | Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (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). |
[RFC6749] | Hardt, D., “The OAuth 2.0 Authorization Framework,” RFC 6749, October 2012 (TXT). |
[RFC6750] | Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” RFC 6750, October 2012 (TXT). |
[USA15] | Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” Unicode Standard Annex 15, 09 2009. |
TOC |
[I-D.ietf-oauth-dyn-reg] | Richer, J., Bradley, J., Jones, M., and M. Machulak, “OAuth Dynamic Client Registration Protocol,” draft-ietf-oauth-dyn-reg-04 (work in progress), January 2013 (TXT). |
TOC |
TOC |
Copyright (c) 2013 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 |
[[ To be removed from the final specification ]]
-14
-13
-12
-11
-10
-09
-08
-07
-06
-05
-04
-03
-02
-01
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 |