OpenID Provider
Authentication Policy Extension 1.0

Abstract

This extension to the OpenID Authentication protocol provides a
mechanism by which a Relying Party can request that particular
authentication policies be applied by the OpenID Provider when
authenticating an End User. This extension also provides a mechanism by
which an OpenID Provider may inform a Relying Party which authentication
policies were used. Thus a Relying Party can request that the End User
authenticate, for example, using a phishing-resistant or multi-factor
authentication method.

This extension also provides a mechanism by which a Relying Party can
request that the OpenID Provider communicate the levels of authentication
used, as defined within one or more sets of requested custom Assurance Levels,
and for the OpenID Provider to communicate the levels used.

This extension is not intended to provide all information regarding
the quality of an OpenID Authentication assertion. Rather, it is
designed to be balanced with information the Relying Party already has
with regard to the OpenID Provider and the level of trust it places in
it. If additional information is needed about processes such as new End
User enrollment on the OpenID Provider, such information should either
be transmitted out-of-band or in other extensions such as OpenID
Attribute Exchange. Other aspects (e.g. security characteristics,
credential provisioning, etc) could be dealt with in the future.

This extension is optional, though its use is certainly recommended.
This extension can be used with OpenID Authentication versions 1.1 and
2.0.

While none of the information transmitted using this extension can be
verified by the Relying Party using technology alone, this does not
limit the utility of this extension. Because there is no trust model
specified by OpenID, Relying Parties must decide for themselves which
Providers are
trustworthy; likewise, RPs can decide whether to trust authentication
policy claims from such OpenID Providers as well. As with other OpenID
extensions, it is the Relying Party's responsibility to implement policy
relative to the OpenID Provider's response.

The actual extension namespace alias should be determined on a
per-message basis by the party composing the messages, in such a
manner as to avoid conflicts between multiple extensions. For the
purposes of this document and when constructing OpenID 1.1
messages, the extension namespace alias SHALL be "pape".

Additionally, this specification uses name spaces for the custom
authentication level identification. It is in the form of

openid.pape.auth_level.ns.<cust>=http://some.authlevel.uri

The actual extension namespace alias should be determined on a
per-message basis by the party composing the messages, in such a
manner as to avoid conflicts between multiple extensions. For the
purposes of this document and when constructing OpenID 1.1
messages, the one custom authentication level identification extension
namespace defined by this specification is "nist". Others may also be
defined and used by implementations, for example, "jisa".

1.3.
Terminology

An Authentication Method is a
single mechanism by which the End User authenticated to their
OpenID Provider, for example, a password or a hardware credential.

Authentication Policy:

An Authentication Policy is a
plain-text description of requirements that dictate which
Authentication Methods can be used by an End User when
authenticating to their OpenID Provider. An Authentication Policy
is defined by a URI which must be previously agreed upon by one or
more OPs and RPs.

The Relying Party includes parameters in the OpenID
Authentication request describing its preferences for authentication
policy for the current assertion.

The OpenID Provider processes the PAPE request, prompting the End
User to fulfill the requested policies during the authentication
process.

As part of the OpenID Provider's response to the Relying Party,
the OP includes PAPE information around the End User's
authentication. An OP MAY include this response information even if
not requested by the RP.

When processing the OpenID Provider's response, the Relying Party
takes the PAPE information into account when determining if the End
User should be sent through additional verification steps or if the
OpenID login process cannot proceed due to not meeting policy
requirements.

3.
Advertising Supported Authentication Policies

Via the use of
[Yadis] (Miller, J., Ed., “Yadis Specification 1.0,” 2005.)
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
STRONGLY RECOMMENDED that the following information be added to the
End User's XRDS document.
An OP may choose to advertise both custom levels and supported
polices in the same <xrd:Service>. An OP should only
advertise the authentication policies and custom assurance
level namespaces that it supports.

When advertising supported policies, each policy URI MUST be added as
the value of an <xrd:Type> element of an OpenID
<xrd:Service> element in an XRDS document.

4.
Defined Authentication Policies

The following are defined policies and policy identifiers describing
how the End User may authenticate to an OP. Additional policies can
be specified elsewhere and used without making changes to this document.
The policies described below are designed to be a starting point to
cover the most common use-cases. Additional polices can be found at
http://schemas.openid.net/pape/policies/.

When multiple policies are listed in the Relying Party's
request, the OpenID Provider SHOULD satisfy as many of the
requested policies as possible. This may require, for
instance, that a user who has already been authenticated using
one authentication method be re-authenticated with different
or additional methods that satisfy the request made by the
Relying Party. It is always the responsibility of the RP to
determine whether the particular authentication performed by
the OP satisfied its requirements; this determination may
involve information contained in the PAPE response, specific
knowledge that the RP has about the OP, and additional
information that it may possess or obtain about the particular
authentication performed.

Phishing-Resistant Authentication

http://schemas.openid.net/pape/policies/2007/06/phishing-resistant

An authentication mechanism where a party potentially under
the control of the Relying Party can not gain sufficient
information to be able to successfully authenticate to the End
User's OpenID Provider as if that party were the End User. (Note
that the potentially malicious Relying Party controls where the
User-Agent is redirected to and thus may not send it to the End
User's actual OpenID Provider).

Multi-Factor Authentication

http://schemas.openid.net/pape/policies/2007/06/multi-factor

An authentication mechanism where the End User authenticates
to the OpenID Provider by providing more than one authentication
factor. Common authentication factors are something you know,
something you have, and something you are. An example would be
authentication using a password and a software token or digital
certificate.

Physical Multi-Factor Authentication

http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical

An authentication mechanism where the End User authenticates
to the OpenID Provider by providing more than one authentication
factor where at least one of the factors is a physical factor
such as a hardware device or biometric. Common authentication
factors are something you know, something you have, and
something you are. This policy also implies the Multi-Factor
Authentication policy
(http://schemas.openid.net/pape/policies/2007/06/multi-factor)
and both policies MAY BE specified in conjunction without
conflict. An example would be authentication using a password
and a hardware token.

Of the policies defined above, two are not independent. All
authentications satisfying the Multi-Factor Physical policy also
satisfy the Multi-Factor policy. Therefore, whenever the OP
returns a result saying that Multi-Factor Physical
authentication was performed it MUST also indicate that
Multi-Factor authentication was performed.

(Optional) If the End User has not actively authenticated
to the OP within the number of seconds specified in a manner
fitting the requested policies, the OP SHOULD authenticate the
End User for this request using the requested policies.
The OP MUST actively authenticate the user and not rely on a
browser cookie from a previous authentication.

Value: Integer value greater than or equal to zero in
seconds.

If an OP does not satisfy a request for timely
authentication, the RP may decide not to grant the End User
access to the services provided by the RP. If this
parameter is absent from the request, the OP should authenticate
the user at its own discretion.

openid.pape.preferred_auth_policies

Zero or more authentication policy URIs
representing authentication policies that the OP SHOULD
satisfy when authenticating the user. If multiple policies
are requested, the OP SHOULD satisfy as many of them as it can.

Value: Space separated list of authentication policy
URIs.

If no policies are requested, the RP may be interested in
other information such as the authentication age.

(Optional) The name space for the custom Assurance Level.
Assurance levels and their name spaces are defined by
various parties, such as country or industry specific
standards bodies, or other groups or individuals.

5.2.
Response Parameters

In response to a Relying Party's request, the following parameters
MUST be included in the OpenID Authentication Response. All response
parameters MUST be included in the signature of the Authentication
Response. It is RECOMMENDED that an OP supporting this extension
include the following parameters even if not requested by the Relying
Party.

All response parameters MUST describe the End User's current
session with the OpenID Provider.

openid.ns.pape

Value:

http://specs.openid.net/extensions/pape/1.0

openid.pape.auth_policies

One or more authentication policy URIs representing policies
that the OP satisfied when authenticating the End User.

Value: Space separated list of authentication policy
URIs.

Note: If no policies were met though the OP wishes to
convey other information in the response, this parameter MUST
be included with the value of
http://schemas.openid.net/pape/policies/2007/06/none.

Note: If the RP's request included the
"openid.pape.max_auth_age" parameter then the OP MUST include
"openid.pape.auth_time" in its response. If
"openid.pape.max_auth_age" was not requested, the OP MAY
choose to include "openid.pape.auth_time" in its response.

openid.pape.auth_level.ns.<cust>

(Optional) The name space for the custom Assurance Level
defined by various parties, such as a country or industry
specific standards body, or other groups or individuals.

(Optional) The Assurance Level as defined by the above
standards body, group, or individual that corresponds to
the authentication method and policies employed by the
OP when authenticating the End User.
A custom Assurance Level definition MAY define additional
subparameter values that are expressed within its namespace,
although for reasons of simplicity, this SHOULD be avoided
if possible.

6.
Security Considerations

Per commonly accepted security practices, it should be noted that
the overall strength of any authentication is only as strong as its
weakest step. It is thus recommended that provisioning of
phishing-resistant and other credentials stronger than shared secrets
should be accomplished using methods that are at least as strong as the
credential being provisioned. By counter-example, allowing people to
retrieve a phishing-resistant credential using only a phishable shared
secret negates much of the value provided by the phishing-resistant
credential itself.
Similarly, sometimes using a phishing-resistant method when a
phishable method continues to also sometimes be employed may still
enable phishing attacks to compromise the OpenID.

OPs SHOULD attempt to satisfy the authentication policies
requested by the RP and the reply SHOULD minimally contain at
least the subset of the requested policies that the authentication
performed satisfied. The OP MAY also choose to return
additional policies that the authentication performed satisfied,
even if not requested.

If the RP requested that an authentication level or levels be
returned and the OP supports some or all of those level types,
then the OP SHOULD return the actual level value for each of
the supported types requested, if available.

Note: Level 0 is not an assurance level defined by NIST, but rather
SHOULD be used to signify that the OP recognizes the parameter and the
End User authentication did not meet the requirements of Level 1. See
Appendix A.1.2 (NIST Authentication Mechanism Levels)
for high-level example classifications
of authentication methods within the defined levels. Authentication
using a long-lived browser cookie, for instance, is one example where
the use of "level 0" is appropriate.
Authentications with level 0 should never be used to authorize
access to any resource of any monetary value whatsoever. The
previous sentence should not be construed as implying that any
of the other levels are recommended or appropriate for accessing
resources with monetary value either without the Relying Party doing
an appropriate risk assessment of the particular OpenID provider
asserting them and their issuance and authentication procedures as
they apply to the particular online interaction in question.

Depending on the particular use case being satisfied by the
authentication response and PAPE information, the OpenID Provider will
have to make a decision, ideally with the consent of the End User, as
if it will include the "openid.pape.auth_level.nist" parameter. This
information is designed to give Relying Parties more information
around the strength of credentials used without actually disclosing
the specific credential type. Disclosing the specific credential type
can be considered a potential privacy or security risk.

It is RECOMMENDED that this parameter always be included in the
response from the OP. This holds true even in cases where the End User
authentication does not meet one of the defined Authentication
Policies. For example, if the End User is authenticating using a
password via HTTPS there is still value to the RP in knowing if the
strength of the Password corresponds to the entropy requirements laid
out by Level 1 or 2 or that it does not even meet the minimum
requirement for the lowest level. With that said, discretion needs to
be used by OP's as conveying that one of their End User's has a weak
password to an "un-trustworthy" RP would not generally be considered a
good idea.

The following table illustrates the minimum number of
factors required at each Authentication Mechanism
Level.

Level

Factors

1

1

2

1

3

2

4

2

In all cases, implementing a commonly accepted nonce and
cross-site scripting protection when entering authentication
credentials is required to satisfy all four Authentication Mechanism
Levels. All examples below assume this requirement is met.

This table provides examples of common authentication
technologies and their mapping to NIST Authentication Mechanism
Levels, please be aware that there are details not represented in
these examples that may bear on the resulting Authentication
Mechanism Level.

Appendix B.
Acknowledgements

The authors would like to thank
Andrew Arnott,
John Bradley,
Kim Cameron,
Barry Ferg,
George Fletcher,
Dick Hardt,
Nate Klingstein,
Gary Krall,
Ben Laurie,
Arun Nanda,
Drummond Reed,
Tatsuki Sakushima,
and
Allen Tom
for their feedback when
drafting this specification. David Recordon would also like to
acknowledge VeriSign who employed him during the original authoring of
this specification.