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.

The end user initiates authentication by presenting a User-Supplied Identifier to the Relying Party via their User-Agent. After normalizing the User-Supplied Identifier, the Relying Party performs discovery on it and establishes the OP Endpoint URL that the end user uses for authentication. It should be noted that the User-Supplied Identifier may be an OP Identifier, as discussed in Section 7.3.1 of OpenID Authentication 2.0, which allows selection of a Claimed Identifier at the OP or for the protocol to proceed without a Claimed Identifier if something else useful is being done via an?extension. The Relying Party Sends the OpenID Authentication Request to the OP via direct communication and obtains an Artifact, or creates request parameter file and assignes a URL for it so that it can send it in the next step. The Relying Party redirects the end user's User-Agent to the OP with an OpenID Artifact Authentication request . 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 Artifact Authentication Response. The RP GETs the assertion from the OP through direct communication (Direct Assertion Request and Response.) The Relying Party verifies the information received from the OP including checking the Return URL, verifying the discovered information, checking the nonce, and verifying the signature by using either the shared key established during the association or by sending a direct request to the OP. A Typical sequence can be depicted as follows:

UA: Click Login UA->RP: Login with identifier RP->RP: Normalize identifier RP->OP: Get XRDS RP->RP: Find Service RP->OP: Direct AuthN Req OP->OP: Create Artifact OP->OP: Store Request OP-->RP: Artifact RP-->UA: Artifact Authentication Request UA->OP: Artifact Authentication Request opt If not immediate OP-->UA: Credential Input Screen User->UA: Input Credential UA->OP: POST credential OP->OP: Check credential end OP->OP: Store Assertion OP-->UA: Artifact Authentication Response UA->RP: Artifact Authentication Response RP->OP: Direct Assertion Request OP-->RP: Direct Assertion Response RP->RP: Verify Assertion RP-->UA: Session ]]> artwork>

Data Format is the same as in section 4.

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

Artifact Binding does not use symetric signature. To achieve higher level assurance levels, one MAY use asymetric signature which is described later. To generate a message signature: Determine the list of keys to be signed, according to the message to be signed (See Section 10.1). The list of keys to be signed MUST be part of the message. The list is stored with the key "openid.signed". The value is a comma-separated list of keys, with the "openid." prefix stripped. This algorithm is only capable of signing keys that start with "openid." Iterate through the list of keys to be signed in the order they appear in "openid.signed" list. For each key, find the value in the message whose key is equal to the signed list key prefixed with "openid." Convert the list of key/value pairs to be signed to an octet string by encoding with Key-Value Form Encoding as specified in 4.1.1 of Apply the signature algorithm specified in the request to the octet string.

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.

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 starts with http:// or https:// do nothing. If there is no user supplied identifier, assume http://openid.net/spec/identifier_select.

Discovery is the process where the Relying Party uses the Identifier to look up ("discover") the necessary information for initiating requests. For the resulting URL, Yadis protocol SHALL be first attempted. If it succeeds, the result is an XRDS document from which one should discover the following elements: If the Yadis protocol fails and no valid XRDS document is retrieved, or no Service Elements are found in the XRDS document, the URL is retrieved and HTML-Based discovery SHALL be attempted.

Via the Direct Authentication Request, the authentication request together with other extensions request such as AX and PAPE requests are sent to the OP Endpoint URL that was discovered previously. Direct Request is always over the SSL connection. No signature is required, but return_to is required and must match what is being advertised in the RP's XRDS. Also, the XRDS MUST contain CanonicalID (Subject in XRD), and this must be included in the request. Conceptually, here are two modes: "push" OR "pull". "Push" is an HTTP POST to the endpoint URL with all the parameter while "Pull" is the mode where only the URL of the "request parameter file" that includes all the "Push" parameters are handed to the OP in the "Artifact Authentication Request". "Push" Parameters sent are as follows: openid.ns Value: "http://specs.openid.net/auth/2.0" openid.mode Value: "direct_checkid_immediate" or "direct_checkid_setup" openid.claimed_id Value: (optional) The Claimed Identifier. "openid.claimed_id" and "openid.identity" SHALL be either both present or both absent. If neither value is present, the assertion is not about an identifier, and will contain other information in its payload, using extensions . openid.identity Value: (optional) The OP-Local Identifier. If a different OP-Local Identifier is not specified, the claimed identifier MUST be used as the value for openid.identity. Note: If this is set to the special value "http://specs.openid.net/auth/2.0/identifier_select" then the OP SHOULD choose an Identifier that belongs to the end user. This parameter MAY be omitted if the request is not about an identifier (for instance if an extension is in use that makes the request meaningful without it; see openid.claimed_id above). openid.return_to Value: (optional) URL to which the OP SHOULD return the User-Agent with the response indicating the status of the request. Note: 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. Note: The return_to URL MAY be used as a mechanism for the Relying Party to attach context about the authentication request to the authentication response. This document does not define a mechanism by which the RP can ensure that query parameters are not modified by outside parties; such a mechanism can be defined by the RP itself. openid.enckey Value: (optional) Base64 public key certificate for encryption. openid.sigalg Value: (optional) "http://www.w3.org/2000/09/xmldsig#rsa-sha1" or "none". openid.proofkey Value: (optional) X.509 public key certificate of the user being authenticated. Request Parameter File (rpf) is created by capturing all the above parameters into UTF-8 JSON format file, e.g.,

When Direct Authentication Request is received successfully, the OP performs request validation. Request validation includes Return URL Verification as in section 9.2. If the request is valid, the OP returns the following fields in the HTTP response body. openid.ns Value: "http://specs.openid.net/auth/2.0" openid.mode Value: direct_checkid_accepted openid.artifact Value: A unique short string less than 400 characters. The Artifact may be used over a redirect request, the Artifact Authentication Request, subsequently.

Upon receipt of the Artifact, RP should send the Artifact Authentication Request to the OP. Fields are as follows: openid.ns As specified in Section 4.1.2 of . openid.mode Value: art_req openid.artifact Value: (Optional) The Artifact value returned by OP on . Only either the openid.artifact or openid.ppfurl should be present in a request. openid.rpfurl Value: (Optional) URL of the request parameter file. Optionally, one can put the SHA256 hash of the file after "#". Only either the openid.artifact or openid.ppfurl should be present in a request.

Upon receipt of the Artifact Authentication Request, the OP determines if it should retrive the request parameter based on artifact or rpfurl. If it is to be based on the artifact, the OP retrieves it in the manner OP implemented it. If it were to be retrieved from rpfurl, then the OP MUST send a GET request to the rpfurl to retrieve the content 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 as follows: openid.ns As specified in Section 4.1.2 of . openid.mode Value: "art_res" openid.artifact Value: The Artifact value corresponding to the Assertion is created. The Artifact value must include the string constructed from a cryptographically strong random or pseudorandom number sequence [RFC1750] generated by the OP. If the Request Artifact was not found at the OP, it MUST be a string "INVALID". No other parameter should be returned.

If valid openid.artifact was returned, the RP SHOULD request the OP in direct communication with the following parameters: openid.ns As specified in Section 4.1.2 of . openid.mode Value: "direct_assertion_req" openid.artifact Value: The Artifact value received in the Artifact Authentication Response. On receipt of such request, the OP should return the assertion created previously as the payload of the response to this request.

Upon receipt of the Direct Assertion Request, OP MUST return either Positive or Negative Assertion as defined in in the HTTP/S response body with the exception of openid.invalidate_handle, openid.assoc_handle, openid.signed, openid.sig, which are unnecessary. When asymmetric signature is used, then the assertion must be Base64ed without line break, and signature should be applied as in SAML Simple Sign. Variables returned in response are as follows: openid.response Value: Base64 converted OpenID assertion. openid.sig Value: Base64 converted version of the value yielded by feeding the raw string before Base64 of the openid.response .

Assertion verification is done as in Section 11.1 to 11.3 of . In addition, if signature is used, the following signature verification must be performed.

Signature verification is performed in the following steps. Base 64 decode the openid.response. Calculate the signature over it and compaire it with openid.sig.

Extensions are as defined in Section 12 of . In addition, this specification adds “artifact” in the disallowed aliases.

Relying Party Discovery is as in Section 13 of . Note that since signature is not used in some cases, RP supporting Artifact Binding MUST support this feature. Non-normative example:

http://rp.example.com/#134592834fjs02 http://specs.openid.net/auth/2.0/return_to http://consumer.example.com/return ]]>

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

To be completed.

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

To be completed.

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 Madiros (breno@gmail.com) Hideki Nara (hideki.nara@gmail.com) John Bradley (jbradely@mac.com) Nat Sakimura (sakimura@gmail.com) <author/editor>