TOC 
DraftN. Sakimura
 NRI
 J. Bradley
 Protiviti
 M. Jones
 Microsoft
 B. de Medeiros
 Google
 C. Mortimore
 Salesforce
 E. Jay
 MGI1
 July 12, 2011


OpenID Connect Framework 1.0 - draft 04

Abstract

This document describes the more advanced request and response formats for OpenID Connect.

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].



Table of Contents

1.  Introduction
2.  Terminology
3.  Authorization Endpoint
    3.1.  Authorization Request
        3.1.1.  OpenID Request Object
    3.2.  Authorization Response
    3.3.  Authorization Error Response
4.  UserInfo Endpoint
    4.1.  Normal Claims
    4.2.  Aggregated and Distributed Claims
    4.3.  Requests
    4.4.  Responses
        4.4.1.  Example Responses
    4.5.  Errors
5.  Introspection Endpoint
    5.1.  Error Codes
6.  Signatures
7.  Encryption
8.  Verification
    8.1.  Authorization Request Verification
    8.2.  Authorization Response Verification
    8.3.  UserInfo Request Verification
    8.4.  UserInfo Response Verification
9.  IANA Considerations
10.  Security Considerations
    10.1.  Assertion Manufacture/Modification
    10.2.  Assertion Disclosure
    10.3.  Assertion Repudiation
    10.4.  Assertion Redirect
    10.5.  Assertion Reuse
    10.6.  Secondary Authenticator Manufacture
    10.7.  Secondary Authenticator Capture
    10.8.  Assertion Substitution
    10.9.  Authentication Request Disclosure
    10.10.  Timing Attack
    10.11.  Authentication Process Threats
11.  Open Issues and Things To Be Done (TBD)
12.  Normative References
Appendix A.  Acknowledgements
Appendix B.  Document History
§  Authors' Addresses




 TOC 

1.  Introduction

The OpenID Connect Core 1.0 (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” July 2011.) [OpenID.Core].0 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.



 TOC 

2.  Terminology

The terms used in this specification are defined in OpenID Connect Core 1.0 (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” July 2011.) [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.



 TOC 

3.  Authorization Endpoint

This specification introduces some new parameters to the OpenID Connect Core (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” July 2011.) [OpenID.Core] Authorization Request.



 TOC 

3.1.  Authorization Request

Section 4.1.1 and 4.2.1 of OAuth 2.0 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” July 2011.) [OAuth.2.0] defines OAuth Authorization Request parameters.

The following extension parameters are defined:

request
OPTIONAL. A JWT (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” March 2011.) [JWT] encoded OpenID Request Object (OpenID Request Object).
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=HeADeR.pAyl0rd.cRypT0
&prompt=login
&display=popup
HTTP/1.1
Host: server.example.com


 TOC 

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 (Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., Jay, E., and G. George, “OpenID Connect UserInfo 1.0,” July 2011.) [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 (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” March 2011.) [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.

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 (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” March 2011.) [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.



 TOC 

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 (Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.) [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 (Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.) [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 "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.



 TOC 

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.)
iso29115
OPTIONAL. (entity authentication assurance): Specifies the X.eaa / ISO/IEC29115 (McCallister, E., “ITU-T Recommendation X.eaa | ISO/IEC 2nd CD 29115 -- Information technology – Security techniques – Entity authentication assurance framework,” .) [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



 TOC 

3.2.  Authorization Response

Authorization responses are defined in the OpenID Connect Core (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” July 2011.) [OpenID.Core] specification.



 TOC 

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 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” July 2011.) [OAuth.2.0].



 TOC 

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.



 TOC 

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.



 TOC 

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:
Aggregated Claims
A JSON object which MUST contain the "JWT" member whose value is a JWT (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” March 2011.) [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 (Jones, M., Hardt, D., and D. Recordon, “OAuth 2.0 Protocol: Bearer Tokens,” June 2011.) [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


 TOC 

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.


 TOC 

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.

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 (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.) [JWS] and JWE (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Encryption,” March 2011.) [JWE] respectively. Section 3.1.1 (OpenID Request Object) 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-TypeFormat Returned
application/json plain text JSON object
application/jwt A JWT



 TOC 

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:

{
 "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_hdr.JWT_claims.JWT_crypto"},
   "src2": {"endpoint": "https://merchant.example.com/claimsource"},
   "src3": {"endpoint": "https://creditagency.example.com/claimshere", "access_token": "ksj3n283dke"}
  }
}



 TOC 

4.5.  Errors

In addition to the error codes defined in section 4.1.2.1 of OAuth 2.0 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” July 2011.) [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.


 TOC 

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:

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"
}



 TOC 

5.1.  Error Codes

In addition to the error codes defined in Section 5.2 of OAuth 2.0 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” July 2011.) [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.


 TOC 

6.  Signatures

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 utilizes JSON Web Signatures (JWS) (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.) [JWS].

Following is the parameters for JWT.

typ
OPTIONAL. One of "JWT", "openid2json+sig".
alg
REQUIRED. One of the algorithm values specified in Table 3 of JWS (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.) [JWS]

Compact Serialization SHOULD BE used when passing it through query parameters, while JSON serialization SHOULD BE used when returning it in HTTP Body.

Following is a non-normative example of such signature in Compact serialization, where HS256 algorithm was used (with line breaks for display purposes only):

eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk


 TOC 

7.  Encryption

To achieve message confidentiality and audience restriction, OpenID Connect uses JSON Web Encryption (JWE) (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Encryption,” March 2011.) [JWE].



 TOC 

8.  Verification



 TOC 

8.1.  Authorization Request Verification

If the request was signed, the Server MUST verify the signature as in JWT.



 TOC 

8.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.



 TOC 

8.3.  UserInfo Request Verification

If the request was signed, the Server MUST verify the signature as in JWS (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.) [JWS].



 TOC 

8.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.
  4. Check that the OP that responded was really the intended OP through a TLS/SSL server certificate check.


 TOC 

9.  IANA Considerations

This document makes no request of IANA.



 TOC 

10.  Security Considerations

This specification references the security considerations defined in OAuth 2.0 Security Considerations (Lodderstedt, T., Ed., McGloin, M., Hunt, P., and A. Nadalin, “OAuth 2.0 Security Considerations,” April 2011.) [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] (National Institute of Standards and Technology, “NIST SP800-63rev.1: Electronic Authentication Guideline,” .).



 TOC 

10.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.


 TOC 

10.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.


 TOC 

10.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.



 TOC 

10.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.



 TOC 

10.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.



 TOC 

10.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.



 TOC 

10.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.



 TOC 

10.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.



 TOC 

10.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.



 TOC 

10.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.



 TOC 

10.11.  Authentication Process Threats

In the category of Authentication Process Threats, following threats exists.

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.



 TOC 

11.  Open Issues and Things To Be Done (TBD)

[[ To be removed from the final specification ]]

Following items remain to be done in this draft:



 TOC 

12. 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,” March 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,” June 2011.
[OAuth.2.0.SC] Lodderstedt, T., Ed., McGloin, M., Hunt, P., and A. Nadalin, “OAuth 2.0 Security Considerations,” April 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 (TXT, HTML, XML).
[RFC5646] Phillips, A. and M. Davis, “Tags for Identifying Languages,” BCP 47, RFC 5646, September 2009 (TXT).
[SP800-63] National Institute of Standards and Technology, “NIST SP800-63rev.1: Electronic Authentication Guideline,” NIST SP800-63.


 TOC 

Appendix A.  Acknowledgements



 TOC 

Appendix B.  Document History

[[ To be removed from the final specification ]]

-04

-03

-02

-01

-00



 TOC 

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