OpenID Artifact Binding 1.0

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

In addition to the terminology used in , following terms are used. An Artifact is a small text associated with the larger payload that identifies the payload. Base 64 Encoding with URL and Filename Safe Alphabet without padding An unique identifier that the client to identify itself to the authorization server. A shared secret established between the authorization server and client. The authorization server's HTTP endpoint capable of authenticating the end-user and obtaining authorization. The authorization server's HTTP endpoint capable of issuing tokens. end-user endpoint and token endpoint. The endpoint to which the OP responses are returned through redirect. The authorization server's HTTP endpoint capable of issuing client identifiers and optional client secrets. The authorization server's HTTP endpoint capable of registering the request file and return request_uri. A protected resource that when presented with a token by the client returns authorized information about the current user. Compact Serialization defined in JSON Simple Sign.

The Relying Party (RP) learns the OpenID Provider Endpoints (OP Endpoints) either out-of-band or through the discovery process defined elsewhere such as . Exact mechanism for the discovery is out of scope of this specification. The relying party prepares a file that contains all the request parameters and registered at a 'request_uri'. OP may provide the service that allows the RP to register the file and obtain a OP accessible 'request_uri' for the request. If the RP is not registered with the OP by then, the RP may register with the OP and obtain 'client_secret'. The Relying Party redirects the end user's User-Agent to the end-user endpoint with the 'request_uri' to obtain the end-user authorization. The OP establishes whether the end user is authorized to perform OpenID Authentication and wishes to do so. The manner in which the end user authenticates to their OP and any policies surrounding such authentication is out of scope for this document. The OP redirects the end user's User-Agent back to the RP with 'code' which stands for an Artifact of the Assertion. The RP requests the assertion from the token endpoint through direct communication (Direct Assertion Request and Response) through HTTP POST. The Relying Party verifies the information received from the OP. If the assertion is signed, the signature MUST be checked first. If the verified claimed_id belongs to the OP's domain, the assertion is deemed valid. Otherwise, a discovery MUST be performed at the 'claimed_id' to make sure that the OP really is delegated authoritatively. Note that this specification does not use type signature. The message integrity that provides are provided by the TLS/SSL. Thus, in the most basic case, the assertion does not have to be signed at all. On the other hand, the messages MAY be signed using the OP's signing key that supports non-repudiation to mitigate the assertion-repudiation attack.

Followings are parameters used in this specification. Most of them are specific to a particular profile and optional. ns Value: "http://openid.net/specs/ab/1.0". Discovery of the Artifact Binding service is achieved via the mechanism described in . This namespace SHOULD be listed as an <xrd:Type> child element of the <xrd:Service> element in the XRDS discovery document. type Value: The URI that expresses the class of the JSON message. id Value: Value of type xs:string that identifies the instance of the JSON message. mode Signifies the mode of this request / response. Value: "direct_assertion_req" / "direct_req" / "id_res" / "art_req" / "art_res" / "client_associate" / "req_reg" / "req_reg_res" request_uri Value: (OPTIONAL) URL of the Request File. Optionally, one can put the SHA256 hash of the file after "#". "#" MUST be escaped. refresh_uri Value: (OPTIONAL) Array of URL of the Assertion Refresh Endpoint, from which client can obtain the refreshed assertion. The presence of this parameter in the assertion indicates that the permission was granted by the user to refresh the assertion. code Value: A unique short string less than 400 characters, also known as "Artifact". op_endpoint Value: The OP Endpoint URL. claimed_id Value: An URI that corresponds to the user in question. The value in the request is either user supplied identifier or the string "http://specs.openid.net/auth/2.0/identifier_select" which tells the OP to chose the identifier that belongs to the user. Type: A String of type xs:AnyURI. identity Value: The OP-Local Identifier, an identifier that corresponds to the user's Local Identifier at the OP. If a different OP-Local Identifier is not specified, the claimed identifier MUST be used as the value for identity. Type: xs:String. user_id Value: A locally unique and never reassigned identifier for the user. Type xs:String. redirect_uri Value: URL to which the OP SHOULD return the User-Agent with the response indicating the status of the art_res. If this value is not sent in the request it signifies that the Relying Party does not wish for the end user to be returned. It used to be "return_to" in the OpenID 2.0. "return_to" MUST NOT be used. Type xs:AnyURI client_id Value: A unique identifier issued to the client to identify itself. Type: xs:String server_id Value: A unique identifier that identifies the OP. Type: xs:String client_secret Value: A token that can be used by the OP to identify and authenticate the RP. Type: xs:String immediate Value: (OPTIONAL) "true" or "false". If set to "true", the authorization server MUST NOT prompt the end-user to process the request. If the OP does not support an immediate check or if it is unable to establish the end-user's identity or approval status, it MUST deny the request without prompting the end-user. Defaults to "false" if omitted. It overrides what was expressed in the request file. pubkey Value: Base64url encoded DER format X.509 Certificate without private key. (RFC1421 - RFC1424) Format. certs_uri Value: A URL from which one can retrieve PEM format X.509 certificate. One may add the sha256 hash of the content as a fragment to signify if the file has changed. certs_uri_alt Value: Alternative 'certs_uri'. If it is specified, this URL SHOULD be checked in the event of certs_uri failing. state Value: (OPTIONAL) An opaque value used by the RP to maintain state between the request and callback. The OP includes this value when redirecting the user-agent back to the client. code Value: The Artifact value corresponding to the Assertion created. The Artifact value MUST include the string constructed from a cryptographically strong random or pseudorandom number sequence RFC1750 generated by the OP. atype Value: Type of assertion to be returned at the end. Values are one of the following: openid2json : (Default) OpenID Artifact Binding's default assertion format, which is JSON. openid2jsonp : openid2json wrapped in "openidjsonp();" so that it will be a JSONP format. openid2json-enc: openid2json assertion encrypted. saml2: SAML ver.2 assertion. wss : WS-Security assertion. proofkey Value: X.509 public key certificate presented by the user to the OP during authentication. response_type Value: The requested response: an access token, an authorization code, or both. The parameter value MUST be set to "token" for requesting an access token, "code" for requesting an authorization code, or "code_and_token" to request both. The authorization server MAY decline to provide one or more of these response types. grant_type Value: The access grant type included in the request. Value MUST be one of "authorization_code", "password", "assertion", "refresh_token", or "none". access_token Value: The access token issued by the OP. The Authorization header field uses the framework defined by RFC2617 access_token_secret Value: The corresponding access token secret as requested by the client. issued_at Value: A unix timestamp of when this signature was created. expires_in Value: The duration in seconds of the access token lifetime. refresh_token Value: The refresh token used to obtain new access tokens using the same end user access grant as described in Section 4. oauth_token Value: The access_token obtained or the Compact Serialization of the Assertion obtained, suitably signed. token_type Value: Used in conjunction with oauth_token when oauth_token is a Compact Serialization of the Assertion obtained. "openid" if it is not signed by the client, and "openid+sig" if it is signed by the client.

Key-Value form encoding is a special file format defined in defined in section 4. It is used as a direct response in this specification. It SHOULD only contain the OpenID parameters. OpenID JSON Encoding is the embodiment of Key-Value form encoding parameters in JSON. The parameters are serialized into a JSON object as a sequence of name/value pairs. The JSON object is represented as the value of the "openid" name. Following is a non-normative example.

Request File is a UTF-8 JSON format file that captures the parameters that the RP would like to send to the OP to obtain an artifact. Following is the list of OpenID variables are to be sent under the key "openid": type - "http://openid.net/specs/ab/1.0#req" immediate - (OPTIONAL) "True" or "False". Default is "False". claimed_id - (OPTIONAL) The claimed_id as in OpenID 2.0 identity - (OPTIONAL) The local id as in OpenID 2.0. server_id - (OPTIONAL) The intended recipient of this request. pubkey - (OPTIONAL) The base64url encoded DER format X.509 certificate of the RP. Note that these are to be serialized into JSON and then represented as a value of the key "openid". Following is the list of variables to be sent as the top level keys: response_type - value: "code". client_id - The client identifier recognized by the authorization server. redirect_uri - The absolute URI to which the OP asks the User-Agent to come back with an artifact ("code"). scope - value: "openid". state - OPTIONAL. Following is a non-normative example.

Positive Assertion is a set of data that an OP sends out to the RP on successful Authentication. The default format is the . Following is the list of variables to be included under the key "openid". type - "http://openid.net/specs/ab/1.0#id_res" mode - "id_res" op_endpoint - OP Endpoint URL from which this assertion was returned. cilent_id - The RP's unique identifier. server_id - The Server's unique identifier claimed_id - The verified identifier of this user. identity - The Local ID that this user was verified against. user_id - (OPTIONAL) A unique HTTPS URI of the currently signed in user. issued_at - A unix timestamp of when this signature was created. refresh_uri - An array of the assertion refresh endpoint URLs. Any other extension and other variables can be included. Following is the list of variables to be included at the top level. access_token - The access token issued by the authorization server. state - REQUIRED if the state parameter was present in the client authorization request. Set to the exact value received from the client. Following is a non-normative example.

Artifact Binding does not use symmetric signature as it adds no value over the mandatory TLS connection to the OP. To mitigate assertion repudiation attack, the assertion may be digitally signed by the OP using a key that supports non-repudiation as in JSON Simple Sign where parameters are as follows. "type":"http://openid.net/specs/ab/1.0#signed_format" "data_type":"application/json" "data":base64url encoded JSON representation of the assertion. "algorithm":"RSA-SHA256" Following is the non-normative illustration of a signed response. (Note: Line wraps in the values are only for the display purpose. New lines MUST be escaped in JSON values.)

In the response, the payload may be encrypted by RP's public key for additional security. If it is encrypted, the data is formatted as JSON Encryption Envelope. The following parameter MUST be set as follows: data_type - "http://openid.net/specs/ab/1.0#openid2json-enc" Following is a non-normative example of encrypted payload.

Communication Types are the same as in section 5 apart from the fact that we call "indirect" in the above as "redirect" to avoid confusion in the terminology used at NIST SP800-63. In addition to those defined, the Artifact Binding uses Direct Communication for sending and receiving authentication message. All Direct Communication MUST be over SSL/TLS encrypted channel.

There are certain processing that are common to all usage patterns, namely, Initiation, Normalization, and Discovery. Steps are as follows:

UA: Click Login UA->RP: Login with identifier RP->RP: Normalize identifier RP->OP: Get XRDS RP->RP: Find OP Endpoint ]]>

Initiation is done as in Following is the non-normative explanation of the process. To initiate OpenID Authentication, the Relying Party SHOULD present the end user with a form that has a field for entering a User-Supplied Identifier. The form field's "name" attribute SHOULD have the value "openid_identifier", so that User-Agents can automatically determine that this is an OpenID form. Browser extensions or other software that support OpenID Authentication may not detect a Relying Party's support if this attribute is not set appropriately.

Normalization is done as in Following is a non-normative, simplified explanation of the Normalization process. If the user supplied identifier string starts with "xri://", strip it. If the user supplied identifier string starts with "=", "@", "+", "$", "!", or "(", add https://xri.net/ to the string. If the user supplied identifier string does not start yet with "http://" or "https://", add "http://". If the user supplied identifier starts with http:// or https:// do nothing.

Discovery is the process where the Relying Party uses the Identifier to look up ("discover") the necessary information for initiating requests, especially the OP Endpoint. When OP Endpoint and other meta-data is known out of band, discovery is unnecessary. Discovery should be performed as in Section 7.3 of OpenID Authentication 2.0 . Optionally, if the RP does not wish to use RSA signature to authenticate itself, RP may obtain the secret dynamically in the following manner.

In Artifact Binding, the OP endpoint MUST be HTTPS endpoint. Therefore, the symmetric signature between the servers that were used in OpenID Authentication 2.0 (POST/GET binding) is unnecessary. Instead, for the RP authentication against the OP, 'client_secret' is used. The 'client_secret' is either the bearer token assigned by the OP or the RSA signature, which will be discussed later.

If the RP opted for the bearer token (note: in this mode, there will be no possibility of non-repudiation of the request), then RP must somehow obtain the secret. This can be achieved in the following manner. Issue HTTPS "POST" request to the Client Regsitration Endpoint with the following REQUIRED parameters: type - "push" client_name - A human-readable name of the client. client_uri - The URL of the homepage of the client. client_desc - A text description of the client. client_icon - OPTIONAL. A URL for an icon for the client. As Most OP will display an AuthN/AuthZ page on HTTPS, the client_icon which RP registers should have HTTPS URL. redirect_uri - The URL to which the OP should send its response. The client MAY include additional metadata in the request and the authorization server MAY ignore this additional information.

Following is a non-normative example of such request. If the redirect_uri was not pre-registered out-of-band, then he server should issue the following response parameters in JSON format. client_id client_secret server_id - OPTIONAL. Server's unique identifier. issued_at - OPTIONAL. Specifies the timestamp when the identifier was issued. The timestamp value MUST be a positive integer. The value is expressed in the number of seconds since January 1, 1970 00:00:00 GMT. expires_in - OPTIONAL; if supplied, the issued_at parameter is REQUIRED. Specifies the valid lifetime, in seconds, of the identifier. The value is represented in base 10 ASCII. The parameters are included in the entity body of the HTTP response using the "application/json" media type as defined by JSON. The parameters are serialized into a JSON structure by adding each parameter at the highest structure level. Parameter names and string values are included as JSON strings. The authorization server MUST include the HTTP Cache-Control response header field with a value of no-store in any response containing client_secret.

Following is a non-normative example of such response. If the request for registration is invalid or unauthorized, the authorization server constructs the response by adding the following parameters to the entity body of the HTTP response with a 400 status code (Bad Request) using the “application/json” media type: error description - OPTIONAL.

Following is a non-normative example of such response. Note that the line wraps are for display purpose only.

If the OP desires evidential quality / non-repudiation possibility of the request from the RP through public key cryptography, then it MUST use the RSA signature mode or EC-DSA signature mode. Unless the OP has the public key by some out-of-band mechanism, the RP MUST send its Public Key as described in JSON Simple Sign. If the RP desires evidential quality / non-repudiation possibility of the response from the OP thorugh public key cryptography, then it MUST use the RSA signature mode or EC-DSA signature mode. Unless the RP has the public key of the OP by some out-of-band mechanism, the OP MUST send its Public Key as described in JSON Simple Sign.

All steps in the following profiles are preceded by the common processing. The assertion returned may vary in the following five ways depending on the security characteristics that RP wishes to have. Plain Text Assertion. Signed Assertion. Signed and Encrypted Assertion. Holder of Key Other Assertion Types

The RP prepares a static file with a globally reachable URL. Optionally, it may contain other extension parameters. It MAY be signed as in

RP then records the Request File either locally or remotely and obtains the URL, "request_uri". The URL MUST be accessible from the OP. Optionally, an OP may provide the Request File registration service at the request registration endpoint. This is especially useful for the cases such as the RP is behind the firewall or lives on a client device that cannot be accessed from the OP. When an OP provides the Request File registration service, it SHOULD publish the registration endpoint in the XRDS where the <Type> is "http://openid.net/specs/ab/1.0#request_regist" or in the XRD where "rel" is "http://openid.net/specs/ab/1.0#request_regist". To register the Request File, the following parameters are sent as HTTPS POST request to the request registration endpoint as query parameters. request - The Base64url encoded JSON request file. client_secret - (OPTIONAL) client secret assigned to the RP. Following is a non-normative example of such request.

If the request is valid, the OP returns the following variables as the OpenID JSON in the HTTP response body using the “application/json” media type: type - "http://openid.net/specs/ab/1.0#req_req_res" request_uri - The request URL that corresponds to the request file. It should be noted that if the Request File includes user's attribute values, it MUST NOT be revealed to anybody but the OP before the user's authentication and authorization. As such, the request_uri MUST have larger entropy than the user authentication credential. Following is a non-normative example of the response.

When the user wishes to access an RP resource, and the user is not yet authorized to do so, the RP sends the user to the OP Endpoint through the HTTP 302 redirect with the following parameters. The entire URL MUST NOT exceed 512 bytes. response_type - "code" request_uri - The URL of the Request File. immediate - (OPTIONAL) "true" or "false". Used to override what was written in the Request File. claimed_id - (OPTIONAL) claimed_id MAY be sent as flow parameter to override what is written in the Request File. state - (OPTIONAL) An opaque value used by the RP to maintain state between the request and callback. If provided, the OP MUST include this value when redirecting the user-agent back to the RP. RPs are strongly advised to use this variable to relate the request and response. Following is a non-normative example. Note: Line wraps are for display purpose only.

Upon receipt of the Request, the OP SHOULD send a GET request to the 'request_uri' to retrieve the content unless it is already cached and parse it to recreate the request parameters.

Once this is done, the OP MUST determine that an authorized end user wishes to complete the authentication in the manner described in Section 10 of the . Once it is determined, the OP creates either positive or negative assertion and associated artifact and returns the response to the RP Endpoint specified in "redirect_uri" URL specified in with following parameters respectively in the follwing cases:

code - The artifact Value. state - Set to the exact value received from the RP. server_id - The Server Identifier. No other parameter SHOULD be returned. The entire URL MUST NOT exceed 512 bytes. Following is a non-normative example. Line wraps after the second line is for the display purpose only.

error - A single error code as described below. request_uri - Set to the exact value received from the RP. state - Set to the exact value received from the RP. No other parameter SHOULD be returned. The entire URL MUST NOT exceed 512 bytes. Error codes are as follows: invalid_request - The request is missing a required parameter, includes an unsupported parameter or parameter value, or is otherwise malformed. invalid_client - The client identifier provided is invalid. unauthorized_client The client is not authorized to use the requested response type. redirect_uri_mismatch - The redirection URI provided does not match a pre-registered value. access_denied - The end-user or authorization server denied the request. unsupported_response_type - The requested response type is not supported by the authorization server. invalid_scope - The requested scope is invalid, unknown, or malformed. setup_needed - "immediate" request denied so that the user interaction was required. Following is a non-normative example. Line wraps after the second line is for the display purpose only.

To obtain the assertion, the RP makes a direct request to the Token Endpoint. The RP may authenticate against the OP depending on the level of assurance desired. There are two ways of authentication, namely: Through the use of client_secret Through the use of asymmetric signature Added benefit of using asymmetric signature are as follows: One can achieve the non-repudiation of the request One do not need to have association or dynamic association OP does not need to keep the state on each and every RP The asymmetric signature based "client_secret" can be created as follows: Apply JSON Simple Sign to 'code'. Use Comapct Serialization.

To obtain the assertion, send the following parameters via HTTPS POST to the token endpoint using the application/x-www-form-urlencoded format in the HTTP request entity-body: grant_type - "authorization_code" code - The artifact received client_id - The client_id of the RP client_secret - (OPTIONAL) If the secret_type is "shared", send the pre-shared secret. If the secret_type is "jsst", send the Web Token serealization of the JSON Simple Sign over the 'code'. secret_type - (OPTIONAL) "shared" or "jsst". Required if "client_secret" was used. The following is a non-normative example. Line wraps are for display purpose only.

Upon receipt of the Direct Assertion Request, OP MUST return either Positive or Negative Assertion that corresponds to the received Artifact "code".

Positive Assertion can only be returned once for the artifact and contains the following variables under the key "openid". type - "http://openid.net/specs/ab/1.0#id_res" server_id - The identifier of the OP. pubkey - OPTIONAL. The OP's X.509 certificate in DER format which is base64url encoded. client_certs - OPTIONAL. The client's X.509 certificate in DER format which is base64url encoded. client_certs_uri - OPTIONAL. The URL of the client's X.509 certificate in PEM format. request_uri - The exact request_uri URL that the OP received from the RP. op_endpoint - The OP Endpoint URL. claimed_id - The claimed_id that the OP recognizes as linked to the Local ID, "identity". identity - The Local ID that was verified by the OP. cileint_id - The identifier of the requesting RP that OP recognized. user_id - A unique persistent HTTPS URI of the currently signed in user. e.g. "https://op.example.com/a3flsjeow1234" issued_at - A unix timestamp of when this signature was created. refresh_uri - OPTIONAL. An array of the URLs to which this assertion can be sent to obtain the refreshed assertion later. Any other variables can be added. Following variables are returned as the top level variables. access_token - The access token issued by the authorization server. expires_in - OPTIONAL. The duration in seconds of the access token lifetime. For example, the value 3600 denotes that the access token will expire in one hour from the time the response was generated by the authorization server. refresh_token - OPTIONAL. The refresh token used to obtain new access tokens. It MUST be formatted in the JSON or JSONP format depending on the atype in the request. Following is an example of an assertion.

There are cases where the assertion is presented to different server than the originator. If such use is expected of the assertion, the original authorization assertion MUST NOT include the value to the user attributes except "claimed_id" and "identity". Such assertion MAY be presented to each refresh_uri so that the server can return the attributes that it is authoritative to.

If the assertion request is invalid or unauthorized, the authorization server constructs the response by adding the following parameter to the entity body of the HTTP response using the "application/json" media type: error - REQUIRED. A single error code as described below. error_description - OPTIONAL. A human-readable text providing additional information, used to assist in the understanding and resolution of the error occurred. error_uri - OPTIONAL. A URI identifying a human-readable web page with information about the error, used to provide the end-user with additional information about the error. The error code is as follows: invalid_request - The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed. invalid_client - The client identifier provided is invalid, the client failed to authenticate, the client did not include its credentials, provided multiple client credentials, or used unsupported credentials type. unauthorized_client - The authenticated client is not authorized to use the access grant type provided. invalid_grant - The provided access grant is invalid, expired, or revoked (e.g. invalid assertion, expired authorization token, bad end-user password credentials, or mismatching authorization code and redirection URI). unsupported_grant_type - The access grant included - its type or another attribute - is not supported by the authorization server. invalid_scope - The requested scope is invalid, unknown, malformed, or exceeds the previously granted scope.

Upon receipt of the JSON formatted positive assertion, the RP SHOULD parse it to obtain the openid parameters. Then, the RP SHOULD perform the verification as follows: Check that OP that it connected was really the intended OP through TLS/SSL server certificate check. Check if "type" is "http://openid.net/specs/ab/1.0#id_res". Check if the current time is after "issued_at" and before "issued_at" + "expires_in". If "claimed_id" was not sent in the request or different than what was sent, perform the discovery on the "claimed_id" in the assertion. Compare "claimed_id", "identity", "op_endpoint" to the discovered or "out-of-band known" values.

To mitigate Assertion-repudiation attack, 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. In this case, the Assertion will be encoded as described in . Public key of the OP MUST be included in the assertion as 'certs_uri' or 'pubkey'. If the Assertion is signed, the signature validation MUST be performed before other verifications specified in

Further, the signed assertion MAY optionally be encrypted based on the RP's public key of the intended recipient to achieve end-to-end encryption and to increase the assurance level of the information protection in the assertion through audience restriction. This is especially useful when the assertion is passed through a medium where the SSL is terminated one or more times, such as an active client. To achieve this, in the Request File , it MUST contain "enc_key", "enc_type" in addition. The assertion will be returned in the format discribed in Encryption using the received "enc_key" and "enc_type". Encryption SHOULD be the last process before the OP returning the assertion.

To achieve the highest level of assurance, the assertion MAY optionally include "proofkey" as one of the field, which can be subsequently used at the RP to further authenticate the user.

When RP wishes to obtain other type of assertion than OpenID, it MAY request one by specifying "atype" in the Request File or as a request parameter in an Artifact Request.

Client may use the assertion obtained to refresh the assertion. To do so, the client may send the following parameters via HTTPS POST to the refresh_uri using the application/x-www-form-urlencoded format in the HTTP request entity-body: grant_type - "assertion" assertion_type - "http://openid.net/specs/ab/1.0/" assertion - Comapct Serialization of the signed assertion previously received. For higher security, the client should add its signature to the assertion. The following is a non-normative example. Line wraps are for display purpose only.

Upon receipt of the request, the server MUST verify the validity of the signatures. Note that the server_id must be itself or the OP that the receiving server trust as the user's authorization endpoint. If the client added its signature, the server MUST verify that the signature is that of the client with "client_id" stated in the assertion.

Clients MAY access protected resources by presenting an access token to the resource server. Access Token MAY be sent as either the access_token received or Comapct Serializationn of the signed assertion. If higher security level is sought, the client SHOULD add its signature to the assertion so that the server can authenticate the client. If the Comapct Serialization of the Signed OpenID Assertion is used, the following parameter SHOULD be sent with the API request. token_type - The value: "openid" or "openid+sig"

Following is a non-normative example of such an API access. How the resource is being actually accessed is out-of-scope of this specification. However, the resource server MUST verify the validity of the access_token before granting access. The verification of the access_token when token_type is "openid" or "openid+sig" is performed in the following steps. If token_type is "openid+sig", verify the client signature. Verify the server signature. Verify the validity period of the assertion. Other application specific verification SHOULD be performed on top of it.

Extensions are as defined in Section 12 of . In addition, this specification adds following list to the disallowed aliases. request_uri, refresh_uri, op_endpoint, user_id, redirect_uri, client_id, server_id, client_secret, immediate, pubkey, certs_uri, state, code, atype, proofkey, enc_data, enc_key, enc_iv, enc_type, enc_ref, access_token, access_token_secret, issued_at, expires_in, refresh_token.

Followings are the list of attack vectors and remedies that were considered for this specification. For details of the attack vector, see .

To mitigate this attack, there are two ways to mitigate it. 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. 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.

The Assertion disclosure can be mitigated in the following two ways. Assertion is sent over TLS/SSL protected channel, where RP is authenticated by "client_id" and "client_secret". Signed Assertion is encrypted by the RP's public key.

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.

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.

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.

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.

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.

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.

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.

Timing attack can be used to reduce the effctive key length of the signature if the time required to return the response in case of signature error and correct signature exists. Care should be taken in the implementation to avoid this attack.

In the category of Authentication Process Threats, following threats exists. Online guessing Phishing Pharming Eavesdropping Replay Session hijack 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.

The following is the parameter registration request for the "scope" parameter as defined in this specification: Parameter name: openid Parameter usage location: The end-user authorization endpoint request, the end-user authorization endpoint response, the token endpoint request, the token endpoint response, and the "WWW-Authenticate" header field. Change controller: IETF Specification document(s): [[ this document ]] Related information: None

As a binding of OpenID Authentication, this specification heavily relies on OpenID Authentication 2.0. Please refer to Appendix C of OpenID Authentication 2.0 for the full list of the contributors for OpenID Authentication 2.0. In addition, the OpenID Community would like to thank the following people for the work they've done in the drafting and editing of this specification. Breno de Medeiros (breno@gmail.com) Hideki Nara (hideki.nara@gmail.com) John Bradley (jbradely@mac.com) <author> Nat Sakimura (n-sakimura@nri.co.jp) <author/editor> Ryo Itou (ritou@yahoo-corp.jp)