<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Draft: OpenID Attribute Exchange 1.0 - Draft 03</title>
<meta http-equiv="Expires" content="Fri, 24 Nov 2006 17:50:57 +0000">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Attribute Exchange 1.0 - Draft 03">
<meta name="generator" content="xml2rfc v1.31 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.full td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Draft</td><td class="header">D. Hardt</td></tr>
<tr><td class="header"> </td><td class="header">Sxip Identity</td></tr>
<tr><td class="header"> </td><td class="header">November 24, 2006</td></tr>
</table></td></tr></table>
<h1><br />OpenID Attribute Exchange 1.0 - Draft 03</h1>
<h3>Abstract</h3>
<p>
OpenID Attribute Exchange is an OpenID service for exchanging
identity information between endpoints. Messages for
retrieval and storage of identity information are provided.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
Terminology<br />
<a href="#anchor2">1.1.</a>
Definitions and Conventions<br />
<a href="#anchor3">2.</a>
Overview<br />
<a href="#anchor4">3.</a>
Information Model<br />
<a href="#identifier-definition">3.1.</a>
Subject Identifier<br />
<a href="#attribute-name-definition">3.2.</a>
Attribute Type Identifier<br />
<a href="#attribute-value-definition">3.3.</a>
Attribute Value<br />
<a href="#anchor5">4.</a>
Discovery<br />
<a href="#fetch">5.</a>
Fetch Message<br />
<a href="#fetch_request">5.1.</a>
Fetch Request Format<br />
<a href="#anchor6">5.2.</a>
Fetch Response Format<br />
<a href="#store">6.</a>
Store Message<br />
<a href="#anchor7">6.1.</a>
Store Request Format<br />
<a href="#anchor8">6.2.</a>
Store Response Format<br />
<a href="#anchor9">6.2.1.</a>
Storage Success<br />
<a href="#anchor10">6.2.2.</a>
Storage Failure<br />
<a href="#anchor11">7.</a>
Security Considerations<br />
<a href="#anchor12">8.</a>
Acknowledgements<br />
<a href="#rfc.references1">9.</a>
References<br />
<a href="#rfc.references1">9.1.</a>
Normative References<br />
<a href="#rfc.references2">9.2.</a>
Non-normative References<br />
<a href="#rfc.authors">§</a>
Author's Address<br />
</p>
<br clear="all" />
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
Terminology</h3>
<p>
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 <a class='info' href='#RFC2119'>[RFC2119]<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a>.
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.1"></a><h3>1.1.
Definitions and Conventions</h3>
<p>
[NOTE: Update terminology based on final OpenID 2.0 draft.]
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>User:</dt>
<dd>
(AKA "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.
</dd>
<dt>Identity Data:</dt>
<dd>
A property of a digital identity in which the Property
Name and Property Value are represented as a name-value
pair.
</dd>
<dt>Persona:</dt>
<dd>
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.
</dd>
<dt>Identity Provider:</dt>
<dd>
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.
</dd>
<dt>Consumer:</dt>
<dd>
A site that requests identity data from an Identity
Provider via the user's client.
</dd>
</dl></blockquote><p>
</p>
<p>
For the purposes of this document, the extension namespace
identifier for the attribute exchange service will be
"ax".
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
Overview</h3>
<p>
The attribute exchange service 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.
</p>
<p>
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 <a class='info' href='#OpenID.attribute-types-1.0'>[OpenID.attribute‑types‑1.0]<span> (</span><span class='info'>Hardt, D., “OpenID Attribute Types - Draft 02,” November 2006.</span><span>)</span></a> for some examples.
</p>
<p>
This service defines two additional message types for
transferring attributes: fetch (see <a class='info' href='#fetch'>Section 5<span> (</span><span class='info'>Fetch Message</span><span>)</span></a>)
and store (see <a class='info' href='#store'>Section 6<span> (</span><span class='info'>Store Message</span><span>)</span></a>). 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.
</p>
<p>
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.]
</p>
<p>
Error responses are communicated using the standard OpenID
methods; see <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>Recordon, D., Hoyt, J., Fitzpatrick, B., and D. Hardt, “OpenID Authentication 2.0 - Draft 10,” August 2006.</span><span>)</span></a>.
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
Information Model</h3>
<p>
The OpenID attribute exchange service provides a mechanism for
moving identity information between sites, as such its
information model is simple:
</p>
<blockquote class="text">
<p>An attribute is associated with a Subject Identifier
</p>
<p>An attribute has a type identfier and a value
</p>
<p>An attribute type identifier is a URI
</p>
<p>An attribute value is a UTF-8 string <a class='info' href='#RFC3629'>[RFC3629]<span> (</span><span class='info'>Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.</span><span>)</span></a>
</p>
</blockquote><p>
</p>
<a name="identifier-definition"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.1"></a><h3>3.1.
Subject Identifier</h3>
<p>
An identifier for a set of attributes. 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.
</p>
<a name="attribute-name-definition"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2"></a><h3>3.2.
Attribute Type Identifier</h3>
<p>
An attribute type identifier MUST be a URI, which is used
for referring to property values.
</p>
<p>
If an attribute type identifier URI can be resolved then it
MAY be dereferenced to retrieve a description of the
property.
</p>
<p>
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 process for defining new
attribute types is defined in <a class='info' href='#OpenID.attribute-types-1.0'>[OpenID.attribute‑types‑1.0]<span> (</span><span class='info'>Hardt, D., “OpenID Attribute Types - Draft 02,” November 2006.</span><span>)</span></a>.
</p>
<a name="attribute-value-definition"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.3"></a><h3>3.3.
Attribute Value</h3>
<p>
A attribute value MUST be a UTF-8 string and may optionally
have no value.
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
Discovery</h3>
<p>
Discovery of the attribute exchange service is achieved via
the mechanism described in <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>Recordon, D., Hoyt, J., Fitzpatrick, B., and D. Hardt, “OpenID Authentication 2.0 - Draft 10,” August 2006.</span><span>)</span></a>. The attribute exchange
namespace "http://openid.net/srv/ax/1.0" SHOULD be listed as an <xrd:Type>
child element of the <xrd:Service> element in the XRDS
discovery document.
</p>
<a name="fetch"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.
Fetch Message</h3>
<p>
The fetch message is used to retrieve personal identity
attributes from an Identity Provider.
</p>
<a name="fetch_request"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1"></a><h3>5.1.
Fetch Request Format</h3>
<p>
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.
</p>
<p>
Multiple aliases in the "required" or "if_available"
directives are separated with a comma, ",". Any alias
referred to in a "required" or "if_available" parameter MUST
have an associated "openid.ax.fetch.<alias>"
parameter.
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>openid.ax.fetch.<alias></dt>
<dd>
Associates an alias with the attribute type identifier
which is the value of this parameter. The name will be
used as part of the lvalue in the fetch response
message.
</dd>
<dt>openid.ax.required</dt>
<dd>
The value of this parameter is an alias corresponding to
a URI defined in an "openid.ax.fetch.<alias>".
The Identity Provider must provide the identity
information specified in this parameter or return an
error condition. Multiple aliases are separated with a
comma, ",".
</dd>
<dt>openid.ax.if_available</dt>
<dd>
The value of this parameter is an alias corresponding to
a URI defined in an "openid.ax.fetch.<alias>".
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. Multiple aliases are separated with a
comma, ",".
</dd>
<dt>openid.ax.update_url</dt>
<dd>
If this URL is specified, the Identity 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 Identity 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.
</dd>
</dl></blockquote><p>
</p>
<p>
This example requests the required full name and gender
information, and the optional favourite dog information.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.fetch.fname=http://example.com/schema/fullname
openid.ax.fetch.gender=http://example.com/schema/gender
openid.ax.fetch.fav_dog=http://example.com/schema/favourite_dog
openid.ax.required=fname,gender
openid.ax.if_available=fav_dog
openid.ax.update_url=http://idconsumer.com/update?transaction_id=a6b5c41
</pre></div>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2"></a><h3>5.2.
Fetch Response Format</h3>
<p>
The fetch response message supplies the information
requested in the fetch request. Each attribute is supplied
with the assigned alias prefixed by "openid.ax.value" as the
lvalue and the attribute value as the rvalue. Attribute
types are also returned in the "type" parameter.
</p>
<p>
All requested values are returned back. If the value was not
supplied or available from the user, it will be returned as
an empty value. This enables the RP to know that the IdP
did process the request.
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>openid.ax.type.<alias></dt>
<dd>
Associates an alias with the attribute type identifier
which is the value of this parameter. The name will be
used as a reference in an
"openid.ax.value.<alias>" parameter.
</dd>
<dt>openid.ax.value.<alias></dt>
<dd>
Assigns a value to the identifier with the name assigned
by a "type" parameter.
</dd>
<dt>openid.ax.update_url</dt>
<dd>
Returns the "update_url" parameter specified in the
request. If the Identity Provider receives an
"update_url" parameter and it intends to support the
attribute update feature, it MUST present the
"update_url" parameter and value as part of the fetch
response message.
</dd>
</dl></blockquote><p>
</p>
<p>
A fetch response message may also be sent to the
"update_url" specified in <a class='info' href='#fetch_request'>Section 5.1<span> (</span><span class='info'>Fetch Request Format</span><span>)</span></a> in response to attribute value
updates on the Identity Provider.
</p>
<p>
The response to the previous request example, in which the
required full name information and the optional favourite
dog information are both supplied.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
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.value.fname=John Smith
openid.ax.value.gender=M
openid.ax.value.fav_dog=Spot
openid.ax.update_url=http://idconsumer.com/update?transaction_id=a6b5c41
</pre></div>
<a name="store"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.
Store Message</h3>
<p>
The store message is used to store personal identity
information to the Identity Provider.
</p>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.1"></a><h3>6.1.
Store Request Format</h3>
<p>
All of the following request fields are OPTIONAL. Any alias
referred to in a "value" parameter MUST have an associated
"openid.ax.type.<alias>" parameter.
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>openid.ax.type.<alias></dt>
<dd>
Associates an alias with the attribute type identifier
which is the value of this parameter. The name will be
used as a reference in an
"openid.ax.value.<alias>" parameter.
</dd>
<dt>openid.ax.value.<alias></dt>
<dd>
Assigns a value to the identifier with the name assigned
by a "type" parameter.
</dd>
</dl></blockquote><p>
</p>
<p>
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.type.fname=http://example.com/schema/fullname
openid.ax.value.fname=Bob Smith
</pre></div>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.2"></a><h3>6.2.
Store Response Format</h3>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.2.1"></a><h3>6.2.1.
Storage Success</h3>
<p>
The successful store response consists of a successful
response message with the 200 HTTP response code as per
the OpenID specification <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>Recordon, D., Hoyt, J., Fitzpatrick, B., and D. Hardt, “OpenID Authentication 2.0 - Draft 10,” August 2006.</span><span>)</span></a>. No additional
parameters are sent.
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.2.2"></a><h3>6.2.2.
Storage Failure</h3>
<p>
If the store request fails, a parameter named
"status" MUST be sent with the value "failure".
</p>
<p>
Implementations MAY send an additional parameter,
"status.description", containing a brief explanation of
the error response.
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>openid.ax.status</dt>
<dd>
On storage failure, the status parameter is sent with
the value "failure".
</dd>
<dt>openid.ax.status.description</dt>
<dd>
Optional parameter describing the error condition
leading to the failure response.
</dd>
</dl></blockquote><p>
</p>
<p>
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.status=failure
openid.ax.status.description=General storage failure
</pre></div>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.
Security Considerations</h3>
<p>
[NOTE: TBD]
</p>
<a name="anchor12"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8"></a><h3>8.
Acknowledgements</h3>
<p>
John Merrels and other contributors to the document
'draft-merrels-dix'. Portions of that document were re-used
for this one.
</p>
<a name="rfc.references"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9"></a><h3>9.
References</h3>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>9.1. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="OpenID.authentication-2.0">[OpenID.authentication-2.0]</a></td>
<td class="author-text"><a href="mailto:drecordon@verisign.com">Recordon, D.</a>, <a href="mailto:josh@janrain.com">Hoyt, J.</a>, <a href="mailto:brad@danga.com">Fitzpatrick, B.</a>, and <a href="mailto:dick@sxip.com">D. Hardt</a>, “OpenID Authentication 2.0 - Draft 10,” August 2006 (<a href="http://www.openid.net/specs/openid-authentication-2_0-10.txt">TXT</a>, <a href="http://www.openid.net/specs/openid-authentication-2_0-10.html">HTML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3629">[RFC3629]</a></td>
<td class="author-text">Yergeau, F., “<a href="ftp://ftp.isi.edu/in-notes/rfc3629.txt">UTF-8, a transformation format of ISO 10646</a>,” STD 63, RFC 3629, November 2003.</td></tr>
</table>
<a name="rfc.references2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>9.2. Non-normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="OpenID.attribute-types-1.0">[OpenID.attribute-types-1.0]</a></td>
<td class="author-text"><a href="mailto:dick@sxip.com">Hardt, D.</a>, “OpenID Attribute Types - Draft 02,” November 2006 (<a href="http://www.openid.net/specs/openid-attribute-types-1_0-02.txt">TXT</a>, <a href="http://www.openid.net/specs/openid-attribute-types-1_0-02.html">HTML</a>).</td></tr>
</table>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Author's Address</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Dick Hardt</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Sxip Identity</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">798 Beatty Street</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Vancouver, BC V6B 2M1</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">CA</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:dick@sxip.com">dick@sxip.com</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="http://sxip.com/">http://sxip.com/</a></td></tr>
</table>
</body></html>