OpenID Artifact Binding 1.0 - Draft01

Abstract

OpenID Authentication 2.0 defines the method to move Authentication and associated extension requests among the User, Relying Party, and the OpenID provider through HTTP POST or GET, i.e., it defines the POST and GET binding for OpenID messaging. This specification defines the Artifact Binding that sends the OpenID message directly from the Relying Party to the OpenID Provider and passes only a small reference data called Artifact through the browser so that large payload can be moved between the Relying Party and the OpenID Provider without hitting the browser URL and HTTP header size limitation.

Table of Contents

1.  Requirements Notation and Conventions
2.  Terminology
3.  Protocol Overview
4.  Data Formats
5.  Communication Types
6.  Generating Signatures
7.  Protocol
    7.1.  Initiation and Discovery
    7.2.  Establishing Associations
    7.3.  Direct Authencitaction Request
    7.4.  Direct Authentication Request Response
    7.5.  Artifact Authentication Request
    7.6.  Artifact Authentication Response
    7.7.  Direct Assertion Request
    7.8.  Direct Assertion Response
    7.9.  Verifying Assertions
8.  Extensions
9.  Discovering OpenID Relying Parties
10.  Security Considerations
Appendix A.  Acknowledgements
11.  Normative References
§  Author's Address

1.  Requirements Notation and Conventions

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

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.

2.  Terminology

In addition to the terminology used in [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.), following terms are used.

Artifact:

An Artifact is a small text associated with the larger payload that identifies the payload.

3.  Protocol Overview

1. The end user initiates authentication (Initiation and Discovery) by presenting a User-Supplied Identifier to the Relying Party via their User-Agent.
2. 1.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.
3. (optional) The Relying Party and the OP establish an association (Establishing Associations) -- a shared secret established using Diffie-Hellman Key Exchange (Rescorla, E., “Diffie-Hellman Key Agreement Method,” .) [RFC2631]. The OP uses an association to sign subsequent messages and the Relying Party to verify those messages; this removes the need for subsequent direct requests to verify the signature after each authentication request/response.
4. The Relying Party Sends the OpenID Authentication Request to the OP via direct communication and obtains an Artifact.
5. The Relying Party redirects the end user's User-Agent to the OP with an OpenID Artifact Authentication request (Artifact Authentication Request).
6. 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.
7. The OP redirects the end user's User-Agent back to the RP with Artifact Authentication Response.
8. The RP GETs the assertion from the OP through direct communication (Direct Assertion Request and Response.)
9. The Relying Party verifies (Verifying Assertions) 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:

4.  Data Formats

Data Format is the same as in [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.) section 4.

5.  Communication Types

Communication Types are the same as in [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.) section 5. In addition to those defined, the Artifact Binding uses Direct Communication for sendin and receiving authentication message.

6.  Generating Signatures

Signature Generation is the same as in [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.) section 6.

7.  Protocol

7.1.  Initiation and Discovery

Initiation and Discovery is the same as in [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.) section 7.

7.2.  Establishing Associations

It is the same as in [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.) section 8.

7.3.  Direct Authencitaction Request

Once the Relying Party has successfully performed discovery and (optionally) created an association with the discovered OP Endpoint URL, it can send an authentication request to the OP to obtain an assertion. When requesting authentication, the Relying Party MUST send the request in direct communication to the OP. Upon receipt of a valid request, OP MUST return a unique short string less than 400 characters called an Artifact to identify this request. The Artifact value must include the string constructed from a cryptographically strong random or pseudorandom number sequence [RFC1750] generated by the OP. The Artifact is subsequently used over an indirect request, the Artifact Authentication Request.

Parameters sent are as follows:

• openid.ns

  As specified in Section 4.1.2 of [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.).

• openid.mode

  Value: "checkid_immediate", "checkid_setup", "direct_checkid_immediate" or "direct_checkid_setup"

  Note: If the Relying Party wishes the end user to be able to interact with the OP, "checkid_setup" should be used. An example of a situation where interaction between the end user and the OP is not desired is when the authentication request is happening asynchronously in JavaScript.

• 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 (Extensions).

  It is RECOMMENDED that OPs accept XRI identifiers with or without the "xri://" prefix, as specified in the Normalization (Initiation and Discovery) section.

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

  Value: (optional) A handle for an association between the Relying Party and the OP that SHOULD be used to sign the response.

  Note: If no association handle is sent, the transaction will take place in Stateless Mode.

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

  Value: (optional) URL pattern the OP SHOULD ask the end user to trust. See "Realms" in OpenID Authentication 2.0. This value MUST be sent if openid.return_to is omitted.

  Default: return_to URL

• openid.signed

  Value: Comma-separated list of signed fields.

  Note: This entry consists of the fields without the "openid." prefix that the signature covers. This list MUST contain at least "op_endpoint", "return_to" "response_nonce" and "assoc_handle", and if present in the response, "claimed_id" and "identity". Additional keys MAY be signed as part of the message. See Generating Signatures (Generating Signatures).

  For example, "op_endpoint,identity,claimed_id,return_to,assoc_handle,response_nonce".

• openid.sig

  Value: Base 64 encoded signature calculated as specified in Section 6 (Generating Signatures).

7.4.  Direct Authentication Request Response

When Direct Authentication Request is received successfully, the OP performs request validation. Request validation includes Return URL Verification as in [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.) section 9.2 as well as the signature validation.

If the request is valid, the OP returns the following fields in the HTTP response body.

• openid.ns

  As specified in Section 4.1.2 of [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.).

• openid.mode

  Value: direct_checkid_accepted

• openid.artifact

  Value: A unique short string less than 400 characters. This value includes a string that is constructed from a cryptographically strong random or pseudorandom number sequence [RFC1750] generated by the OP. The Artifact may be used over an indirect request, the Artifact Authentication Request, subsequently.

• openid.signed

  Value: Comma-separated list of signed fields.

  Note: This entry consists of the fields without the "openid." prefix that the signature covers. This list MUST contain at least "op_endpoint", "return_to" "response_nonce" and "assoc_handle", and if present in the response, "claimed_id" and "identity". Additional keys MAY be signed as part of the message. See Generating Signatures (Generating Signatures).

  For example, "op_endpoint,identity,claimed_id,return_to,assoc_handle,response_nonce".

• openid.sig

  Value: Base 64 encoded signature calculated as specified in Section 6 (Generating Signatures).

7.5.  Artifact Authentication Request

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.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.).

• openid.mode

  Value: art_req

• openid.artifact

  Value: The Artifact value returned by OP on Section 7.4 (Direct Authentication Request Response).

7.6.  Artifact Authentication Response

Upon receipt of the Artifact Authentication Request, the OP MUST determine that an authorized end user wishes to complete the authentication in the manner described in Section 10 of the [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.). 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.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.).

• openid.mode

  Value: "art_res"

• openid.artifact

  Value: The Artifact value corresponding to the Assertion created. It may or may not be the same as the value in the request. If the Artifact was not found at the OP, it MUST be a string "INVALID".

No other parameter should be returned.

7.7.  Direct Assertion Request

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.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.).

• openid.mode

  Value: "direct_assertion_req"

• openid.artifact

  Value: The Artifact value received in the Section 7.6 (Artifact Authentication Response) Artifact Authentication Response.

• openid.signed

  Value: Comma-separated list of fields in this request.

• openid.sig

  Value: Base 64 encoded signature calculated as specified in Section 6 of [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.).

On receipt of such request, the OP should return the assertion created previously as the payload of the response to this request.

7.8.  Direct Assertion Response

Upon receipt of the Direct Assertion Request, OP MUST return either Positive or Negative Assertion as defined in [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.) in the HTTP/S response body.

7.9.  Verifying Assertions

Assertion verification is done as in Section 11 of [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.).

8.  Extensions

Extensions are as defined in Section 12 of [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.). In addition, this specification adds “artifact” in the disallowed aliases.

9.  Discovering OpenID Relying Parties

Relying Party Discovery is as in Section 13 of [OpenID.authentication‑2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.).

10.  Security Considerations

Appendix A.  Acknowledgements

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. If you want to know the nitty gritty of who actually wrote what, feel free to look at our BitBucket repository.

Breno de Madiros (breno@gmail.com)

Hideki Nara (hideki.nara@gmail.com)

Nat Sakimura (sakimura@gmail.com) <author/editor>

11. Normative References

Author's Address