<!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
Assertion Quality Extension 1.0 - Draft 4</title>
<meta http-equiv="Expires" content="Tue, 28 Nov 2006 13:30:25 +0000">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID
Assertion Quality Extension 1.0 - Draft 4">
<meta name="generator" content="xml2rfc v1.32pre2 (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. Recordon</td></tr>
<tr><td class="header"> </td><td class="header">VeriSign</td></tr>
<tr><td class="header"> </td><td class="header">A. Glasser</td></tr>
<tr><td class="header"> </td><td class="header">VxV Solutions</td></tr>
<tr><td class="header"> </td><td class="header">P. Madsen</td></tr>
<tr><td class="header"> </td><td class="header">NTT</td></tr>
<tr><td class="header"> </td><td class="header">November 28, 2006</td></tr>
</table></td></tr></table>
<h1><br />OpenID
Assertion Quality Extension 1.0 - Draft 4</h1>
<h3>Abstract</h3>
<p>
This extention to the OpenID Authentication protocol provides
means for a Relying Party to request additional information
about the specifics by which a user enrolled and/or
authenticated to the OpenID Provider, as well as for an OpenID
Provider to add such information into assertions. Such
information may be necessary for use cases in which, for an RP
to make an assesment of the quality of an assertion from a OP,
the OP's identity is not on its alone sufficient (as might be
the case were an OP capable of authenticating a user through
various authentication mechanisms).
</p>
<p>
While there are other aspects of lifecycle management that may
bear on the resultant quality of an OpenID Authentication
assertion - enrollment and authentication are generally the
two characteristics that are most useful in distinguishing
authentication quality. Consequently, we focus on these
aspects here. We expect that other aspects (e.g. security
characteristics, credential provisioning, etc) could be dealt
with in the future.
</p>
<p>
As an extension, it requires no changes to either the Yadis
protocol or the OpenID Authentication protocol and is viewed
as an optional extension though its use is certainly
recommended.
</p>
<p>
We acknowledge that, while none of the information expressed
via this extension can be verified by the Relying Party in a
technological fashion, this need not be viewed as an
issue. The lack of an inherent trust model within OpenID
allows for Relying Parties to decide which OPs they trust
using whatever criteria they choose - likewise RPs will decide
whether or not to trust claims as to authentication quality
from such OPs as well.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1</a>
Requirements Notation<br />
<a href="#anchor2">2</a>
Terminology<br />
<a href="#anchor3">3</a>
Extension Overview<br />
<a href="#anchor4">4</a>
Relation to SAML Authentication Context<br />
<a href="#advertising">5</a>
Advertising OP Policy<br />
<a href="#enroll_props">5.1</a>
Supported Enrollment Properties<br />
<a href="#anchor5">5.2</a>
Supported Authentication Properties<br />
<a href="#anchor6">6</a>
Authentication Protocol<br />
<a href="#anchor7">6.1</a>
Request Parameters<br />
<a href="#anchor8">6.2</a>
Response Parameters<br />
<a href="#anchor9">7</a>
Security Considerations<br />
<a href="#anchor10">8</a>
To-Do List<br />
<a href="#anchor11">9</a>
Examples<br />
<a href="#anchor12">9.1</a>
XRDS Document<br />
<a href="#rfc.references1">10</a>
Normative References<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
</p>
<br clear="all" />
<a name="rfc.section.1"></a><h4><a name="anchor1">1</a>
Requirements Notation</h4>
<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, B., “Key words for use in RFCs to Indicate Requirement Levels,” ?.</span><span>)</span></a>.
</p>
<a name="rfc.section.2"></a><h4><a name="anchor2">2</a>
Terminology</h4>
<p>
The following terms are defined in
<a class='info' href='#OpenIDAuthentication2.0'>[OpenIDAuthentication2.0]<span> (</span><span class='info'>Recordon, D., Hoyt, J., Hardt, D., and B. Fitzpatrick, “OpenID Authentication 2.0 - Draft 10,” 2006.</span><span>)</span></a>:
</p>
<p>
</p>
<ul class="text">
<li>Identifier
</li>
<li>Relying Party (RP)
</li>
<li>OpenID Provider (OP)
</li>
</ul><p>
</p>
<a name="rfc.section.3"></a><h4><a name="anchor3">3</a>
Extension Overview</h4>
<p>
</p>
<ol class="text">
<li>
End Users and OPs advertise both enrollment policy and
supported authentication methods via Yadis.
</li>
<li>
Based on Yadis advertisements, the Relying Party includes
parameters in the OpenID Authentication request describing
its preferences for enrollment and authentication policy
for any subsequent assertions.
</li>
<li>
The OpenID Provider responds to the Authentication request
with an assertion - supplemented with information about
the enrollment and authentication policies under which the
assertion was issued. The RP will take this information as
input into its assessment of the quality of the assertion.
</li>
</ol><p>
</p>
<a name="rfc.section.4"></a><h4><a name="anchor4">4</a>
Relation to SAML Authentication Context</h4>
<p>
The Security Assertion Markup Language (SAML) Authentication
Context (<a class='info' href='#SAMLAC'>[SAMLAC]<span> (</span><span class='info'>Kemp, J., “SAML 2.0 Authentication Context,” 2005.</span><span>)</span></a> defines mechanisms by which
SAML Service Providers and OpenID Providers can discuss the
context of an authentication assertion.
</p>
<p>
The authors acknowledge the similar motivation between SAML's
Authentication Context and this extension. Where possible, we
have attempted to stay aligned with the SAML Authentication
Context model. Indeed, we see this topic as a likely area of
convergence between OpenID and SAML. More work is needed here.
</p>
<a name="rfc.section.5"></a><h4><a name="advertising">5</a>
Advertising OP Policy</h4>
<p>
Via the use of <a class='info' href='#Yadis'>[Yadis]<span> (</span><span class='info'>Miller, J., “Yadis Specification 1.0,” 2005.</span><span>)</span></a> within OpenID, Relying
Parties are able to discover OpenID Provider service
information in an automated fashion. This is used within
OpenID Authentication for a RP to discover what version of the
protocol each OP listed supports as well as any extensions,
such as this one, that are supported. To aide in the process
of a Relying Party selecting which OP they wish to interact
with, it is advised that the following information be added to
the End User's XRDS document.
</p>
<p>
It should be noted that implementors can add additional
parameters to describe other attributes that can be verified
during the enrollment process or properties of a specific
authentication request. The following are meant as
examples of what we feel are a reasonable baseline when
looking at solving this problem.
</p>
<p>
The XML namespace SHALL be "http://openid.net/xmlns/aqe".
</p>
<a name="rfc.section.5.1"></a><h4><a name="enroll_props">5.1</a>
Supported Enrollment Properties</h4>
<p>
The following are properties describing the mechanisms used
by the OP policy at the time of enrollment (account
creation) and, as such, do not change with each
authentication request. In other words, they describe what
has already happened, and not a capability for something to
happen.
</p>
<p>
For each property, the following values apply. The value of
"yes" means that the End User has successfully passed
verification. The value of "no" means that the user has not
yet completed or has failed verification. The value of "na"
means that the OP has not tried this method of
verification. If a particular property is not declared, the
property does not need to be declared and will be treated as
the "na" or "no" value.
</p>
<p>
</p>
<blockquote class="text">
<p>enroll.verified.captcha
</p>
<blockquote class="text">
<p>Did the OP present the End User with a CAPTCHA
during the account creation process?
</p>
<p>Value: "yes" or "no"
</p>
</blockquote>
<p>enroll.verified.email
</p>
<blockquote class="text">
<p>Did the OP verify any email address the End User
provided during the account creation process?
</p>
<p>Value: "yes", "no" or "na"
</p>
</blockquote>
<p>enroll.verified.telephone
</p>
<blockquote class="text">
<p>Did the OP verify any telephone number the End User
provided during the account creation process?
</p>
<p>Value: "yes" or "no"
</p>
</blockquote>
</blockquote><p>
</p>
<a name="rfc.section.5.2"></a><h4><a name="anchor5">5.2</a>
Supported Authentication Properties</h4>
<p>
The following are properties describing authentication requests.
</p>
<p>user.authentication.methods
</p>
<blockquote class="text">
<p>What authentication methods is the OP capable of
authenticating the End User through?
</p>
<p>Value: Comma-delimited list of "none", "password",
"pin", "fingerbio", "handbio", "hardotp", "irisbio",
"otherbio", "smartcard", "softotp", "voicebio"
</p>
<p>If multiple methods are listed, no significance
should be assigned to their order.
</p>
<p>
</p>
<blockquote class="text">
<p>none - represents that no authentication
operation is required for the OP to make a positive
assertion about this Identifier.
</p>
<p>password -
</p>
<p>pin -
</p>
<p>fingerbio -
</p>
<p>handbio -
</p>
<p>irisbio -
</p>
<p>voicebio -
</p>
<p>otherbio -
</p>
<p>smartcard -
</p>
<p>softotp -
</p>
</blockquote>
<p>
OpenID actors are free to extend the above list as
necessary. Care MUST be taken to ensure that any
identifier for an authentication method will be
recognized and interpreted appropriately.
</p>
</blockquote><p>
</p>
<a name="rfc.section.6"></a><h4><a name="anchor6">6</a>
Authentication Protocol</h4>
<a name="rfc.section.6.1"></a><h4><a name="anchor7">6.1</a>
Request Parameters</h4>
<p>
During an OpenID Authentication 2.0 Request (Section 10),
the following parameters can be included by the Relying
Party to describe preferences for the particular
authentication session.
</p>
<p>
</p>
<ul class="text">
<li>openid.ns.aqe
<blockquote class="text">
<p>Value: "http://openid.net/extensions/aqe/1.0"
</p>
</blockquote>
</li>
<li>openid.aqe.max_auth_age
<blockquote class="text">
<p>If the End User has not actively authenticated to the
OP within the number of seconds specified, the OP SHOULD
authenticate the End User for this request.
</p>
<p>Value: Numeric value greater than or equal to zero in
seconds.
</p>
<p>OP should realize that not adhering to the request
for re-authentication means that the user will most
likely not be allowed access to the RP.
</p>
</blockquote>
</li>
<li>openid.aqe.preferred_auth_mode
<blockquote class="text">
<p>Optional. The mode(s) of authentication the RP would
like the OP to perform. The mode should match one of the
advertised values in the XRDS.
</p>
<p>Value: Comma-delimited list of "none", "password", "pin",
"fingerbio", "handbio", "hardotp", "irisbio", "otherbio",
"smartcard", "softotp", "voicebio"
</p>
<p>Note: The OP should attempt to authenticate the user
with the most secure mode requested. For example, if
the OP has determined that their voicebio method is
stronger than their password method and the RP requests
either "voicebio or password", the OP should strive to
authenticate the user by "voicebio" when possible. If
the two modes are considered equally strong, then it is
the choice of the OP regarding which one or ones to
authenticate against. OPs should note that
authenticating a user by a non-preferred method may
result in an RP denying access.
</p>
</blockquote>
</li>
</ul><p>
</p>
<a name="rfc.section.6.2"></a><h4><a name="anchor8">6.2</a>
Response Parameters</h4>
<p>
In response to a Relying Party's request, the following
parameters MUST be included in the OpenID Authentication 2.0
Response (Section 11). It is RECOMMENDED that an OP
supporting this extension include the following parameters
even if not requested by the Relying Party.
</p>
<p>
</p>
<ul class="text">
<li>openid.ns.aqe
<blockquote class="text">
<p>Value: "http://openid.net/extensions/aqe/1.0"
</p>
</blockquote>
</li>
<li>openid.aqe.enrollment_verified
<blockquote class="text">
<p>Attributes verified by the OP during the End User's
enrollment.
</p>
<p>Value: Comma-delimited list of "captcha", "email",
"telephone".
</p>
<p>Note: These values correspond with those in <a class='info' href='#enroll_props'>Section 5.1<span> (</span><span class='info'>Supported Enrollment Properties</span><span>)</span></a>.
</p>
</blockquote>
</li>
<li>openid.aqe.auth_mode
<blockquote class="text">
<p>Description of the mechanism by which the End User
authenticated to to the OP for this request.
</p>
<p>Value: Comma-delimited list of "none", "password",
"pin", "fingerbio", "handbio", "hardotp", "irisbio",
"otherbio", "smartcard", "softotp", "voicebio"
</p>
</blockquote>
</li>
<li>openid.aqe.auth_age
<blockquote class="text">
<p>The number of seconds prior to this request that the
End User authenticated to the OP using the mode
specified in "openid.aqe.auth_mode".
</p>
<p>Value: Numeric value greater than or equal to zero in
seconds.
</p>
</blockquote>
</li>
</ul><p>
</p>
<p>
If the OP used more than one method to authenticate the End
User for this request, it SHOULD be expressed to the RP in
the response. To do so, the OP MUST post-fix both
"openid.aqe.auth_mode" and "openid.aqe.auth_age" with a
numeric value starting at 1 and incrementing by one for each
authentication method used. Thus an OP using two
authentication methods would include the following
parameters in its response: "openid.aqe.auth_mode1",
"openid.aqe.auth_age1", "openid.aqe.auth_mode2",
openid.aqe.auth_age2".
</p>
<a name="rfc.section.7"></a><h4><a name="anchor9">7</a>
Security Considerations</h4>
<p>None known.
</p>
<a name="rfc.section.8"></a><h4><a name="anchor10">8</a>
To-Do List</h4>
<p>
</p>
<ol class="text">
<li>
Use an existing schema when referring to attributes such
as email, telephone, etc. This will also provide for the
extension to be extensible by other parties.
</li>
<li>
Define the XML namespace to be used in the XRDS document.
</li>
<li>
Define the URI to represent this extension.
</li>
</ol><p>
</p>
<a name="rfc.section.9"></a><h4><a name="anchor11">9</a>
Examples</h4>
<p>Non-normative
</p>
<a name="rfc.section.9.1"></a><h4><a name="anchor12">9.1</a>
XRDS Document</h4>
<p>
The following examples show how information in <a class='info' href='#advertising'>Section 5<span> (</span><span class='info'>Advertising OP Policy</span><span>)</span></a> can be expressed.
</p>
<p>
<p>
A 'weak' OP supporting only password based authentication
that presented a captcha upon enrollment and verified the
End User's email address.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
<xrds:XRDS xmlns:openidaqe="http://openid.net/xmlns/aqe"
xmlns:openid="http://openid.net/xmlns/1.0" xmlns:xrds="xri://$xrds"
xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service>
<Type>http://openid.net/signon/2.0</Type>
<Type>http://openid.net/extensions/aqe/1.0</Type>
<URI>http://weakidp.example.com/openid/server</URI>
<openidaqe:enroll.verified.captcha>
yes
</openidaqe:enroll.verified.captcha>
<openidaqe:enroll.verified.telephone>
no
</openidaqe:enroll.verified.telephone>
<openidaqe:enroll.verified.email>
yes
</openidqe:enroll.verified.email>
<openidaqe:user.authentication.methods>
password
</openidaqe:user.authentication.methods>
</Service>
</XRD>
</xrds:XRDS>
</pre></div>
<p>
<p>
A 'strong' OP supporting both hardotp and voice print
biometric based authentication that presented a captcha
but and verified the End User's email address upon enrollment.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
<xrds:XRDS xmlns:openidaqe="http://openid.net/xmlns/aqe"
xmlns:openid="http://openid.net/xmlns/1.0" xmlns:xrds="xri://$xrds"
xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service>
<Type>http://openid.net/signon/2.0</Type>
<Type>http://openid.net/extensions/aqe/1.0</Type>
<URI>http://strongidp.example.com/openid/server</URI>
<openidaqe:enroll.verified.captcha>
yes
</openidaqe:enroll.verified.captcha>
<openidaqe:enroll.verified.telephone>
no
</openidaqe:enroll.verified.telephone>
<openidaqe:enroll.verified.email>
yes
</openidqe:enroll.verified.email>
<openidaqe:user.authentication.methods>
hardotp,voicebio
</openidaqe:user.authentication.methods>
</Service>
</XRD>
</xrds:XRDS>
</pre></div>
<p>
<p>
A description of two seperate OPs, both the prior
strong and weak examples. This would allow the RP to
choose the applicable OP for the particular
authentication request.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
<xrds:XRDS xmlns:openidaqe="http://openid.net/xmlns/aqe"
xmlns:openid="http://openid.net/xmlns/1.0" xmlns:xrds="xri://$xrds"
xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service>
<Type>http://openid.net/signon/2.0</Type>
<Type>http://openid.net/extensions/aqe/1.0</Type>
<URI>http://weakidp.example.com/openid/server</URI>
<openidaqe:enroll.verified.captcha>
yes
</openidaqe:enroll.verified.captcha>
<openidaqe:enroll.verified.telephone>
no
</openidaqe:enroll.verified.telephone>
<openidaqe:enroll.verified.email>
yes
</openidqe:enroll.verified.email>
<openidaqe:user.authentication.methods>
password
</openidaqe:user.authentication.methods>
</Service>
<Service>
<Type>http://openid.net/signon/2.0</Type>
<Type>http://openid.net/extensions/aqe/1.0</Type>
<URI>http://strongidp.example.com/openid/server</URI>
<openidaqe:enroll.verified.captcha>
yes
</openidaqe:enroll.verified.captcha>
<openidaqe:enroll.verified.telephone>
no
</openidaqe:enroll.verified.telephone>
<openidaqe:enroll.verified.email>
yes
</openidqe:enroll.verified.email>
<openidaqe:user.authentication.methods>
hardotp,voicebio
</openidaqe:user.authentication.methods>
</Service>
</XRD>
</xrds:XRDS>
</pre></div>
<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>10. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="OpenIDAuthentication2.0">[OpenIDAuthentication2.0]</a></td>
<td class="author-text">Recordon, D., Hoyt, J., Hardt, D., and B. Fitzpatrick, “OpenID Authentication 2.0 - Draft 10,” 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">Bradner, B., “<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>,” RFC 2119, ?.</td></tr>
<tr><td class="author-text" valign="top"><a name="SAMLAC">[SAMLAC]</a></td>
<td class="author-text">Kemp, J., “<a href="http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf">SAML 2.0 Authentication Context</a>,” 2005.</td></tr>
<tr><td class="author-text" valign="top"><a name="Yadis">[Yadis]</a></td>
<td class="author-text">Miller, J., “Yadis Specification 1.0,” 2005 (<a href="http://yadis.org/papers/yadis-v1.0.pdf">PDF</a>, <a href="http://yadis.org/papers/yadis-v1.0.odt">ODT</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>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">David Recordon</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">VeriSign, Inc.</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">487 E Middlefield Road</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Mountain View, CA 94043</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:drecordon@verisign.com">drecordon@verisign.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Avery Glasser</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">VxV Solutions, Inc.</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">329 Bryant Street</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Suite #2D</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">San Francisco, CA 94107</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:aglasser@vxvsolutions.com">aglasser@vxvsolutions.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Paul Madsen</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">NTT</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">150 Insmill Crescent</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Ottawa, ON K2T 1G2</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Canada</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:paulmadsen@ntt-at.com">paulmadsen@ntt-at.com</a></td></tr>
</table>
</body></html>