Draft D. Hardt J. Bufu Sxip Identity January 9, 2007 OpenID Attribute Exchange 1.0 - Draft 04 Abstract OpenID Attribute Exchange is an OpenID service extension for exchanging identity information between endpoints. Messages for retrieval and storage of identity information are provided. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . ancho 1.1. Definitions and Conventions . . . . . . . . . . . . . . ancho 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . ancho 3. Information Model . . . . . . . . . . . . . . . . . . . . . ancho 3.1. Subject Identifier . . . . . . . . . . . . . . . . . . ident 3.2. Attribute Type Identifier . . . . . . . . . . . . . . . attri 3.3. Attribute Value . . . . . . . . . . . . . . . . . . . . attri 4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . ancho 5. Fetch Message . . . . . . . . . . . . . . . . . . . . . . . fetch 5.1. Fetch Request Format . . . . . . . . . . . . . . . . . fetch 5.2. Fetch Response Format . . . . . . . . . . . . . . . . . ancho 6. Store Message . . . . . . . . . . . . . . . . . . . . . . . store 6.1. Store Request Format . . . . . . . . . . . . . . . . . ancho 6.2. Store Response Format . . . . . . . . . . . . . . . . . ancho 6.2.1. Storage Success . . . . . . . . . . . . . . . . . . ancho 6.2.2. Storage Failure . . . . . . . . . . . . . . . . . . ancho 7. Security Considerations . . . . . . . . . . . . . . . . . . ancho 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . ancho 9. References . . . . . . . . . . . . . . . . . . . . . . . . ancho 9.1. Normative References . . . . . . . . . . . . . . . . . ancho 9.2. Non-normative References . . . . . . . . . . . . . . . ancho Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 0 Hardt & Bufu [Page 1] OpenID Attribute Exchange 1.0 - Draft 04 January 2007 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 User: Also referred to as "End User" or "Subject". 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. Attribute The base of the information model used to describe the Identity Data, for the purpose of exchanging it. Persona: A subset of the user's identity data. A user can have multiple personas as part of their identity. For example, a user might have a work persona and a home persona. OpenID Provider: Also called "OP" or "Server". An OpenID Authentication server on which a Relying Party relies for an assertion that the end user controls an Identifier. Relying Party: Also called "RP" or "Consumer". A Web application that wants proof that the end user controls an Identifier, and requests identity data associated with the end user. For the purposes of this document, the extension namespace identifier for the attribute exchange service will be "ax". Hardt & Bufu [Page 2] OpenID Attribute Exchange 1.0 - Draft 04 January 2007 2. Overview The attribute exchange service extension is identified by the URI "http://openid.net/srv/ax/1.0" [NOTE: subject to change in following drafts]. This URI MUST be specified in the extension namespace declaration. 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 [OpenID.attribute-types-1.0] for some examples. This service extension defines two message types for transferring attributes: fetch (see Section 5) and store (see Section 6). Fetch retrieves attribute information from an OpenID Provider, while store saves or updates attribute information on the OpenID Provider. Both messages originate from the Relying Party and are passed to the OpenID Provider via the user agent as per the OpenID Authentication protocol specification. The request parameters detailed here MUST be sent using the [OpenID.authentication-2.0] extension mechanism. Error responses are communicated using the standard OpenID methods. Hardt & Bufu [Page 3] OpenID Attribute Exchange 1.0 - Draft 04 January 2007 3. Information Model The OpenID Attribute Exchange service extension provides a mechanism for moving identity information between sites, as such its information model is simple: An attribute is associated with a Subject Identifier An attribute has a type identifier and a value An attribute type identifier is a URI An attribute value is a UTF-8 string [RFC3629] 3.1. Subject Identifier An identifier for a set of attributes. It MUST be a URI. The subject identifier corresponds to the end-user identifier in the authentication portion of the messages. In other words, the subject of the identity attributes in the attribute exchange part of the message is the same as the end-user in the authentication part. The subject identifier is not included in the attribute exchange. 3.2. Attribute Type Identifier An attribute type identifier MUST be a URI, which is used for referring to property values. If an attribute type identifier URI can be resolved then it MAY be dereferenced to retrieve a description of the property. This provides for flexibility and extensibility. Flexibility in that both URNs and URLs can be used to refer to property values. Extensibility allows any individual site, or consortium of sites, to define their own attribute types with agreements on the syntax and semantics of their associated attribute values. The proposed process for defining new attribute types is specified in [OpenID.attribute-types-1.0], and the attribute metadata schema and data formats are described in [OpenID.attribute-metadata-1.0]. Details about the location of these documents, as well as the OpenID attribute type URI namespace have not been finalized yet, and are currently being discussed with the community. 3.3. Attribute Value A attribute value MUST be a UTF-8 string and may optionally be empty. Hardt & Bufu [Page 4] OpenID Attribute Exchange 1.0 - Draft 04 January 2007 4. Discovery Discovery of the attribute exchange service extension is achieved via the mechanism described in [OpenID.authentication-2.0]. 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 & Bufu [Page 5] OpenID Attribute Exchange 1.0 - Draft 04 January 2007 5. Fetch Message The fetch message is used to retrieve personal identity attributes from an OpenID Provider. 5.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, and any attribute alias present in a "openid.ax.required" or "openid.ax.if_available" parameter MUST have an associated "openid.ax.type." parameter. Multiple attribute aliases in the "openid.ax.required" and "openid.ax.if_available" directives are separated with a comma, ",". Attribute aliases MUST NOT contain newline and colon characters, as specified in the Data Formats / Protocol Messages section of [OpenID.authentication-2.0]; they also MUST NOT contain commas. openid.ax.type. The value of this parameter specifies the type identifier URI of a requested attribute. The will further be used to identify the attribute being exchanged. openid.ax.required The value of this parameter is an attribute alias, or a list of aliases corresponding to the URIs defined by "openid.ax.type." parameters. The OpenID Provider MUST provide the identity information specified in this parameter or return an error condition. Multiple attribute aliases are separated with a comma, ",". openid.ax.if_available The value of this parameter is an attribute alias, or a list of aliases corresponding to the URIs defined by "openid.ax.type." parameters. The OpenID Provider MAY provide the identity information specified in this parameter. Not including the information in the response does not constitute an error condition. Multiple attribute aliases are separated with a comma, ",". openid.ax.count. OPTIONAL. The number of values for the specified attribute alias the Relying Party wishes to receive from the OpenID Provider. If present, the value MUST be greater than zero. If absent, exactly one value is requested. OpenID Providers MUST NOT return more than the number of requested values. Hardt & Bufu [Page 6] OpenID Attribute Exchange 1.0 - Draft 04 January 2007 openid.ax.update_url If this URL is specified, the OpenID Provider may re-post the fetch response data to it at some time after the initial response has been sent. This "unsolicited" response message would be generated in response to an attribute information update, and would contain the updated data. The relying party may include transaction data encoded in the URL such that it contains enough information to match the attribute information to the identity subject. Additional information may be encoded in the URL by the relying party as necessary. If the OpenID Provider supports this feature it MUST return the parameter as part of the fetch response message. If it does not support this feature it may legally ignore this parameter. This example requests the required full name and gender information, and the optional favourite dog and movie information. The Relying Party is interested in up to three favorite movies associated with the subject identifier. openid.ns.ax=http://openid.net/srv/ax/1.0 openid.ax.type.fname=http://example.com/schema/fullname openid.ax.type.gender=http://example.com/schema/gender openid.ax.type.fav_dog=http://example.com/schema/favourite_dog openid.ax.type.fav_movie=http://example.com/schema/favourite_movie openid.ax.count.fav_movie=3 openid.ax.required=fname,gender openid.ax.if_available=fav_dog,fav_movie openid.ax.update_url=http://idconsumer.com/update?transaction_id=a6b5c41