Subversion Repositories specifications

Compare Revisions

Rev 151 → Rev 152

1.0/tags/Draft_03/openid-assertion-quality-extension-1_0.xml New file
0,0 → 1,772
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2629 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
]>
 
<rfc category="info" ipr="none" docName="openid-assertion-quality-extension-1_0">
 
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
 
 
 
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc private="Draft" ?>
 
<front>
<title abbrev="OpenID Assertion Quality Extention">OpenID
Assertion Quality Extension 1.0 - Draft 3</title>
 
<author initials="D.R" surname="Recordon" fullname="David Recordon">
<organization abbrev="VeriSign">VeriSign, Inc.</organization>
<address>
<postal>
<street>487 E Middlefield Road</street>
<city>Mountain View</city> <region>CA</region>
<code>94043</code>
<country>USA</country>
</postal>
<email>drecordon@verisign.com</email>
</address>
</author>
 
<author initials="A.G" surname="Glasser" fullname="Avery Glasser">
<organization abbrev="VxV Solutions">VxV Solutions, Inc.</organization>
<address>
<postal>
<street>329 Bryant Street</street>
<street>Suite #2D</street>
<city>San Francisco</city> <region>CA</region>
<code>94107</code>
<country>USA</country>
</postal>
<email>aglasser@vxvsolutions.com</email>
</address>
</author>
 
<author initials="P.M" surname="Madsen" fullname="Paul Madsen">
<organization abbrev="NTT">NTT</organization>
<address>
<postal>
<street>150 Insmill Crescent</street>
<city>Ottawa</city> <region>ON</region>
<code>K2T 1G2</code>
<country>Canada</country>
</postal>
<email>paulmadsen@ntt-at.com</email>
</address>
</author>
 
<date month="December" year="2006"/>
 
<abstract>
<t>
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).
</t>
 
<t>
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.
</t>
 
<t>
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.
</t>
 
<t>
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.
</t>
</abstract>
</front>
 
<middle>
<section title="Requirements Notation">
<t>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 <xref target="RFC2119"/>.</t>
</section>
 
<section title="Terminology">
<t>
The following terms are defined in
<xref target="OpenIDAuthentication2.0" />:
</t>
 
<t>
<list style="symbols">
<t>Identifier</t>
<t>Relying Party (RP)</t>
<t>OpenID Provider (OP)</t>
</list>
</t>
</section>
 
<section title="Extension Overview">
<t>
<list style="numbers">
<t>
End Users and OPs advertise both enrollment policy and
supported authentication methods via Yadis.
</t>
 
<t>
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.
</t>
 
<t>
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.
</t>
</list>
</t>
</section>
 
<section title="Relation to SAML Authentication Context">
<t>
The Security Assertion Markup Language (SAML) Authentication
Context (<xref target="SAMLAC"/> defines mechanisms by which
SAML Service Providers and OpenID Providers can discuss the
context of an authentication assertion.
</t>
 
<t>
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.
</t>
</section>
 
<section title="Advertising OP Policy" anchor="advertising">
<t>
Via the use of <xref target="Yadis" /> 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.
</t>
 
<t>
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.
</t>
 
<t>
The XML namespace SHALL be "http://openid.net/xmlns/aqe".
</t>
 
<section title="Supported Enrollment Properties" anchor="enroll_props">
<t>
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.
</t>
 
<t>
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.
</t>
 
<t>
<list style="empty">
 
<t>enroll.verified.liveness
<list style="empty">
<t>Did the OP present the End User with a liveness
during the account creation process?</t>
<t>Value: "captcha", "oob", "other" or "no"</t>
<t>Note: "captcha" means any automated CAPTCHA method. "oob" means
that a form of out of band liveness verification (phone call, email,
physical mail). "other" means another type of liveness challenge and
"no" means no liveness testing was performed.</t>
 
 
</list>
</t>
 
<t>enroll.verified.email
<list style="empty">
<t>Did the OP verify any email address the End User
provided during the account creation process?</t>
<t>Value: "yes", "no" or "na"</t>
</list>
</t>
 
<t>enroll.verified.telephone
<list style="empty">
<t>Did the OP verify any telephone number the End User
provided during the account creation process?</t>
<t>Value: "yes" or "no"</t>
</list>
</t>
 
</list>
</t>
</section>
 
<section title="Supported Authentication Properties">
<t>
The following are properties describing authentication requests.
</t>
 
<t>user.authentication.methods
<list style="empty">
<t>What authentication methods is the OP capable of
authenticating the End User through?</t>
<t>Value: Comma-delimited list of "none", "password",
"pin", "fingerbio", "handbio", "hardotp", "irisbio",
"otherbio", "smartcard", "softotp", "voicebio"</t>
 
<t>If multiple methods are listed, no significance
should be assigned to their order. </t>
 
<t>
<list>
<t>none - represents that no authentication
operation is required for the OP to make a positive
assertion about this Identifier. </t>
<t>password - </t>
<t>pin - </t>
<t>fingerbio - </t>
<t>handbio - </t>
<t>irisbio - </t>
<t>voicebio - </t>
<t>otherbio - </t>
<t>smartcard - </t>
<t>softotp - </t>
</list>
</t>
 
<t>
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.
</t>
</list>
</t>
 
</section>
</section>
 
<section title="Authentication Protocol">
 
<section title="Request Parameters">
<t>
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.
</t>
 
<t>
<list style="symbols">
<t>openid.ns.aqe
<list style="empty">
<t>Value: "http://openid.net/extensions/aqe/1.0"</t>
</list>
</t>
 
<t>openid.aqe.max_auth_age
<list style="empty">
<t>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.</t>
 
<t>Value: Numeric value greater than or equal to zero in
seconds.</t>
 
<t>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.</t>
</list>
</t>
 
<t>openid.aqe.multi_factor_order
<list style="empty">
<t>Optional: This will inform an OP that the order of methods
used in authentication must follow the order specified by the RP.
If not specified, it is treated as a preferred order.</t>
 
<t>Value: "mandatory", "preferred"</t>
 
<t>Mandatory means that the RP must perform the authentications in
the order prescribed in the openid.aqe.auth_factor1/2/3</t>
</list>
</t>
 
<t>openid.aqe.auth_factor1
<list style="empty">
<t>Optional: The method of authentication the RP would like the OP
to perform, or in the case of a multi-factor authentication, the
first method that the RP would like the OP to perform. The mode should
match one of the advertised values in the XRDS. If this is not
specified, it is assumed that only a single factor is required
and any authentication method is acceptable.</t>
 
<t>Value: Comma-delimited list of "none", "password", "pin",
"fingerbio", "handbio", "hardotp", "irisbio", "otherbio",
"smartcard", "softotp", "voicebio"</t>
 
<t>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 to
authenticate against. OPs should note that
authenticating a user by a non-designated method may
result in an RP denying access.</t>
</list>
</t>
 
<t>openid.aqe.auth_factor2
<list style="empty">
<t>Optional: In the case of a multi-factor authentication,
the second method that the RP would like the OP to perform.
The mode should match one of the advertised values in the XRDS.
If this is not specified, it is assumed that the RP is requesting
only a single factor for authentication.
The OP will not use the same method for this factor as was used in
any previous factors. For example, if the first factor is a password,
the second factor cannot also be a password.
For openid.aqe.auth_factor2 to be included, openid.aqe.auth_factor1 must
have been previously defined.</t>
 
<t>Value: Comma-delimited list of "none", "password", "pin",
"fingerbio", "handbio", "hardotp", "irisbio", "otherbio",
"smartcard", "softotp", "voicebio"</t>
 
<t>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 to
authenticate against. OPs should note that
authenticating a user by a non-designated method may
result in an RP denying access.</t>
</list>
</t>
 
<t>openid.aqe.auth_factor3
<list style="empty">
<t>Optional: In the case of a multi-factor authentication,
the third method that the RP would like the OP to perform.
The mode should match one of the advertised values in the XRDS.
If this is not specified, it is assumed that the RP is requesting
only two factors for authentication.
The OP will not use the same method for this factor as was used in
any previous factors. For example, if the first factor is a password,
the second factor cannot also be a password.
For openid.aqe.auth_factor3 to be included, openid.aqe.auth_factor2 must
have been previously defined.</t>
 
<t>Value: Comma-delimited list of "none", "password", "pin",
"fingerbio", "handbio", "hardotp", "irisbio", "otherbio",
"smartcard", "softotp", "voicebio"</t>
 
<t>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 to
authenticate against. OPs should note that
authenticating a user by a non-designated method may
result in an RP denying access.</t>
</list>
</t>
 
 
</list>
</t>
</section>
 
<section title="Response Parameters">
<t>
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.
</t>
 
<t>
<list style="symbols">
<t>openid.ns.aqe
<list style="empty">
<t>Value: "http://openid.net/extensions/aqe/1.0"</t>
</list>
</t>
 
<t>openid.aqe.enrollment_liveness
<list style="empty">
<t>Was liveness verified by the OP during the End User's
enrollment.</t>
<t>Value: Comma-delimited list of "captcha", "oob",
"other" or "no".</t>
<t>Note: These values correspond with those in <xref target="enroll_props" />.</t>
</list>
</t>
 
<t>openid.aqe.enrollment_verified
<list style="empty">
<t>Attributes verified by the OP during the End User's
enrollment.</t>
<t>Value: Comma-delimited list of "email",
"telephone".</t>
<t>Note: These values correspond with those in <xref target="enroll_props" />.</t>
</list>
</t>
 
<t>openid.aqe.auth_factor1
<list style="empty">
<t>Description of the mechanism by which the End User
authenticated to to the OP for this request.</t>
 
<t>Value: "none", "password",
"pin", "fingerbio", "handbio", "hardotp", "irisbio",
"otherbio", "smartcard", "softotp", "voicebio"</t>
</list>
</t>
 
<t>openid.aqe.auth_factor2
<list style="empty">
<t>Only provided if the OP uses two or more factors for authentication.</t>
 
<t>Value: "none", "password",
"pin", "fingerbio", "handbio", "hardotp", "irisbio",
"otherbio", "smartcard", "softotp", "voicebio"</t>
</list>
</t>
 
<t>openid.aqe.auth_factor3
<list style="empty">
<t>Only provided if the OP uses three for authentication.</t>
 
<t>Value: "none", "password",
"pin", "fingerbio", "handbio", "hardotp", "irisbio",
"otherbio", "smartcard", "softotp", "voicebio"</t>
</list>
</t>
 
 
<t>openid.aqe.auth_age
<list style="empty">
<t>The number of seconds prior to this request that the
End User authenticated to the OP using the mode
specified in "openid.aqe.auth_factor".</t>
<t>Value: Numeric value greater than or equal to zero in
seconds.</t>
</list>
</t>
</list>
</t>
 
<t>
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_factor1",
"openid.aqe.auth_age1", "openid.aqe.auth_factor2",
openid.aqe.auth_age2".
</t>
</section>
 
</section>
 
<section title="Security Considerations">
<t>None known.</t>
</section>
 
<section title="To-Do List">
<t>
<list style="numbers">
<t>
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.
</t>
 
<t>
Define the XML namespace to be used in the XRDS document.
</t>
 
<t>
Define the URI to represent this extension.
</t>
</list>
</t>
</section>
 
<section title="Examples">
<t>Non-normative</t>
 
<section title="XRDS Document">
<t>
The following examples show how information in <xref target="advertising" /> can be expressed.
</t>
 
<t>
<figure>
<preamble>
A 'weak' OP supporting only password based authentication
that presented a captcha upon enrollment and verified the
End User's email address.
</preamble>
<artwork><![CDATA[
<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>
]]></artwork>
</figure>
</t>
 
 
<t>
<figure>
<preamble>
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.
</preamble>
<artwork><![CDATA[
<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>
]]></artwork>
</figure>
</t>
 
<t>
<figure>
<preamble>
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.
</preamble>
<artwork><![CDATA[
<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>
]]></artwork>
</figure>
</t>
 
</section>
 
</section>
</middle>
 
<back>
<references title='Normative References'>
<reference anchor='RFC2119'>
<front>
<title>
Key words for use in RFCs to Indicate Requirement Levels
</title>
<author initials='B.S' surname='Bradner' fullname='Scott Bradner'>
<organization>Alis Technologies</organization>
</author>
<date year="?"/>
</front>
<seriesInfo name="RFC" value="2119" />
</reference>
 
<reference anchor="OpenIDAuthentication2.0">
<front>
<title>OpenID Authentication 2.0 - Draft 10</title>
 
<author initials="D.R" surname="Recordon" fullname="David Recordon">
<organization abbrev="VeriSign">VeriSign, Inc.</organization>
</author>
 
<author initials="J.H" surname="Hoyt" fullname="Josh Hoyt">
<organization abbrev="JanRain">JanRain, Inc.</organization>
</author>
 
<author initials="D.H" surname="Hardt" fullname="Dick Hardt">
<organization abbrev="Sxip">Sxip Identity Corporation</organization>
</author>
 
<author initials="B.F" surname="Fitzpatrick"
fullname="Brad Fitzpatrick">
<organization abbrev="Six Apart">Six Apart, Ltd.</organization>
</author>
<date year="2006"/>
</front>
<format type='TXT' target='http://www.openid.net/specs/openid-authentication-2_0-10.txt'/>
<format type='HTML' target='http://www.openid.net/specs/openid-authentication-2_0-10.html'/>
</reference>
 
<reference anchor="Yadis">
<front>
<title>Yadis Specification 1.0</title>
<author initials='J.M' surname='Miller' fullname="Joaquin Miller">
<organization>NetMesh</organization>
</author>
<date year="2005"/>
</front>
<format type='PDF' target="http://yadis.org/papers/yadis-v1.0.pdf" />
<format type='ODT' target="http://yadis.org/papers/yadis-v1.0.odt" />
</reference>
 
<reference anchor="SAMLAC">
<front>
<title>SAML 2.0 Authentication Context</title>
<author initials='J.K' surname='Kemp' fullname="John Kemp">
<organization>Nokia</organization>
</author>
<date year="2005"/>
</front>
<format type='PDF' target="http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf" />
</reference>
 
</references>
</back>
</rfc>
\ No newline at end of file