Draft D. Hardt Sxip Identity November 29, 2006 OpenID Attribute Types - Draft 02 Hardt [Page 1] Attribute Properties November 2006 Abstract This document describes how OpenID attribute properties are defined and created. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Definitions and Conventions . . . . . . . . . . . . . . . 4 3. Attribute Type Definition . . . . . . . . . . . . . . . . . . 5 3.1. Attribute Format Types . . . . . . . . . . . . . . . . . . 5 4. Attribute Creation . . . . . . . . . . . . . . . . . . . . . . 6 4.1. New Attribute Process . . . . . . . . . . . . . . . . . . 6 4.2. New Attribute Data Format Process . . . . . . . . . . . . 6 4.3. Attribute Type Identifiers . . . . . . . . . . . . . . . . 7 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Normative References . . . . . . . . . . . . . . . . . . . 9 5.2. Non-normative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Hardt [Page 2] Attribute Properties November 2006 1. Overview OpenID ([OpenID.authentication-2.0]) identity attributes are pieces of identity data that may be transferred using the OpenID Attribute Exchange extension ([OpenID.attribute-exchange-1.0]). They are uniquely identified by a URI, and have associated meta-data describing them. As attributes are continually being added, this document does not attempt to enumerate them. Rather, the process for definition and creation of the attributes is listed. Only attributes in the "schema.openid.net" name space are pertinent to this discussion; there are no restrictions on the definition and creation of attributes in other name spaces. Hardt [Page 3] Attribute Properties November 2006 2. Terminology 2.1. Definitions and Conventions Identity Attribute Type Identity attribute types (also referred to as simply "attribute types") are types of subject properties expressed in an identity context. Examples are "surname" or "birth date". Identity Attribute Format Type The identity attribute format type ("format type") refers to the layout of the data in the value of an identity attribute type. They may be as simple as a normalized string or as complicated as a telephone number format. Hardt [Page 4] Attribute Properties November 2006 3. Attribute Type Definition Attributes defined in the "schema.openid.net" name space are listed in the index document at . Each attribute is also defined by resolving its attribute type identifier URI. The format for the meta-data in the definition document is outlined in [identity-attribute-metadata-1.0]. The meta-data at "schema.openid.net" is recorded in XML but may be expressed in a human readable format using XSLT. The meta-data recorded includes the format of the type's value and a localized label and description. Optional data including examples, cross references and acquisition and authority information may also be recorded. 3.1. Attribute Format Types Base types for the format of the identity data values are also stored in the schema.openid.net name space. The type index is located at . Type data is expressed in XML Schema format as specified in [identity-attribute-metadata-1.0]. Hardt [Page 5] Attribute Properties November 2006 4. Attribute Creation 4.1. New Attribute Process New OpenID identity data attribute types may be proposed by any interested parties; this section outlines the process involved in doing so. Note that this process only applies to identity types in the "schema.openid.net" name space. Anyone is free to implement attribute types in other name spaces. 1. The first step in proposing a new identity attribute type is to search the list of existing types for similar attributes. Duplication of attribute types should be avoided. 2. Post an "intent to define" message to the mailing list at schema@openid.net. The email should describe the proposed type in general terms. Posting this to the list will reduce duplicated effort in the case of multiple parties defining similar types. Intent posts will also generate discussion that may be used to determine if it is worthwhile to pursue the proposal. 3. The attribute type should be completely described both in regular prose and in the meta-data format defined in [identity-attribute-metadata-1.0]. Tools to help create and validate the meta-data will likely evolve. 4. Post a "proposed attribute" message to the mailing list at "schema@openid.net", including the attribute type identifier, motivation, description and meta-data. An administrator will post the attribute type meta-data to the experimental "http://openid.net/x/" area. 5. Discussions on the list will dictate whether or not the proposal passes. If the consensus is that the proposed attribute type is worth pursuing, the type will be moved into the non-experimental name space and the "schema@openid.net" list notified. The approval stage of the process is deliberately vague; the idea being that a more detailed process will emerge as more interested parties take part. In any case, approval should be the default action if there is no vocal disapproval and the proposed type is not a duplicate of an existing type. 4.2. New Attribute Data Format Process New attribute data format types are proposed and approved in a similar manner to attribute types themselves. The proposed type is Hardt [Page 6] Attribute Properties November 2006 sent to the list expressed in XML Schema ([W3C.REC-xmlschema-2-20041028]) format as outlined in [identity-attribute-metadata-1.0]. Often format type proposals will accompany an attribute type proposal; in this case it is acceptable to combine the two proposals. 1. The first step in proposing a new attribute format type is to search the list of existing types for similar types. Duplication of format types should be avoided. 2. Post an "intent to define" message to the mailing list at schema@openid.net. The email should describe the proposed type in general terms. Posting this to the list will reduce duplicated effort in the case of multiple parties defining similar types. Intent posts will also generate discussion that may be used to determine if it is worthwhile to pursue the proposal. 3. The format type should be completely described both in regular prose and in the meta-data format defined in [identity-attribute-metadata-1.0]. 4. Post a "proposed format type" message to the mailing list at "schema@openid.net", including the motivation, description and meta-data. An administrator will post the attribute type meta- data to the experimental "http://openid.net/type/x/" area. 5. Discussions on the list will dictate whether or not the proposal passes. If the consensus is that the proposed format type is worth pursuing, the type will be moved into the non-experimental name space and the "schema@openid.net" list notified. 4.3. Attribute Type Identifiers Attribute type identifiers should be created with the following considerations: o Attribute type identifiers MUST conform to the generic URI syntax described in [RFC2396]. o The OpenID authority portion of the URI is "schema.openid.net". o Each URI resolves to an RDF representation of the type's meta-data as defined in [identity-attribute-metadata-1.0]. o URIs should, where possible, re-use existing paths in the schema.openid.net namespace. Hardt [Page 7] Attribute Properties November 2006 o The URI path should be kept as short as possible. o URI fragment specifiers should not be used. Hardt [Page 8] Attribute Properties November 2006 5. References 5.1. Normative References [OpenID.attribute-exchange-1.0] Hardt, D., "OpenID Attribute Exchange", November 2006. [OpenID.authentication-2.0] Recordon, D., Hoyt, J., and B. Fitzpatrick, "OpenID Authentication 2.0 - Draft 10", October 2006. [W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, . [identity-attribute-metadata-1.0] Hardt, D., "Identity Attribute Metadata", November 2006. 5.2. Non-normative References [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Hardt [Page 9] Attribute Properties November 2006 Author's Address Dick Hardt Sxip Identity 798 Beatty Street Vancouver, BC V6B 2M1 CA Email: dick@sxip.com URI: http://sxip.com/ Hardt [Page 10]