Draft D. Hardt B. Ferg Sxip Identity August 10, 2006 OpenID Attribute Exchange 1.0 - Draft 1 Abstract OpenID Attribute Exchange is an OpenID service for exchanging identity information between endpoints. Messages for retrieval and storage of identity information are provided. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Definitions and Conventions . . . . . . . . . . . . . . . 2 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Fetch Message . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Fetch Request Format . . . . . . . . . . . . . . . . . . . 5 4.2. Fetch Response Format . . . . . . . . . . . . . . . . . . 5 5. Store Message . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Store Request Format . . . . . . . . . . . . . . . . . . . 7 5.2. Store Response Format . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Non-normative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Hardt & Ferg [Page 1] OpenID Attribute Exchange 1.0 August 2006 1. Terminology 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]. 1.1. Definitions and Conventions [NOTE: Update terminology based on final OpenID 2.0 draft.] User: (Or "End User".) A person with a digital identity who participates in OpenID based identity information exchanges using their client software, typically a web browser. Identity Data: A property of a digital identity in which the Property Name and Property Value are represented as a name-value pair. Persona: A user can have multiple personas as part of their identity. For example, a user might have a work persona and a home persona. A persona is a subset of the user's identity data. Identity Provider: Also called "IdP" or "Server". This is the OpenID Authentication server that a Consumer contacts for cryptographic proof that the End User owns the Claimed Identity. Consumer: A site that requests identity data from an Identity Provider via the user's client. For the purposes of this document, the extension namespace identifier for the attribute exchange service will be "ax". Hardt & Ferg [Page 2] OpenID Attribute Exchange 1.0 August 2006 2. Overview The attribute exchange service is identified by the URI "http://openid.net/srv/ax/1.0" [NOTE: subject to change in following drafts]. An attribute is a unit of personal identity information that is identified by a unique URI. It may refer to any kind of information; see [Prop_List] for some examples. This service defines two additional message types for transferring attributes: fetch (see Section 4) and store (see Section 5). Fetch retrieves attribute information from an Identity Provider, while store saves or updates attribute information on the Identity Provider. Both messages originate from the Consumer site or service provider and are passed to the Identity Provider via the user agent as per the OpenID protocol specification. The request parameters detailed here SHOULD be sent with OpenID Authentication checkid_immediate or checkid_setup requests. [NOTE: This portion of the spec will change depending on the final draft of OpenID 2.0.] Error responses are communicated using the standard OpenID methods; see [OpenID_Auth]. Hardt & Ferg [Page 3] OpenID Attribute Exchange 1.0 August 2006 3. Discovery Discovery of the attribute exchange service is achieved via the mechanism described in [OpenID_Auth]. The attribute exchange namespace "http://openid.net/srv/ax/1.0" SHOULD be listed as an child element of the element in the XRDS discovery document. Hardt & Ferg [Page 4] OpenID Attribute Exchange 1.0 August 2006 4. Fetch Message The fetch message is used to retrieve personal identity attributes from an Identity Provider. 4.1. Fetch Request Format All of the following request fields are OPTIONAL, though at least one of "openid.ax.required" or "openid.ax.if_available" MUST be specified in the request. Separate "required" or "if_available" directives must be used for each identifier name referred to. Any identifier name referred to in a "required" or "if_available" parameter MUST have an associated "openid.ax.fetch." parameter. openid.ax.fetch. Associates an identifier name with the attribute URI which is the value of this parameter. The name will be used as the lvalue in the fetch response message. openid.ax.required The value of this parameter is an identifier name corresponding to a URI defined in an "openid.ax.fetch.". The Identity Provider must provide the identity information specified in this parameter or return an error condition. openid.ax.if_available The value of this parameter is an identifier name corresponding to a URI defined in an "openid.ax.fetch.". The Identity Provider may provide the identity information specified in this parameter. Not including the information in the response does not constitute an error condition. This example requests the required full name information, and the optional favourite dog information. openid.ns.ax=http://openid.net/srv/ax/1.0 openid.ax.fetch.fname=http://example.com/schema/fullname openid.ax.fetch.fav_dog=http://example.com/schema/favourite_dog openid.ax.required=fname openid.ax.if_available=fav_dog 4.2. Fetch Response Format The fetch response message supplies the information requested in the fetch request in a format suitable for consumption by a standard HTML form processor. Each attribute is supplied with the assigned identifier name as the lvalue and the attribute value as the rvalue. Hardt & Ferg [Page 5] OpenID Attribute Exchange 1.0 August 2006 The response to the previous request example, in which the required full name information and the optional favourite dog information are both supplied. fname="John Smith" fav_dog="Spot" Hardt & Ferg [Page 6] OpenID Attribute Exchange 1.0 August 2006 5. Store Message The store message is used to store personal identity information to the Identity Provider. 5.1. Store Request Format All of the following request fields are OPTIONAL. Any identifier name referred to in a "value" parameter MUST have an associated "openid.ax.label." parameter. openid.ax.label. Associates an identifier name with the attribute URI which is the value of this parameter. The name will be used as a reference in an "openid.ax.value." parameter. openid.ax.value. Assigns a value to the identifier with the name assigned by a "label" parameter. openid.ns.ax=http://openid.net/srv/ax/1.0 openid.ax.label.fname=http://example.com/schema/fullname openid.ax.value.fname="Bob Smith" 5.2. Store Response Format The store response consists of an empty response message with the 200 HTTP response code as per the OpenID specification [OpenID_Auth]. Hardt & Ferg [Page 7] OpenID Attribute Exchange 1.0 August 2006 6. Security Considerations [NOTE: TBD] Hardt & Ferg [Page 8] OpenID Attribute Exchange 1.0 August 2006 7. References 7.1. Normative References [OpenID_Auth] Recordon, D., Hoyt, J., and B. Fitzpatrick, "OpenID Authentication 2.0", July 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. 7.2. Non-normative References [Prop_List] Hardt, D. and B. Ferg, "Attribute Properties for OpenID Attribute Exchange", August 2006. Hardt & Ferg [Page 9] OpenID Attribute Exchange 1.0 August 2006 Authors' Addresses Dick Hardt Sxip Identity 798 Beatty Street Vancouver, BC V6B 2M1 CA Email: dick@sxip.com URI: http://sxip.com/ Barry Ferg Sxip Identity 798 Beatty Street Vancouver, BC V6B 2M1 CA Email: barry@sxip.com URI: http://sxip.com/ Hardt & Ferg [Page 10]