Draft N. Sakimura NRI J. Bradley Protiviti M. Jones Microsoft B. de Medeiros Google C. Mortimore Salesforce E. Jay MGI1 July 28, 2011 OpenID Connect Framework 1.0 - draft 05 Abstract This document describes the more advanced request and response formats for OpenID Connect. Sakimura, et al. [Page 1] OpenID Connect Framework 1.0 - draft 05 July 2011 Requirements Language 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]. Sakimura, et al. [Page 2] OpenID Connect Framework 1.0 - draft 05 July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Authorization Endpoint . . . . . . . . . . . . . . . . . . . . 6 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 6 3.1.1. OpenID Request Object . . . . . . . . . . . . . . . . 6 3.2. Authorization Response . . . . . . . . . . . . . . . . . . 10 3.3. Authorization Error Response . . . . . . . . . . . . . . . 10 4. UserInfo Endpoint . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Normal Claims . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Aggregated and Distributed Claims . . . . . . . . . . . . 11 4.3. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Responses . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4.1. Example Responses . . . . . . . . . . . . . . . . . . 13 4.5. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Introspection Endpoint . . . . . . . . . . . . . . . . . . . . 15 5.1. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 16 6. Signatures and Encryption . . . . . . . . . . . . . . . . . . 17 7. Verification . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Authorization Request Verification . . . . . . . . . . . . 18 7.2. Authorization Response Verification . . . . . . . . . . . 18 7.3. UserInfo Request Verification . . . . . . . . . . . . . . 18 7.4. UserInfo Response Verification . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9.1. Assertion Manufacture/Modification . . . . . . . . . . . . 21 9.2. Assertion Disclosure . . . . . . . . . . . . . . . . . . . 21 9.3. Assertion Repudiation . . . . . . . . . . . . . . . . . . 21 9.4. Assertion Redirect . . . . . . . . . . . . . . . . . . . . 21 9.5. Assertion Reuse . . . . . . . . . . . . . . . . . . . . . 22 9.6. Secondary Authenticator Manufacture . . . . . . . . . . . 22 9.7. Secondary Authenticator Capture . . . . . . . . . . . . . 22 9.8. Assertion Substitution . . . . . . . . . . . . . . . . . . 22 9.9. Authentication Request Disclosure . . . . . . . . . . . . 22 9.10. Timing Attack . . . . . . . . . . . . . . . . . . . . . . 22 9.11. Authentication Process Threats . . . . . . . . . . . . . . 23 10. Open Issues and Things To Be Done (TBD) . . . . . . . . . . . 24 11. Normative References . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27 Appendix B. Document History . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Sakimura, et al. [Page 3] OpenID Connect Framework 1.0 - draft 05 July 2011 1. Introduction The OpenID Connect Core 1.0 [OpenID.Core] specification defines the basic requests and responses in allow easy and simple implementations and conformance. This specification defines various optional parts of OpenID Connect that use more complex requests and responses. Sakimura, et al. [Page 4] OpenID Connect Framework 1.0 - draft 05 July 2011 2. Terminology The terms used in this specification are defined in OpenID Connect Core 1.0 [OpenID.Core]. In addition, the following terms are defined: Introspection Endpoint The Authorization Server's endpoint that takes an ID Token or Access Token as input and returns an unpacked JSON representation of an ID Token. Sakimura, et al. [Page 5] OpenID Connect Framework 1.0 - draft 05 July 2011 3. Authorization Endpoint This specification introduces some new parameters to the OpenID Connect Core [OpenID.Core] Authorization Request. 3.1. Authorization Request Section 4.1.1 and 4.2.1 of OAuth 2.0 [OAuth.2.0] defines OAuth Authorization Request parameters. The following extension parameters are defined: request OPTIONAL. A JWT [JWT] encoded OpenID Request Object (Section 3.1.1). request_uri OPTIONAL. A URL that points to the OpenID Request Object. Following is a non-normative example when they are sent using the query parameters serialization: GET /authorize?scope=openid&response_type=code &client_id=s6BhdRkqt3 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb &request=jwt_header.jwt_part2.jwt_part3 &prompt=login &display=popup HTTP/1.1 Host: server.example.com 3.1.1. OpenID Request Object The OpenID Request object is used to provide OpenID request parameters that MAY differ from the default ones. Implementing support for the OpenID Request object is OPTIONAL. Supporting it is necessary for implementations that need to request or provide sets of claims other than the default UserInfo claim set, as defined in the OpenID UserInfo 1.0 [OpenID.UserInfo] specification. If present, the OpenID Request object is passed as the value of a "request" OAuth 2.0 parameter and is represented as a JWT [JWT]. Parameters that affect the information returned from the UserInfo endpoint are in the "userinfo" member. Parameters that affect the information returned in an ID Token are in the "id_token" member. If the same parameters are available both as query strings and in the OpenID Request Object, the later takes the precedence. Sakimura, et al. [Page 6] OpenID Connect Framework 1.0 - draft 05 July 2011 An example an OpenID request object is as follows: { "userinfo": { "claims": { "name": null, "nickname": {"optional": true}, "email": null, "verified": null, "picture": {"optional": true}, }, "format": "signed" } "id_token": { "claims": { "auth_time": null } "max_age": 86400, "iso29115": "2" } } The OpenID Request object is a JWT [JWT] that MAY contain a set of members defined by this specification and MAY contain other members that are not defined by this specification. The JWT MAY be signed or unsigned. When it is unsigned, it will be indicated by the JWT ""signed":"none"" convention in the JWT header. The members defined by this specification are: userinfo OPTIONAL. (UserInfo request): Requests affecting the values to be returned from the UserInfo endpoint. If not present, the UserInfo endpoint behaves in the default manner. id_token OPTIONAL. (ID request): Requests affecting the values to be included in the ID Token. If not present, the default ID Token contents are used. If present, these parameters are used to request deltas to the default contents of the ID Token. If signed, the OpenID Request object SHOULD contain the standard JWT "iss" and "aud" claims. All members of the OpenID Request object are OPTIONAL. Other members MAY be present and if so, SHOULD be understood by both parties. Sakimura, et al. [Page 7] OpenID Connect Framework 1.0 - draft 05 July 2011 3.1.1.1. "userinfo" member The structure of the "userinfo" (UserInfo request) member is a JSON object that MAY contain the following members: claims OPTIONAL. (Requested Claims): Set of requested claims from the UserInfo endpoint. If not present, the default UserInfo claims held by the IdP are returned. format OPTIONAL. (Format): The requested format for the UserInfo endpoint information. If not present, the format is an unsigned JSON object. locale OPTIONAL. (Locale): The default languages and scripts of the entire claim request, represented as a space-separated list of BCP47 [RFC5646] language tags. The "claims" member is a JSON object with a member for each requested claim. The member names are the requested claim names. The member values may be either: null This indicates that this claim is being requested in the default manner. In particular, this is a required claim. OR A JSON Object This is used to provide additional information about the claim being requested. The claims MAY be represented in multiple languages and scripts. To specify languages and scripts for the claim request, BCP47 [RFC5646] language tags delimited by a "#" MUST be added to each requested claim name for which a particular language and script is requested. For example, the claim "family_name#ja-Kana-JP" is used for expressing Family Name in Katakana in Japanese, which is commonly used to index and represent the phonetics of the Kanji representation of the same value represented as "family_name#ja-Hani-JP". All members of the "claims" object are OPTIONAL. The members of the JSON object value following a claim name defined by this specification are: optional If this is an optional claim, this member's value MUST be "true", else, if present, its value MUST be "false", which indicates that it is a required claim. If it is not present, it is a required claim. Other members MAY be defined to provide additional information about the requested claim. If the "claims" member is present in the Sakimura, et al. [Page 8] OpenID Connect Framework 1.0 - draft 05 July 2011 "userinfo" object, the claims requested within it override the default claim set that would otherwise be returned from the UserInfo endpoint. The "format" member of the "userinfo" object is used to specify the requested format of the UserInfo endpoint contents. Values defined are: unsigned - in which case the contents are an unsigned JSON object signed - in which case the contents are a signed JWT encrypted - in which case the contents are an signed and encrypted JWT All members of the "userinfo" object are OPTIONAL. Other members MAY be present and if so, SHOULD understood by both parties. 3.1.1.2. "id_token" member The structure and function of the "id_token" (ID Token request) member of the OpenID Request object is similar to that of the "userinfo" member. It MAY include "claims", "format", "locale". The same structure of these members are the same as that for the "userinfo" member. If the "claims" member is present in the "id_token" object, the claims requested within it modify the default claim set that would otherwise be returned in the ID Token. Unlike for the "userinfo" member, typically these claims will augment, rather than override the default set. Following claim MAY be requested in the ID Token by specifying it in the "claims" member: auth_time OPTIONAL. (authenticated at): Requests that the "auth_time" claim be present. The claim value is the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/ time that the user authentication occurred. (The "auth_time" claim semantically corresponds to the openid.pape.auth_time response parameter.) In addition to the "claims" member, this additional member is defined within the "id_token" member of the OpenID Request object: max_age OPTIONAL. (max authentication age): Specifies that the user must be actively authenticated if any present authentication is older than the specified number of seconds. (The "max_age" request parameter corresponds to the OpenID 2.0 openid.pape.max_auth_age request parameter.) Sakimura, et al. [Page 9] OpenID Connect Framework 1.0 - draft 05 July 2011 iso29115 OPTIONAL. (entity authentication assurance): Specifies the X.eaa / ISO/IEC29115 [ISO29115] entity authentication assurance level that is requested by the client. It is anticipated that additional "id_token" parameters MAY be defined to request that additional properties hold for the authentication - for instance, that certain authentication policies be applied (in the same spirit of the OpenID 2.0 openid.pape.auth_policies values), or that the authentication conform to the policies defined by a specified trust framework. These parameters MAY be defined by extension specifications. All members of the "id_token" object are OPTIONAL. Other members MAY be present and if so, SHOULD understood by both parties 3.2. Authorization Response Authorization responses are defined in the OpenID Connect Core [OpenID.Core] specification. 3.3. Authorization Error Response If the end-user denies the access request or if the request fails, the authorization server informs the client by returning parameters defined in section 4.1.2.1 of OAuth 2.0 [OAuth.2.0]. Sakimura, et al. [Page 10] OpenID Connect Framework 1.0 - draft 05 July 2011 4. UserInfo Endpoint The UserInfo endpoint returns claims for the authenticated user. There are three different types of claims. Normal Claims Claims that are directly asserted by the OpenID Provider. Aggregated Claims Claims that are asserted by a claims provider other than the OpenID Provider but are returned by OpenID Provider. Distributed Claims Claims that are asserted by a claims provider other than the OpenID Provider but are returned as references by the OpenID Provider. The UserInfo endpoint MUST support normal claims. Aggregated and distributed claims support is OPTIONAL. Claim objects contain members and member values which are the individual claims and claims values. A claim object is represented by a JSON object which contains a collection of name/value pairs for the claims. 4.1. Normal Claims Normal claims are represented as members in a JSON object. The claim name is the member name and the claim value is the member value. 4.2. Aggregated and Distributed Claims Aggregated and distributed claims are represented within the "_claim_names" and "_claim_sources" members of the JSON object. _claim_names This is a JSON object whose member names are the claims names for the aggregated and distributed claims. The member values are references to the member names in the "_claim_sources" member of the claim object from which the actual value can be retrieved. _claim_sources This is a JSON object whose member names are referenced by the member values of the "_claim_names" member of the claim object. The member values contain sets of aggregated claims or reference locations for distributed claims. The member values can have one of the following formats depending on whether they're storing aggregated claims or distributed claims: Sakimura, et al. [Page 11] OpenID Connect Framework 1.0 - draft 05 July 2011 Aggregated Claims A JSON object which MUST contain the "JWT" member whose value is a JWT [JWT] which MUST contain all the claims in the "_claim_names" object which references the corresponding "_claim_sources" member. Other members MAY be present if they are understood by both parties. JWT REQUIRED. JWT Value Distributed Claims A JSON object which contains the following members and values: endpoint REQUIRED. The value is the OAuth 2.0 resource endpoint from which the associated claim can be retrieved. The endpoint URL MUST return the claim as a JWT. access_token OPTIONAL. Access token enabling retrieval of the claims from the endpoint URL by using the OAuth 2.0 BEARER [OAuth.2.0.Bearer] scheme. Claims SHOULD be requested using the Authorization request header field and claims sources MUST support this method. Other members MAY be present, if understood by both parties 4.3. Requests Clients MAY send requests with the following parameters to the UserInfo endpoint to obtain further information about the user. access_token REQUIRED. The access_token obtained from an OpenID Connect authorization request. This parameter MUST NOT be sent if the access token is sent in the HTTP Authorization header. schema OPTIONAL. The schema in which the data is to be returned. The only predefined value is "openid". If this parameter is not included, the response may be a proprietary schema to support backwards compatibility. A URL MAY be passed to define custom schemes not specified by short names. Custom scheme names and responses are out of scope for this specification. id This identifier is reserved for backwards compatibility. It MUST be ignored by the endpoint if the "openid" schema is used. 4.4. Responses If the requested schema is "openid", the response MUST return a plain text JSON object that contains a set of claims that are a subset of those defined below. Additional claims (not specified below) MAY also be returned. Sakimura, et al. [Page 12] OpenID Connect Framework 1.0 - draft 05 July 2011 The UserInfo endpoint MUST return claims in JSON format unless a request for a different format is made by the client in the authorization request. The UserInfo endpoint MAY return claims in JWT format which can be signed or encrypted via JWS [JWS] and JWE [JWE] respectively. Section 3.1.1 describes how to request a different format. The UserInfo endpoint MUST return a content-type header to indicate which format is being returned. The following are accepted content types: +------------------+------------------------+ | Content-Type | Format Returned | +------------------+------------------------+ | application/json | plain text JSON object | +------------------+------------------------+ | application/jwt | A JWT | +------------------+------------------------+ 4.4.1. Example Responses The following is a non-normative normal claims responses: { "name": "Jane Doe" "given_name": "Jane", "family_name": "Doe", "email": "janedoe@example.com", "picture": "http://example.com/janedoe/me.jpg" } The following is a non-normative claims response containing aggregated and distributed claims: Sakimura, et al. [Page 13] OpenID Connect Framework 1.0 - draft 05 July 2011 { "name": "Jane Doe" "given_name": "Jane", "family_name": "Doe", "email": "janedoe@example.com", "picture": "http://example.com/janedoe/me.jpg" "_claim_names": { "birthday": "src1", "eye_color": "src1", "payment_info": "src2", "shipping_address": "src2", "credit_score": "src3" }, "_claim_sources": { "src1": {"JWT": "JWT_header.JWT_part2.JWT_part3"}, "src2": {"endpoint": "https://merchant.example.com/claimsource"}, "src3": {"endpoint": "https://creditagency.example.com/claimshere", "access_token": "ksj3n283dke"} } } 4.5. Errors In addition to the error codes defined in section 4.1.2.1 of OAuth 2.0 [OAuth.2.0], this specification defines the following additional error codes: invalid_access_token The access token is not valid for the requested resource, malformed, is in an incorrect format, outside the valid scope, or expired. invalid_schema The requested schema is invalid or unsupported. Sakimura, et al. [Page 14] OpenID Connect Framework 1.0 - draft 05 July 2011 5. Introspection Endpoint The introspection endpoint returns a text JSON object which contains information about the end user associated with supplied access or ID token. It is for use by clients that cannot or do not wish to handle signed tokens. Request Parameters: One of the following parameters access_token OPTIONAL. A token obtained from the token endpoint. id_token OPTIONAL. An ID token obtained from the authorization request. Both parameters are optional, but at least one parameter MUST be supplied. Response: The response is a text JSON object of an ID token using the "application/json" media type. If the request contains "access token", the authorization server creates a version of an ID token and returns it as a JSON object. However, a session is not created. If the request contains " id_token", then the server returns the text JSON object of the ID token. The following is a non-normative example of a request to the introspection endpoint: Sakimura, et al. [Page 15] OpenID Connect Framework 1.0 - draft 05 July 2011 Request: GET /op/introspection?access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6 ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbXBs ZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20iLCJhdWRpZW5jZSI6ImNsa WVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJleHAiOjEzMDM4NTI4ODB9.a JwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ Host: server.example.com Response: HTTP/1.1 200 OK Content-Type: application/json { "issuer": "http://server.example.com", "client_id": "http://client.example.net", "user_id": "Jane Doe", "aud": "http://client.example.net", "exp": "1236485123" } 5.1. Error Codes In addition to the error codes defined in Section 5.2 of OAuth 2.0 [OAuth.2.0], this specification defines the following error codes. invalid_access_token The access token is not valid for the requested resource, malformed, is in an incorrect format, outside the valid scope, or expired. invalid_id_token The ID token is not valid for the requested resource, malformed, is in an incorrect format, or expired. Sakimura, et al. [Page 16] OpenID Connect Framework 1.0 - draft 05 July 2011 6. Signatures and Encryption Depending on the transport through which the messages are sent, the integrity of the message may not be guaranteed and the originator of the message may not be authenticated. To mitigate these risks, OpenID Connect tokens MAY utilize JSON Web Signatures (JWS) [JWS] to sign the token content. To achieve message confidentiality, OpenID Connect tokens MAY use JSON Web Encryption (JWE) [JWE] to encrypt the token content. Sakimura, et al. [Page 17] OpenID Connect Framework 1.0 - draft 05 July 2011 7. Verification 7.1. Authorization Request Verification If the request was signed, the Server MUST verify the signature as in JWT. 7.2. Authorization Response Verification To verify the validity of the Authorization Response, the client MUST to the following: 1. If the response was signed, the Client SHOULD verify the token signature as the first step. 2. Check that current time is within the validity period contained within the token. 3. Verify that the token was intended for the recipient, using the audience contained within the token. 4. Check that the OP that responded was really the intended OP through a TLS/SSL server certificate check. If the client does not directly verify the signature, it MUST make a request to the Introspection Endpoint to validate the token. 7.3. UserInfo Request Verification If the request was signed, the Server MUST verify the signature as in JWS [JWS]. 7.4. UserInfo Response Verification To verify the validity of the UserInfo response, the client MUST do the following: 1. If the response was signed, the Client SHOULD verify the token signature as the first step. 2. If the response was signed, check that current time is within the validity period contained within the response. 3. If the response was signed, verify that the response was intended for the recipient, using the audience contained within the response. Sakimura, et al. [Page 18] OpenID Connect Framework 1.0 - draft 05 July 2011 4. Check that the OP that responded was really the intended OP through a TLS/SSL server certificate check. Sakimura, et al. [Page 19] OpenID Connect Framework 1.0 - draft 05 July 2011 8. IANA Considerations This document makes no request of IANA. Sakimura, et al. [Page 20] OpenID Connect Framework 1.0 - draft 05 July 2011 9. Security Considerations This specification references the security considerations defined in OAuth 2.0 Security Considerations [OAuth.2.0.SC]. Followings are the list of attack vectors and remedies that were considered for this specification. For details of the attack vector, see [SP800-63]. 9.1. Assertion Manufacture/Modification To mitigate this attack, there are two ways to mitigate it. 1. The assertion may be digitally signed by the OP. The Relying Party SHOULD check the digital signature to verify that it was issued by a legitimate OP. 2. The assertion may be sent over a protected channel such as TLS/ SSL. In order to protect the integrity of assertions from malicious attack, the OP MUST be authenticated. In this specification, the assertion is always sent over TLS/SSL protected channel. 9.2. Assertion Disclosure The Assertion disclosure can be mitigated in the following two ways. 1. Assertion is sent over TLS/SSL protected channel, where RP is authenticated by "client_id" and "client_secret". 2. Signed Assertion is encrypted by the RP's public key. 9.3. Assertion Repudiation To mitigate this threat, the assertion may be digitally signed by the OP using a key that supports non-repudiation. The RP SHOULD check the digital signature to verify that it was issued by a legitimate OP. 9.4. Assertion Redirect To mitigate this threat, the assertion includes the identity of the RP for whom it was generated as "client_id". The RP verifies that incoming assertions include its identity as the recipient of the assertion. Sakimura, et al. [Page 21] OpenID Connect Framework 1.0 - draft 05 July 2011 9.5. Assertion Reuse The assertion includes a timestamp and a short lifetime of validity. The Relying Party checks the timestamp and lifetime values to ensure that the assertion is currently valid. 9.6. Secondary Authenticator Manufacture Due to the large entropy requirement of the Artifact ("code") and short life nature of its validity, the success probability of this attack is extremely low. 9.7. Secondary Authenticator Capture Secondary authenticator (="code") is transmitted only through HTTPS, thus it is protected between the OP and the User-Agent, and User- Agent and the RP. Only the place it can be captured is the User-Agent where the TLS session is terminated, and is possible if the User-Agent is infested by malwares. However, it renders no usefulness as long as the profile in use either RP authentication or assertion encryption. 9.8. Assertion Substitution Responses to assertion requests is bound to the corresponding requests by message order in HTTP, as both assertions and requests are protected by TLS that can detect and disallow malicious reordering of packets. 9.9. Authentication Request Disclosure If the authentication request is POSTed directly through a protected channel, it is not possible to disclose the authentication request. If the Request File is encrypted by the OP's public key, the authentication request will not be disclosed unless OP's private key gets compromised or the encryption algorithm becomes vulnerable. 9.10. Timing Attack Timing attack can be used to reduce the effective key length of the signature if the time required to return the response in case of a signature error and a correct signature differs. Care should be taken in the implementation to avoid this attack. Sakimura, et al. [Page 22] OpenID Connect Framework 1.0 - draft 05 July 2011 9.11. Authentication Process Threats In the category of Authentication Process Threats, following threats exists. o Online guessing o Phishing o Pharming o Eavesdropping o Replay o Session hijack o Man-in-the-middle Authentication process per se as described in NIST SP800-63-rev1 is out of scope for this protocol, but care SHOULD be taken to achieve appropriate protection. Sakimura, et al. [Page 23] OpenID Connect Framework 1.0 - draft 05 July 2011 10. Open Issues and Things To Be Done (TBD) [[ To be removed from the final specification ]] Following items remain to be done in this draft: o Finish the security consideration section. o Properly capitalize the Defined Words. o Provide more structure to the OpenID Request Object section. Sakimura, et al. [Page 24] OpenID Connect Framework 1.0 - draft 05 July 2011 11. Normative References [ISO29115] McCallister, E., "ITU-T Recommendation X.eaa | ISO/IEC 2nd CD 29115 -- Information technology - Security techniques - Entity authentication assurance framework", ISO/IEC 29115. [JWE] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, "JSON Web Encryption", March 2011. [JWS] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, "JSON Web Signatures", April 2011. [JWT] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, "JSON Web Token", July 2011. [OAuth.2.0] Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, "OAuth 2.0 Authorization Protocol", July 2011. [OAuth.2.0.Bearer] Jones, M., Hardt, D., and D. Recordon, "OAuth 2.0 Protocol: Bearer Tokens", July 2011. [OAuth.2.0.SC] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", July 2011. [OpenID.Core] Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, "OpenID Connect Core 1.0", July 2011. [OpenID.UserInfo] Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., Jay, E., and G. George, "OpenID Connect UserInfo 1.0", July 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009. [SP800-63] Sakimura, et al. [Page 25] OpenID Connect Framework 1.0 - draft 05 July 2011 National Institute of Standards and Technology, "NIST SP800-63rev.1: Electronic Authentication Guideline", NIST SP800-63. Sakimura, et al. [Page 26] OpenID Connect Framework 1.0 - draft 05 July 2011 Appendix A. Acknowledgements Sakimura, et al. [Page 27] OpenID Connect Framework 1.0 - draft 05 July 2011 Appendix B. Document History [[ To be removed from the final specification ]] -05 o Corrected examples. o Removed obsolete signing text left over from Artifact Binding draft. -04 o Correct issues raised by Pam Dingle and discussed on the mailing list after the 7-Jul-11 working group call. o Adopted long_names. -03 o Correct issues raised by Johnny Bufu and discussed on the 7-Jul-11 working group call. -02 o Consistency and cleanup pass, including removing unused references. o Moved "display" and "prompt" parameter definitions from the Framework spec back to the Core spec. -01 o Added RFC5656/BCP47 locale information to claims requests. -00 o Split from core when all optional features were removed. Sakimura, et al. [Page 28] OpenID Connect Framework 1.0 - draft 05 July 2011 Authors' Addresses Nat Sakimura Nomura Research Institute, Ltd. Email: n-sakimura@nri.co.jp John Bradley Protiviti Government Services Email: jbradley@mac.com Michael B. Jones Microsoft Corporation Email: mbj@microsoft.com Breno de Medeiros Google Email: breno@google.com Chuck Mortimore Salesforce Email: cmortimore@salesforce.com Edmund Jay MGI1 Email: ejay@mgi1.com Sakimura, et al. [Page 29]