TOC 
DraftD. Hardt
 Sxip Identity
 November 29, 2006


OpenID Attribute Types - Draft 02

Abstract

This document describes how OpenID attribute properties are defined and created.



Table of Contents

1.  Overview
2.  Terminology
    2.1.  Definitions and Conventions
3.  Attribute Type Definition
    3.1.  Attribute Format Types
4.  Attribute Creation
    4.1.  New Attribute Process
    4.2.  New Attribute Data Format Process
    4.3.  Attribute Type Identifiers
5.  References
    5.1.  Normative References
    5.2.  Non-normative References
§  Author's Address




 TOC 

1.  Overview

OpenID ([OpenID.authentication‑2.0] (Recordon, D., Hoyt, J., and B. Fitzpatrick, “OpenID Authentication 2.0 - Draft 10,” October 2006.)) identity attributes are pieces of identity data that may be transferred using the OpenID Attribute Exchange extension ([OpenID.attribute‑exchange‑1.0] (Hardt, D., “OpenID Attribute Exchange,” November 2006.)). 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.



 TOC 

2.  Terminology



 TOC 

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.



 TOC 

3.  Attribute Type Definition

Attributes defined in the "schema.openid.net" name space are listed in the index document at http://schema.openid.net/. 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] (Hardt, D., “Identity Attribute Metadata,” November 2006.). 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.



 TOC 

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 http://schema.openid.net/types/. Type data is expressed in XML Schema format as specified in [identity‑attribute‑metadata‑1.0] (Hardt, D., “Identity Attribute Metadata,” November 2006.).



 TOC 

4.  Attribute Creation



 TOC 

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] (Hardt, D., “Identity Attribute Metadata,” November 2006.). 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.



 TOC 

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 sent to the list expressed in XML Schema ([W3C.REC‑xmlschema‑2‑20041028] (Biron, P. and A. Malhotra, “XML Schema Part 2: Datatypes Second Edition,” October 2004.)) format as outlined in [identity‑attribute‑metadata‑1.0] (Hardt, D., “Identity Attribute Metadata,” November 2006.). 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] (Hardt, D., “Identity Attribute Metadata,” November 2006.).
  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.



 TOC 

4.3.  Attribute Type Identifiers

Attribute type identifiers should be created with the following considerations:



 TOC 

5.  References



 TOC 

5.1. Normative References

[OpenID.attribute-exchange-1.0] Hardt, D., “OpenID Attribute Exchange,” November 2006 (TXT, HTML).
[OpenID.authentication-2.0] Recordon, D., Hoyt, J., and B. Fitzpatrick, “OpenID Authentication 2.0 - Draft 10,” October 2006 (TXT, HTML).
[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 (HTML).
[identity-attribute-metadata-1.0] Hardt, D., “Identity Attribute Metadata,” November 2006 (TXT, HTML).


 TOC 

5.2. Non-normative References

[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax,” RFC 2396, August 1998 (TXT, HTML, XML).


 TOC 

Author's Address

  Dick Hardt
  Sxip Identity
  798 Beatty Street
  Vancouver, BC V6B 2M1
  CA
Email:  dick@sxip.com
URI:  http://sxip.com/