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
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.
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.
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.
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.).
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.
-
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.
-
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.
-
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.
-
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.
-
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 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.
-
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.
-
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.
-
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.).
-
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.
-
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:
-
Attribute type identifiers MUST conform to the generic URI
syntax described in [RFC2396] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax,” August 1998.).
-
The OpenID authority portion of the URI is schema.openid.net.
-
Each URI resolves to an RDF representation of the type's
meta-data as defined in [identity‑attribute‑metadata‑1.0] (Hardt, D., “Identity Attribute Metadata,” November 2006.).
-
URIs should, where possible, re-use existing paths in the
schema.openid.net namespace.
-
The URI path should be kept as short as possible.
-
URI fragment specifiers should not be used.
5.
References
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). |
5.2. Non-normative References
Author's Address