<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
        <head>
                <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
                <title>PAPE-AM Specification 1.0</title>
                <style type="text/css">
                        /* ;;; OPENID STUFF ;;; */
                        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; }

                        a.info {
                                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 {
                                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: 0em; 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; }

                        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; }

                        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;
                        }

                        /* ;;; OUR STUFF ;;; */

                        li { margin-left: 0px; }
                        td.author { width: 217px; text-align: right; }
                        dt { font-weight: bold; }
                        dd { padding-top: 0.5ex; padding-bottom: 0.5ex; }
                        #toc li { list-style: none; margin-left: -1em; font-weight: bold; }
                        div.toc-link {
                                padding: 4px;
                                background-color: #990000;
                                font-size: x-small;
                                font-weight: bold;
                                float: right;
                        }
                        div.toc-link a {
                                text-decoration: none;
                                color: white;
                        }
                </style>
        </head>
        <body>
                <table>
                        <tbody>                                
                                <tr><td class="header">&nbsp;</td><td class="header">Taylor Venable, TrustBearer Labs</td></tr>
                                <tr><td class="header">&nbsp;</td><td class="header">Siddharth Bajaj, VeriSign</td></tr>
                                <tr><td class="header">&nbsp;</td><td class="header">Brian Kelly, TrustBearer Labs</td></tr>
                                <tr><td class="header">&nbsp;</td><td class="header">Mingliang Pei, VeriSign</td></tr>
                                  <tr><td class="header">Draft</td><td class="header">Daniel Perry</td></tr>
                        </tbody>
                </table>
                <h1>OpenID Provider Authentication Policy Extension - Authentication Mechanisms (PAPE-AM) 1.0</h1>

                <p>The PAPE extension <a href="#reference-pape">[PAPE]</a> to the OpenID Authentication
                protocol provides means for a Relying Party to request previously agreed-upon authentication
                policies be applied by the OpenID Provider and for an OpenID Provider to inform a Relying
                Party what authentication policies were used.</p>

                <p>This proposed addendum is intended to extend the policies supported by the existing PAPE <a
                        href="#reference-pape">[PAPE]</a> specification and provide more granular policies and
                information to the Relying Parties.</p>

                <p>For example, Relying Parties will be able to request that the end user authenticate to
                the OpenID Provider using certain forms of credentials such as a digital certificate on
                smart card issued by a particular organization, an OTP token, or that OpenID users be
                authenticated to the provider under other certain specific security-related conditions.</p>

                <p>The authors have deliberated on each of the attributes below and have tried to keep a
                sensible balance between simplicity and functionality. They identify some use cases where such
                granular control would be beneficial to the Relying Parties.</p>

                <p>The authors propose to the OpenID community to incorporate this work in its specifications
                as appropriate.</p>

                <hr/>
                <h3>Table of Contents</h3>
                <ul id="toc">
                        <li><a href='#section-1'>1.</a> Definitions<ul>
                                <li><a href='#section-1.1'>1.1.</a> Requirements Notation</li>
                                <li><a href='#section-1.2'>1.2.</a> Conventions</li>
                                <li><a href='#section-1.3'>1.3.</a> Terminology</li>
                        </ul>
                        </li>
                        <li><a href='#section-2'>2.</a> Defined Authentication Policies<ul>
                                <li><a href='#section-2.1'>2.1.</a> Scope of this Document</li>
                                <li><a href='#section-2.2'>2.2.</a> Supporting Use Cases</li>
                        </ul>
                        </li>
                        <li><a href='#section-3'>3.</a> Authentication Protocol<ul>
                                <li><a href='#section-3.1'>3.1.</a> Request Parameters<ul>
                                        <li><a href='#section-3.1.1'>3.1.1.</a> General</li>
                                        <li><a href='#section-3.1.2'>3.1.2.</a> Password</li>
                                        <li><a href='#section-3.1.3'>3.1.3.</a> PKI</li>
                                        <li><a href='#section-3.1.4'>3.1.4.</a> OTP</li>
                                        <li><a href='#section-3.1.5'>3.1.5.</a> Channel Security</li>
                                        <li><a href='#section-3.1.6'>3.1.6.</a> Provider Policy</li>
                                </ul>
                                </li>
                                <li><a href='#section-3.2'>3.2.</a> Response Parameters<ul>
                                        <li><a href='#section-3.2.1'>3.2.1.</a> General</li>
                                        <li><a href='#section-3.2.2'>3.2.2.</a> Password</li>
                                        <li><a href='#section-3.2.3'>3.2.3.</a> PKI</li>
                                        <li><a href='#section-3.2.4'>3.2.4.</a> OTP</li>
                                        <li><a href='#section-3.2.5'>3.2.5.</a> Channel Security</li>
                                        <li><a href='#section-3.2.6'>3.2.6.</a> Provider Policy</li>
                                </ul>
                                </li>
                        </ul>
                        </li>
                        <li><a href='#section-4'>4.</a> Security Considerations</li><ul>
                                <li><a href='#section-4.1'>4.1.</a> Session-specific Information</li>
                                <li><a href='#section-4.2'>4.2.</a> NIST Assurance Levels</li>
                                <li><a href='#section-4.3'>4.3.</a> PKI Authentication</li>
                                <li><a href='#section-4.4'>4.4.</a> Privacy</li>
                        </ul>
                        <li><a href='#section-5'>5.</a> Examples<ul>
                                <li><a href='#section-5.1'>5.1.</a> Client Authentication with PKI token</li>
                                <li><a href='#section-5.2'>5.2.</a> Enforcing Password Strength</li>
                                <li><a href='#section-5.3'>5.3.</a> One Time Password</li>
                        </ul>
                        </li>
                        <li><a href='#appendix-a'>Appendix A.</a> URI Reference</li>
                        <li><a href='#section-6'>6.</a> Acknowledgments</li>
                        <li><a href='#section-7'>7.</a> Normative References</li>
                        <li><a href='#section-8'>8.</a> Authors' Addresses</li>
                </ul>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-1'>1. Definitions</h3>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-1.1'>1.1. Requirements Notation</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 RFC2119
                <a href="#reference-rfc2119">[RFC2119]</a></p>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-1.2'>1.2. Conventions</h3>

                <p>Throughout this document, values are quoted to indicate that they are to be taken
                literally.  When using these values in protocol messages, the quotes MUST NOT be used as
                part of the value.</p>

                <p>All OpenID Provider Authentication Policy Extension (PAPE) messages MUST contain the
                following extension namespace declaration, as specified in the Extensions section of
                OpenIDAuthentication2.0 <a href="#reference-openid2.0">[OpenID2.0]</a></p>

                <blockquote>
                        openid.ns.&lt;alias&gt;=http://specs.openid.net/extensions/pape/1.0
                </blockquote>

                <p>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".</p>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-1.3'>1.3. Terminology</h3>
                <p>The following terms are defined in <a href="#reference-openid2.0">[OpenID2.0]</a></p>
                <ul class="simple">
                        <li>Identifier</li>
                        <li>OpenID Provider (OP)</li>
                        <li>Relying Party (RP)</li>
                        <li>User-Agent</li>
                </ul>
                <dl>
                        <dt>Authentication Method</dt>
                        <dd>A single mechanism by which the end user authenticated to their OpenID provider.
                        For example, a password or a hardware credential.</dd>

                        <dt>Authentication Policy</dt>
                        <dd>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 providers and relying parties.
                </dl>
                <p>There are several places in this specification when a particular situation is referred to
                as "erroneous".  Such circumstances indicate a failure to comply with this specification.
                In such a situation, it is RECOMMENDED that the OP refuse the authentication.</p>
                <p>This specification uses specific terminology to denote the domain of the type of response.</p>
                <dl>
                        <dt>string</dt>
                        <dd>A string is taken literally as-is.  Although shown in this document as occurring
                        between quotation marks, these are not a part of the actual protocol and MUST be omitted
                        in the content of the parameter.</dd>
                        <dt>integer</dt>
                        <dd>An integral number written as a sequence of digits, where a digit is an ASCII value
                        '0' through '9'.  The presence of any character other than a digit within the value
                        SHOULD be treated as an erroneous response.  Note that this means there are no negative
                        values; for the sake of this specification all integers are implicitly positive.</dd>
                        <dt>boolean</dt>
                        <dd>These are rendered as the strings "true" or "false".  Any other value MUST be
                        treated as an erroneous response.  Relying parties MUST accept these as case-insensitive
                        values; i.e. "true", "TRUE", "True" are equivalent.</dd>
                        <dt>time</dt>
                        <dd>All times MUST be represented according to <a href="#reference-rfc3339">[RFC
                                3339]</a> ("Date and Time on the Internet: Timestamps"), which is a refinement of
                        international date-time notation standard ISO 8601 on the Gregorian calendar, with the
                        following restrictions:
                                <ul>
                                        <li>All times must be in the UTC timezone, indicated with a "Z".</li>
                                        <li>No fractional seconds are allowed.</li>
                                </ul>
                        </dd>
                        <dt>dn</dt>
                        <dd>Distinguished-names MUST be represented according to <a
                                href="#reference-rfc4514">[RFC 4514]</a> ("Lightweight Directory Access Protocol (LDAP):
                        String Representation of Distinguished Names").</dd>
                </dl>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-2'>2. Defined Authentication Policies</h3>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-2.1'>2.1. Scope of this Document</h3>

                <p>This document covers four areas which relate to the assurance of an authentication
                against the OpenID provider.  Three of these areas govern the actual authentication
                process and method: PKI, OTP, and password.  An additional category governs the channel
                security used in the connection which established the authenticated session.  For PKI,
                OTP, and channel security, the actual parameters of the session are the ones acted upon by
                the provider in terms of response values.  Password is the exception to this rule, where
                to prevent possible leaking of important information, these response parameters are based
                on the provider's policy rather than the user's actual password.</p>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-2.2'>2.2. Supporting Use Cases</h3>

                <p>While OpenID provides very convenient capabilities for authenticating users via a
                universal identifier, it does not entirely address the safety of the initial
                authentication performed by the OpenID provider.  With existing systems, there is some
                danger from phishing: users of password-based providers can fall victim to having their
                passwords stolen and their accounts compromised.  PAPE-AM attempts to address this by
                providing information about the authentication method to the OpenID provider such that
                relying parties can determine if such methods are sufficient to ensure that the
                authenticated user is truly the owner of the account.  PAPE-AM provides this information in
                varying degrees so that relying parties may choose the level of required security.</p>

                <p>See <a href="#section-5">Section 5</a> for examples of how to implement each of these
                Use Cases using PAPE-AM.</p>

                <ul>
                        <li>Online banking website that supports government-issued ID smart cards

                        <p>Consider an online banking website that has adopted support for OpenID, but wishes to
                        restrict access to users who have been issued a citizen ID smart card by government
                        authorities that the bank trusts. In this case, the online banking website would use PAPE-AM to
                        ensure hardware-based PKI authentication was used with the OP. The banking website would also
                        use PAPE-AM to get information about who issued the user's digital certificate.</p>

                        <p>These additional request/response parameters provided by PAPE-AM help ensure that the bank's
                        users will not fall victim to hijacking attempts since client authentication using PKI with a
                        hardware-based token was used. The information about the issuer of the certificate could help
                        the bank prove the real-life identity of the user, also.</p></li>

                        <li>Blog publishing website that requires a strong password

                        <p>A blog publishing website supports OpenID as a RP, but wants to make sure that its users
                        are using a strong password with their OP. PAPE-AM gives Relying Parties the ability to specify
                        a minimum length for a password and minimum number unique characters that should be used.</p>

                        <p>By requesting a minimum password length and the minimum number of unique characters allowed
                        in the password, the blog publishing website can be assured that it's users accounts are
                        reasonably protected from being compromised.</p></li>

                        <li>Online Brokerage Supports OTP

                        <p>An online brokerage supports OpenID as a RP. However, when enabling users to authenticate
                        via third-party OpenID Providers, they want to make sure that the user is using a hardware OTP
                        token where the length of the OTP is at least 8. The RP can request additional PAPE-AM
                        attributes during the OpenID exchange and thereby can be assured that the user and the OpenID
                        provider meet the requirements.</p></li>
                </ul>


                <p>For examples of how these use cases would be implemented with PAPE-AM, please see
                Section 5.</p>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-3'>3. Authentication Protocol</h3>
                <p>The following section lists the Request and Response Parameters that can be used by the Relying
                Party and OpenID Provider during an OpenID Authentication Request.</p>
                <p>Note that the authors have deliberately minimized the number of request parameters in order to
                simplify the processing for the OpenID Providers. This approach is to be consistent with the
                OpenID philosophy today.</p>
                <p>Also in order to minimize the size of the responses, we provide means for Relying Parties to
                specify what information they would like to receive in the response from the OpenID Provider.</p>
                <p>The Relying Parties can then verify if the response values satisfy their security and policy
                requirements.</p>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-3.1'>3.1. Request Parameters</h3>
                <p>The following parameters MAY be included during an OpenID Authentication
                Request by the Relying Party.</p>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-3.1.1'>3.1.1. General</h3>

                <ul>
                        <li>openid.pape.method

                        <p>A space-separated list of acceptable Authentication Methods.  Elements MUST be
                        members of the following set:
                        {<tt>password</tt>, <tt>otp</tt>, <tt>pki</tt>, <tt>biometric</tt>, <tt>any</tt>}.
                        This list MUST NOT be empty, and the phrase "<tt>any</tt>" MUST NOT appear with
                        any other element.</p>

                        <p>Examples:</p>
                        <ul>
                                <li>"<tt>password otp pki</tt>"
                                <p>OpenID provider MUST use either a password, an OTP device, or some kind of
                                PKI to authenticate the user.</p></li>

                                <li>"<tt>any</tt>"
                                <p>OpenID provider may use any method to authenticate the user.</p></li>
                        </ul>

                        <p>Invalid Example:</p>
                        <ul>
                                <li>"<tt>any pki</tt>"
                                <p>The relying party MUST NOT specify the phrase "<tt>any</tt>" with any other
                                element.  While this makes logical sense (though it it unnecessary to specify
                                "<tt>pki</tt>" given "<tt>any</tt>"), this is disallowed to prevent
                                confusion.</p></li>
                        </ul>
                        </li>
                </ul>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-3.1.2'>3.1.2. Password</h3>

                <ul>
                        <li>openid.pape.password.info
                        <p>A space-separated list of what kinds of information user
                        password policy that MUST be returned in the response.
                        Elements MUST be members of the set: {<tt>length</tt>,
                        <tt>change_time</tt>, <tt>recycle_period</tt>, <tt>variety</tt>}. If
                        not provided, the OP is under no obligation to return any
                        such information.</p>

                        <ul>
                                <li><tt>length</tt>
                                <p>Minimum length of the password.</p>
                                </li>
                                <li><tt>change_time</tt>
                                <p>Maximum time before user is forced to change password.</p>
                                </li>
                                <li><tt>recycle_period</tt>
                                <p>Number of cycles before user can reuse password.</p>
                                </li>
                                <li><tt>variety</tt>
                                <p>Number of different 'characters' required in password.  Here, a 'characters' are
                                differentiated by the merit of having different Unicode codepoints.</p>
                                </li>
                        </ul>
                        </li>
                </ul>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-3.1.3'>3.1.3. PKI</h3>

                <ul>
                        <li>openid.pape.pki.key.storage
                        <p>A space-separated list of acceptable PKI "types" - elements MUST be members of the following
                        set: {<tt>software</tt>, <tt>hardware</tt>}.  If not provided, it is the same as providing
                        "<tt>software</tt> <tt>hardware</tt>".</p>

                        <p><b>Example:</b></p>
                        <ul>
                                <li>"<tt>software hardware</tt>"
                                <p>Users may authenticate to the OpenID provider using either a hardware-based
                                or a software-based keystore.</p>
                                </li>
                        </ul>
                        </li>
                        <li>openid.pape.pki.key.info
                        <p>A space-separated list of what kinds of information about the key in use MUST be
                        returned in the response.  Elements MUST be members of the set:
                        {<tt>storage</tt>, <tt>algorithm</tt>, <tt>policy</tt>,
                        <tt>consent</tt>}. If not provided, the OP is under no obligation to return any such information.</p>
                        <ul>
                                <li><tt>storage</tt>
                                <p>Whether the key was based in hardware or software.</p>
                                </li>
                                <li><tt>algorithm</tt>
                                <p>The type and strength of the algorithm used.</p>
                                </li>
                                <li><tt>policy</tt>
                                <p>Private key policy indicators.</p>
                                </li>
                                <li><tt>consent</tt>
                                <p>Method(s) of user consent used at authentication time.</p>
                                </li>
                        </ul>

                        <p><b>Examples:</b></p>
                        <ul>
                                <li>"<tt>storage policy consent</tt>"
                                <p>OP SHOULD respond with three parameters for the PKI key - type of storage,
                                policy and consent.</p>
                                </li>
                        </ul>
                        </li>

                        <li>openid.pape.pki.cert.revocation_check
                        <p>A boolean indicating whether or not a revocation check MUST be performed
                        by the OpenID provider.  If unspecified, this parameter by default is
                        considered to be "<tt>false</tt>", i.e. no check is required.  Here, a revocation
                        check includes checking the entire certificate path.</p>
                        </li>

                        <li>openid.pape.pki.cert.info
                        <p>A space-separated list of what kinds of information about the certificate MUST
                        be returned in the response.  Elements MUST be members of the set:
                        {<tt>issuer_dn</tt>, <tt>subject_dn</tt>, <tt>policy</tt>, <tt>time</tt>, <tt>certificate</tt>}.
                        If not provided, the OP is under no obligation to return any such
                        information.</p>
                        <ul>
                                <li><tt>issuer_dn</tt>
                                <p>The name of the party that issued the certificate. This MUST be formatted according
                                to <a href="#reference-rfc4514">[RFC 4514]</a>.</p>
                                </li>
                                <li><tt>subject_dn</tt>
                                <p>The subject field of the certificate.</p>
                                </li>
                                <li><tt>policy</tt>
                                <p>URI for the issuer's Certificate Policy.</p>
                                </li>
                                <li><tt>not_before</tt>
                                <p>Time before which the certificate is invalid.  See <a href="#section-1.3">Section 1.3</a>
                                for more information on proper formatting of time types.</p>
                                </li>
                                <li><tt>not_after</tt>
                                <p>Time after which the certificate is invalid.  See <a href="#section-1.3">Section 1.3</a>
                                for more information on proper formatting of time types.</p>
                                </li>
                                <li><tt>certificate</tt>
                                <p>The user's digital certificate used to authenticate to the OP. The certificate
                                should be formatted as a valid PEM encoded X.509 certificate. See <a
                                        href="#reference-rfc3280">[RFC3280]</a> for specifications of the X.509
                                certificate, and <a href="#reference-rfc1421">[RFC1421]</a> for specifications of
                                PEM encoding.</p>
                                </li>
                        </ul>

                        <p><b>Example:</b></p>
                        <ul>
                                <li>"<tt>issuer_dn not_before not_after</tt>"
                                <p>Request the certificate issuer distinguished name, and the invalid before and invalid
                                after times of the certificate.</p></li>
                        </ul>
                        </li>
                </ul>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-3.1.4'>3.1.4. OTP</h3>

                <ul>
                        <li>openid.pape.otp.info
                        <p>A space-separated list of attribute names about the OTP credential that was used to
                        authenticate the user. The value of the requested attributes MUST be returned in the
                        response. Elements MUST be members of the following set: {<tt>mode</tt>,
                        <tt>token_type</tt>, <tt>consent</tt>, <tt>length</tt>, <tt>encoding</tt>,
                        <tt>algorithm</tt>}. If not provided, the OP is under no obligation to return any such
                        information.</p>

                        <ul>
                                <li><tt>mode</tt>
                                <p>OTP mode that was used.</p>
                                </li>
                                <li><tt>token_type</tt>
                                <p>Type of token that was used by the user.</p>
                                </li>
                                <li><tt>consent</tt>
                                <p>Consent method which was used before generating OTP value.</p>
                                </li>
                                <li><tt>length</tt>
                                <p>Length of the OTP value.</p>
                                </li>
                                <li><tt>encoding</tt>
                                <p>Encoding of the OTP value.</p>
                                </li>
                                <li><tt>algorithm</tt>
                                <p>The OTP algorithm that was used.</p>
                                </li>
                        </ul>

                        <p><b>Example:</b></p>
                        <ul>
                                <li>"<tt>token_type length encoding</tt>"
                                <p>OP MUST respond with three parameters for the OTP: token-type, length, and encoding.</p>
                                </li>
                        </ul>
                        </li>
                </ul>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-3.1.5'>3.1.5. Channel Security</h3>
                <ul>
                        <li>openid.pape.channel.info
                        <p>A space-separated list of attribute names about the channel used to transmit the user
                        authentication credential. The value of the requested attributes MUST be returned in the
                        response.  Elements MUST be members of the following set: {<tt>ssl_use</tt>,
                        <tt>algorithm</tt>, <tt>cert_validation</tt>, <tt>site_recognition</tt>}.</p>
                        <ul>
                                <li><tt>ssl_use</tt>
                                <p>Use of SSL in the transport protocol.</p>
                                </li>
                                <li><tt>algorithm</tt>
                                <p>The algorithms used for SSL handshake.</p>
                                </li>
                                <li><tt>certificate_validation</tt>
                                <p>The level of vetting before the server certificate was issued.</p>
                                </li>
                                <li><tt>site_recognition</tt>
                                <p>Use of site recognition in the provider's site for a user.</p>
                                </li>
                        </ul>
                        <p><b>Example:</b></p>
                        <ul>
                                <li>"<tt>ssl_use certificate_validation</tt>"
                                <p>OP MUST respond with parameters that indicate whether SSL was used and
                                what level of certificate vetting was used.</p>
                                </li>
                        </ul>
                        </li>
                </ul>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-3.1.6'>3.1.6. Provider Policy</h3>
                <ul>
                        <li>openid.pape.policy.info
                        <p>A space-separated list of attribute names about the OpenID provider's operational policy. The
                        value of the requested attributes MUST be returned in the response. Elements MUST be members
                        of the following set: {<tt>url</tt>}.</p>

                        <p><b>Example:</b></p>
                        <ul>
                                <li>"<tt>url</tt>"
                                <p>OP MUST respond with the URL for its Provider Policy Statement.</p>
                                </li>
                        </ul>
                        </li>
                </ul>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-3.2'>3.2. Response Parameters</h3>
                <p>In response to a Relying Party's request, the following parameters, if requested by the
                Relying Party, MUST be included in the OpenID Authentication Response. All response
                parameters MUST be included in the signature of the Authentication Response.</p>

                <p>Any phrase that appears in a response parameter MAY be set to "Nothing" (capitalization
                unimportant) to indicate that the value is unknown, unknowable, invalid, irrelevant, or
                simply that the OP refuses to reveal it (for privacy or other reasons).  Note that this does
                not necessarily mean that the RP will accept the authentication; in fact, extremely strict
                RPs MAY refuse any authentication which responds with a "Nothing" phrase.  The "Nothing"
                phrase MUST NOT appear in lists with any other phrase.</p>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-3.2.1'>3.2.1. General</h3>
                <p>It is RECOMMENDED that an OP supporting this extension include the parameters in the 'General'
                category even if they were not specifically requested by the Relying Party.</p>
                <ul>
                        <li>openid.pape.method
                        <p>A space-separated list of authentication methods that were used by the OpenID Provider to
                        authenticate the user.  Elements MUST be members of the following set: {
                        <tt>password</tt>, <tt>otp</tt>, <tt>pki</tt>, <tt>biometric</tt>}.  This list MUST NOT be empty.

                        <p><b>Examples:</b></p>
                        <ul>
                                <li>"<tt>password otp</tt>"
                                <p>OpenID provider used a combination of a password and an OTP device
                                to authenticate the user.</p>
                                </li>
                        </ul>
                        </li>
                </ul>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-3.2.2'>3.2.2. Password</h3>
                <p>Password parameters are meant to give information only on the OpenID provider's policies for
                using passwords, NOT FOR THE ACTUAL PASSWORD BEING USED.  While it would be nice to utilize
                measures like password entropy, when considering the possibility of multi-lingual character sets
                and the difficulties of measuring an accurate, objective, and universal qualitative assessment
                of password randomness, it becomes clear that such is simply too complex for this specification.</p>
                <p>All of these parameters are optional unless indicated in the <em>openid.pape.password.info</em> list.</p>
                <ul>
                        <li>openid.pape.password.length
                        <p>Integer giving the minimum length of a password; if the OpenID provider does not have a
                        policy that requires this length then the relying party may refuse to accept the
                        authentication.</p>
                        </li>
                        <li>openid.pape.password.change_time
                        <p>Integer giving the maximum length of time in days that the password can go before it must be
                        changed.  Whether or not the provider is in compliance depends on the provider's policy.</p>
                        </li>
                        <li>openid.pape.password.recycle_period
                        <p>Integer giving the minimum amount of "cycles" that a user must select a new password for
                        before they are allowed to reuse old passwords; or the special string "inf" to indicate that
                        passwords may never be recycled.  A value of "0" means that the provider should not allow
                        users to reuse their passwords.  Note: this is the only parameter where the type of the
                        response is variable (integer or string).</p>
                        </li>
                        <li>openid.pape.password.variety
                        <p>Indicates the minimum number of different characters in the password.  Here,
                        characters are differentiated by the merit of having different Unicode codepoints.
                        (Thus, when a combining character is added to a "normal" character there are at least
                        two distinct characters in use.) OpenID providers may translate their own policy into
                        similar terms, for example, requiring both upper and lower case plus numerics means at
                        minimum three different characters.</p>
                        </li>
                </ul>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-3.2.3'>3.2.3. PKI</h3>
                <p>All of these parameters are optional unless indicated in the openid.pape.pki.key.info or
                openid.pape.pki.cert.info lists.</p>

                <ul>
                        <li>openid.pape.pki.key.storage
                        <p>A string indicating what type of PKI credential was used.  MUST include
                        one member of the set of allowed possibilities in the corresponding
                        request object (i.e. "<tt>software</tt>" OR "<tt>hardware</tt>").  A response with both phrases is erroneous.</p>
                        </li>
                        <li>openid.pape.pki.key.algorithm
                        <p>Space-separated list of algorithm URIs (see <a href="#appendix-a">Appendix A</a>)
                        describing the algorithm that was used.</p>
                        </li>
                        <li>openid.pape.pki.key.policy
                        <p>A space-separated list of policies in place for the private key.
                        Elements MUST be members of the set: {<tt>escrowed</tt>, <tt>exportable</tt>, <tt>roaming</tt>},
                        and ALL members of this set MUST be present.  Elements MUST be preceded
                        by a tilde "<tt>~</tt>" when indicating that policy is not in effect.</p>

                        <p><b>Example:</b></p>
                        <ul>
                                <li>"<tt>escrowed ~exportable roaming</tt>"
                                <p>The key is escrowed, is allowed to move from one physical
                                machine to another, but is not exportable (e.g. a hardware
                                token).</p>
                                </li>
                                <li>"<tt>~escrowed ~exportable roaming</tt>"
                                <p>The key is not escrowed, but is allowed to move from one
                                physical machine to another and is not exportable.</p>
                                </li>
                        </ul>

                        <p><b>Invalid Example:</b></p>
                        <ul>
                                <li>"<tt>exportable</tt>"
                                <p>The status of all policies MUST be indicated.</p>
                                </li>
                        </ul>
                        </li>

                        <li>openid.pape.pki.key.consent
                        <p>Space-separated list of strings indicating the type of consent used to unlock the
                        private key.  Each phrase describes one of a set of simultaneous consent methods, and
                        MUST be a member of the set {<tt>passphrase</tt>,
                        <tt>biometric</tt>, <tt>visual</tt>}.</p>
                        <ul>
                                <li><tt>passphrase</tt>
                                <p>The user supplied a password; the precise mechanism of which (e.g. through a keyboard or through a
                                separate device) is deliberately omitted from this specification.</p>
                                </li>
                                <li><tt>biometric</tt>
                                <p>A fingerprint, voiceprint, retina scan, or other biological identifier was used.</p>
                                </li>
                                <li><tt>visual</tt>
                                <p>Other methods such as grid cards, image matching, and CAPTCHAs fall into this category.</p>
                                </li>
                        </ul>

                        <p><b>Example:</b></p>
                        <ul>
                                <li>"<tt>passphrase visual</tt>"
                                <p>The user combined a passphrase with a visual confirmation (e.g. a
                                grid card or image match) to do the authentication.</p>
                                </li>
                        </ul>

                        </li>

                        <li><p>openid.pape.pki.cert.revocation_check</p>
                        <p>Boolean indicating if the OpenID provider did a revocation check on the
                        user's certificate, including the entire path to the Certificate Authority.</p>
                        </li>
                        <li><p>openid.pape.pki.cert.issuer_dn</p>
                        <p>The name of the entity which issued the certificate used, expressed as a distinguished name.
                        See <a href="#section-1.3">Section 1.3</a> for an explanation on the precise format.</p>
                        </li>
                        <li><p>openid.pape.pki.cert.subject_dn</p>
                        <p>Content of the subject field of the certificate, expressed as a distinguished name.
                        See <a href="#section-1.3">Section 1.3</a> for an explanation on the precise format.</p>
                        </li>
                        <li><p>openid.pape.pki.cert.policy</p>
                        <p>String giving the URI for the certificate policy.</p>
                        </li>
                        <li><p>openid.pape.pki.cert.not_after</p>
                        <p>The time at which the certificate will become invalid; the certificate is valid before and at this
                        time.  See <a href="#section-1.3">Section 1.3</a> for an explanation on the precise
                        format.</p>
                        </li>
                        <li><p>openid.pape.pki.cert.not_before</p>
                        <p>The time before which the certificate is invalid; the certificate is only valid at and after this
                        time.  See <a href="#section-1.3">Section 1.3</a> for an explanation on the precise
                        format.</p>
                        </li>
                        <li><p>openid.pape.pki.cert.certificate</p>
                        <p>The complete PEM-encoded certificate.</p>
                        </li>
                </ul>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-3.2.4'>3.2.4. OTP</h3>

                <p>All of these parameters are optional unless indicated in the
                openid.pape.otp.info list.</p>
                <ul>
                        <li>openid.pape.otp.mode
                        <p>A string indicating the mode that was used to authenticate the user.
                        The value MUST be one of the following set:
                        {<tt>response-only</tt>, <tt>challenge-response</tt>}.</p>
                        </li>
                        <li>openid.pape.otp.tokentype
                        <p>A string indicating the type of OTP token that was used by the user.  The value MUST be one
                        of the following set: {<tt>unknown</tt>, <tt>software</tt>, <tt>hardware-unconnected</tt>,
                        <tt>hardware-connected</tt>, <tt>server-generated</tt>}.</p>
                        </li>
                        <li>openid.pape.otp.consent
                        <p>Space-separated list of strings indicating the type of consent used to unlock the
                        private key.  Each phrase describes one of a set of simultaneous consent methods, and
                        MUST be a member of the set {<tt>passphrase</tt>,
                        <tt>biometric</tt>, <tt>visual</tt>}.</p>
                        <ul>
                                <li><tt>passphrase</tt>
                                <p>The user supplied a password; the precise mechanism of which (e.g. through a keyboard or through a
                                separate device) is deliberately omitted from this specification.</p>
                                </li>
                                <li><tt>biometric</tt>
                                <p>A fingerprint, voiceprint, retina scan, or other biological identifier was used.</p>
                                </li>
                                <li><tt>visual</tt>
                                <p>Other methods such as grid cards, image matching, and CAPTCHAs fall into this category.</p>
                                </li>
                        </ul>

                        <p><b>Example:</b></p>
                        <ul>
                                <li>"<tt>passphrase biometric</tt>"
                                <p>The user combined a biometric authentication in combination with a passphrase before the
                                OTP value was displayed to the user.</p>
                                </li>
                        </ul>

                        <li>openid.pape.otp.length
                        <p>A numeric value that indicates the length of the OTP that was used
                        to authenticate the user.</p>
                        <p>Example: 6, 8</p>
                        </li>

                        <li>openid.pape.otp.encoding
                        <p>A string value that indicates the encoding that was used to represent
                        the OTP value. The value MUST be one of the following set:
                        {<tt>numeric</tt>, <tt>hexadecimal</tt>, <tt>alphanumeric</tt>}.</p>
                        </li>

                        <li>openid.pape.otp.algorithm
                        <p>A string indicating the algorithm that was used to generate the OTP
                        value. Algorithm values are represented by URIs (see <a href="#appendix-a">Appendix A</a>).</p>
                        </li>
                </ul>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-3.2.5'>3.2.5. Channel Security</h3>
                <p>All of these parameters are optional unless indicated in the
                openid.pape.channel.info list.</p>

                <ul>
                        <li>openid.pape.channel.ssl_use
                        <p>Boolean which indicates whether SSL is used to secure the channel to access the service
                        provider.</p>
                        </li>

                        <li>openid.pape.channel.algorithm
                        <p>A space-separated list of algorithm URIs.  See <a href="#appendix-a">Appendix A</a> for
                        available URI.</p>
                        </li>

                        <li>openid.pape.channel.certificate_validation
                        <p>A string indicating the level of vetting before the server certificate
                        was issued. The value MUST be one of the following:</p>
                        <ul>
                                <li><tt>low</tt>
                                <p>Automatic instance issuance including self-signed.</p>
                                </li>
                                <li><tt>high</tt>
                                <p>Domain name and organization verification.</p>
                                </li>
                                <li><tt>ev</tt>
                                <p>Extended validation beyond those in high, e.g. the individual approver's employment with
                                the applicant, and authority to obtain the Extended Validation SSL Certificate.</p>
                                </li>
                        </ul>
                        </li>

                        <li>openid.pape.channel.site_recognition
                        <p>A string indicating how a provider's site is recognized by a user other than
                        SSL. Note that these methods could be used with or without SSL. The value MUST
                        be a member of the set {<tt>none</tt>, <tt>user</tt>, <tt>host</tt>}.</p>
                        <ul>
                                <li><tt>none</tt>
                                <p>No additional recognition method is provided.</p>
                                </li>
                                <li><tt>user</tt>
                                <p>A user-secret user interface was displayed for the site recognition.  A user will see the
                                same secret UI from all machines.</p>
                                </li>
                                <li><tt>host</tt>
                                <p>A host-secret user interface was displayed for the site recognition.  All users from that
                                host will see the same secret UI.</p>
                                </li>
                        </ul>
                        </li>
                </ul>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-3.2.6'>3.2.6. Provider Policy</h3>

                <p>All of these parameters are optional unless indicated in the
                openid.pape.policy.info list.</p>
                <ul>
                        <li>openid.pape.policy.url
                        <p>A URI that contains the operation policy statement for the OpenID provider.
                        This is analogous to the Certification Policy statement for a Certificate
                        Authority.</p>
                        </li>
                </ul>


                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-4'>4. Security Considerations</h3>

                <p>This section outlines security considerations that were raised by the group developing this
                specification. Some of the considerations here may be addressed by later versions of this
                specification.</p>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-4.1'>4.1. Session-specific Information</h3>

                <p>It is important to note that any authentication information provided by an OpenID Identity
                Provider (OP) is only describing the authentication used during that current session. Other
                methods of authentication may have been used in prior sessions.</p>

                <p>When an OP uses more secure authentication methods by multiple factors than a RP requests, it
                doesn't have to report all the credential methods that it used. It can simply assert to the RP
                the method it requests. For example, a RP requests "password" authentication but an OP
                authenticates a user with both a password and a hardware token generated OTP, it may just report
                "password" for the response.</p>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-4.2'>4.2. NIST Assurance Levels</h3>

                <p>NIST Assurance Level about authentication method is a general guideline that OpenID Providers
                may use to fulfill the accepted Authentication Methods requested by a RP. If a RP supports weaker
                authentication method such as "password", an OP can proceed to authenticate a user if it
                supports PKI. The OP should send the actual authentication method that it used in the PAPE-AM
                authentication extension.</p>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-4.3'>4.3. PKI Authentication</h3>

                <p>When PKI authentication method is requested by a RP, it doesn't specify the strength of PKI
                credential to keep the protocol simple. An OP can enforce its own policy on acceptable PKI
                credential strength.  Note that it is still the prerogative of the relying party to refuse the
                assertion of the provider if the credential strength specified in the informational response
                parameter is not up to the requirements of the relying party.</p>

                <p>When a credential's revocation status check is requested by a RP, an OP may choose any
                revocation status check according to its policy. It should return the method it used in a
                response to a RP for further security enforcement. For example, an OP may use delayed
                Certificate Revocation List (CRL) instead of OCSP for certificate status check. A RP may launch
                its own optional OCSP check if it wants higher security than that provided by various response attributes
                from the OP about the certificate.</p>

                <p>In the <a href="#section-2.2">Online banking use case</a> and <a
                        href="#section-5.1">Client Authentication with PKI token</a> example, the RP receives
                the distinguished names for both the issuer of the user's certificate and the subject of the
                user's certificate. The value of the issuer_dn and subject_dn should only be trusted if the
                RP trusts the same root Certificate Authorities that the OP trusts. If the RP does not trust
                the same root CAs as the OP, then the values of these distinguished names could be spoofed.
                The RP and OP would need to have a out-of-band handshake to address this issue.</p>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-4.4'>4.4. Privacy</h3>

                <p>There may be privacy concerns when an OP tells a RP the user's credential type. An OP can
                choose to not send this information by replying the value "Nothing".</p>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='appendix-a'>Appendix A. URI Reference</h3>

                <p>The following locations will be used as URI for algorithm properties.</p>

                <p><b>OTP Algorithms</b></p>

                <p>These values are only allowed with regard to an OTP authentication; using them in the
                context of a PKI authentication is erroneous.</p>

                <ul>
                        <li>http://schemas.openid.net/pape/otp/hotp   &mdash; HMAC</li>
                        <li>http://schemas.openid.net/pape/otp/ocra-1 &mdash; OCRA-1</li>
                        <li>http://schemas.openid.net/pape/otp/totp   &mdash; TOTP</li>
                        <li>http://schemas.openid.net/pape/otp/aes    &mdash; AES</li>
                        <li>http://schemas.openid.net/pape/otp/aes128-counter &mdash; AES 128-bit Counter</li>
                        <li>http://schemas.openid.net/pape/otp/des    &mdash; DES</li>
                        <li>http://schemas.openid.net/pape/otp/3des   &mdash; Triple DES</li>
                </ul>

                <p><b>PKI Algorithms</b></p>

                <p>These values are only allowed with regard to a PKI authentication; using them in the
                context of an OTP authentication is erroneous.  Note that when using Elliptic Curve DSA, an
                additional URI indicating the curve in use must be specified to fully describe the
                algorithm.</p>

                <ul>
                        <li>http://schemas.openid.net/pape/pki/rsa/1024 &mdash; RSA 1024-bit</li>
                        <li>http://schemas.openid.net/pape/pki/rsa/2048 &mdash; RSA 2048-bit</li>
                        <li>http://schemas.openid.net/pape/pki/rsa/4096 &mdash; RSA 4096-bit</li>
                        <li>http://schemas.openid.net/pape/pki/ecdsa    &mdash; Elliptic Curve DSA</li>
                </ul>

                <p><b>NIST-recommended Elliptic Curves</b></p>

                <ul>
                        <li>http://schemas.openid.net/pape/pki/ecc/p192 &mdash; Prime Curve 192</li>
                        <li>http://schemas.openid.net/pape/pki/ecc/p224 &mdash; Prime Curve 224</li>
                        <li>http://schemas.openid.net/pape/pki/ecc/p256 &mdash; Prime Curve 256</li>
                        <li>http://schemas.openid.net/pape/pki/ecc/p384 &mdash; Prime Curve 384</li>
                        <li>http://schemas.openid.net/pape/pki/ecc/p521 &mdash; Prime Curve 521</li>
                        <li>http://schemas.openid.net/pape/pki/ecc/b163 &mdash; Binary Curve 163</li>
                        <li>http://schemas.openid.net/pape/pki/ecc/k163 &mdash; Koblitz Curve 163</li>
                        <li>http://schemas.openid.net/pape/pki/ecc/b233 &mdash; Binary Curve 233</li>
                        <li>http://schemas.openid.net/pape/pki/ecc/k233 &mdash; Koblitz Curve 233</li>
                        <li>http://schemas.openid.net/pape/pki/ecc/b283 &mdash; Binary Curve 283</li>
                        <li>http://schemas.openid.net/pape/pki/ecc/k283 &mdash; Koblitz Curve 283</li>
                        <li>http://schemas.openid.net/pape/pki/ecc/b409 &mdash; Binary Curve 409</li>
                        <li>http://schemas.openid.net/pape/pki/ecc/k409 &mdash; Koblitz Curve 409</li>
                        <li>http://schemas.openid.net/pape/pki/ecc/b571 &mdash; Binary Curve 571</li>
                        <li>http://schemas.openid.net/pape/pki/ecc/k571 &mdash; Koblitz Curve 571</li>
                </ul>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-5'>5. Examples</h3>
                <p>These three examples show how PAPE-AM can be used to give a Relying Party more information
                about how a user authenticated to his or her OpenID Provider. Each example corresponds to
                a use case in <a href="#section-2.2">Section 2.2</a>.</p>
                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-5.1'>5.1. Client Authentication with PKI token</h3>

                <p>In this example, an online bank requires that users authenticate to the OP using a
                hardware-based PKI token. The bank also requests the OP to:</p>
                <ul>
                        <li>request a passphrase from the user</li>
                        <li>perform revocation checking on the user's digital certificate</li>
                        <li>return information about the user's digital key: storage type, algorithm, and policies
                        enforced</li>
                        <li>return information about the user's digital certificate: Issuer's distinguished name,
                        Subject's distinguished name, and the validity period of the certificate</li>
                </ul>
                <p>After receiving the response from the OP, the online bank verifies that the responses are in
                compliance with its requirements and that the user's certificate was issued by an entity that
                it trusts. If all responses are acceptable, the user is permitted to access the banking
                website.</p>

                <p><em>See the <a href="#section-4.3">Security Considerations: PKI Authentication</a> section 
                for additional actions necessary for the banking website (RP) to trust the OP in this 
                example.</em></p>

                <p>Request:</p>

                <pre>
openid.pape.method =&gt; pki
openid.pape.pki.key.storage =&gt; hardware
openid.pape.pki.cert.revocation_check =&gt; true
openid.pape.pki.key.info =&gt; storage algorithm policy issuer_dn subject_dn not_before not_after</pre>

                <p>Response:</p>

                <pre>
openid.pape.method =&gt; pki
openid.pape.method.consent =&gt; passphrase
openid.pape.pki.key.storage =&gt; hardware
openid.pape.pki.key.algorithm =&gt; RSA_2048
openid.pape.pki.key.policy =&gt; ~escrowed ~exportable roaming
openid.pape.pki.cert.issuer_dn =&gt; C=US, O=U.S. Government, OU=Federal, OU=PKI, CN=FEDERAL IDENTITY CA-20
openid.pape.pki.cert.subject_dn =&gt; CN=Brian Kelly
openid.pape.pki.cert.not_before =&gt; 1985-04-12T23:20:50Z
openid.pape.pki.cert.not_after =&gt; 1990-12-31T23:59:60Z</pre>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>

                <h3 id='section-5.2'>5.2 Enforcing Password Strength</h3>

                <p>A blog publishing website (the RP) wants to be sure that its users are authenticating to
                their OpenID Identity Provider using a reasonably-strong password. PAPE-AM provides several
                password policy information request parameters that an RP can pass to an OP during an
                authentication request.</p>

                <p>In this use case, the RP only wants to accept users from OPs that enforce their users to have:</p>

                <ul>
                        <li>a minimum password length of 8</li>
                        <li>at least 6 unique characters in their password</li>
                        <li>passwords changed at least once a year</li>
                </ul>

                <p>To accomplish this, the RP would send the following request
                parameters to the OP when requesting an authentication:</p>

                <pre>
openid.pape.password.length =&gt; 8
openid.pape.password.variety =&gt; 6
openid.pape.password.change_time =&gt; 365</pre>

                <p>At this point the RP would decide if these responses are acceptable, and if so allow the
                user to access their blog account.</p>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-5.3'>5.3. One Time Password</h3>

                <p>Relying party (brokerage) has enabled users to authenticate using third-party OpenID providers.
                However they want users to authenticate using an OTP token where OTP values are at least 8
                characters long. The brokerage also wants to make sure that the OpenID provider used SSL when
                interacting with the user.</p>

                <p>Request:</p>

                <pre>
openid.pape.method =&gt; otp
openid.pape.otp.info =&gt; token_type length encoding algorithm
openid.pape.channel.info =&gt; ssl certificate_validation</pre>

                <p>Response:</p>

                <pre>
openid.pape.method =&gt; otp
openid.pape.otp.tokentype =&gt; hardware_unconnected
openid.pape.otp.length =&gt; 8
openid.pape.otp.encoding =&gt; numeric
openid.pape.otp.algorithm =&gt; &lt;url for HOTP&gt;
openid.pape.channel.ssl =&gt; true
openid.pape.channel.ssl.certificate_validation =&gt; ev</pre>

                <p>The relying party can confirm that OTP token was used by the user to authenticate to the
                and length of OTP was 8 numeric digits. Also the provider was using Extended Validation
                SSL.</p>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-6'>6. Acknowledgments</h3>
                <p> The authors would like to acknowledge Initiative for Open AuTHentication (OATH). 
                OATH is an industry wide collaboration that is working together with other 
                standards groups to enable and promote the use of strong authentication, enabling eBusiness 
                and giving consumers the confidence to conduct secure commerce online. </p>

                <p>The authors would like to thank the following individuals for their comments and
                suggestions to improve this draft document.</p>

                <p>
                Dr. David M'Raihi (VeriSign)<br/>
                Gary Krall (VeriSign)<br/>
                Johan Rydel<br/>
                Mike Rudolph (Wells Fargo)<br/>
                Philip Hoyer (ActivIdentity)<br/>
                Terry Davis (Clareity Security)<br/>
                Thomas Harning (TrustBearer Labs)
                </p>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-7'>7. Normative References</h3>

                <table>
                        <tr>
                                <td class="author-text" id="reference-hotp">[HOTP]</td>
                                <td class="author-text">M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and Ranen, O. "HOTP: An HMAC-Based One-Time Password Algorithm".  <a href="http://tools.ietf.org/rfc/rfc4226.txt">http://tools.ietf.org/rfc/rfc4226.txt</a></td>
                        </tr>
                        <tr>
                                <td class="author-text" id="reference-totp">[TOTP]</td>
                                <td class="author-text">M'Raihi, D., Machani, S., Pei, M., and Rydell, J. "TOTP: Time-based One-time Password Algorithm".  <a href="http://www.ietf.org/internet-drafts/draft-mraihi-totp-timebased-00.txt">http://www.ietf.org/internet-drafts/draft-mraihi-totp-timebased-00.txt</a></td>
                        </tr>
                        <tr>
                                <td class="author-text" id="reference-ocra">[OCRA]</td>
                                <td class="author-text">M'Raihi, D., Rydell, J., Naccache, D., Machani, S., and Bajaj, S. "OCRA: OATH Challenge-Response Algorithms".  <a href="http://tools.ietf.org/id/draft-mraihi-mutual-oath-hotp-variants-07.txt">http://tools.ietf.org/id/draft-mraihi-mutual-oath-hotp-variants-07.txt</a></td>
                        </tr>
                        <tr>
                                <td class="author-text" id="reference-pape">[PAPE]</td>
                                <td class="author-text">Recordon, D.  "OpenID Provider Authentication Policy Extension 1.0 (Draft 2)".  <a href="http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html">http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html</a></td>
                        </tr>
                        <tr>
                                <td class="author-text" id="reference-pskc">[PSKC]</td>
                                <td class="author-text">Hoyer, P., Pei, M., and Machani, S. "Portable Symmetric Key Container".  <a href="http://www.ietf.org/internet-drafts/draft-ietf-keyprov-portable-symmetric-key-container-05.txt">http://www.ietf.org/internet-drafts/draft-ietf-keyprov-portable-symmetric-key-container-05.txt</a></td>
                        </tr>
                        <tr>
                                <td class="author-text">[NIST_SP800-63]</td>
                                <td class="author-text">Burr, W., Dodson, D., and W. Polk, Ed., "Electronic Authentication Guideline," April 2006.</td>
                        </tr>
                        <tr>
                                <td class="author-text" id="reference-openid2.0">[OpenID2.0]</td>
                                <td class="author-text"><a href="mailto:specs@openid.net">specs@openid.net</a>, "OpenID Authentication 2.0".  <a href="http://openid.net/specs/openid-authentication-2_0.html">http://openid.net/specs/openid-authentication-2_0.html</a></td>
                        </tr>
                        <tr>
                                <td class="author-text" id="reference-rfc1421">[RFC 1421]</td>
                                <td class="author-text">Linn, J.  "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures".  <a href="http://www.ietf.org/rfc/rfc1421.txt">http://www.ietf.org/rfc/rfc1421.txt</a></td>
                        </tr>
                        <tr>
                                <td class="author-text" id="reference-rfc2119">[RFC 2119]</td>
                                <td class="author-text">Bradner, S.  "Key words for use in RFCs to Indicate Requirement Levels".  <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a></td>
                        </tr>
                        <tr>
                                <td class="author-text" id="reference-rfc3280">[RFC 3280]</td>
                                <td class="author-text">Housley, R. et al.  "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".  <a href="http://www.ietf.org/rfc/rfc3280.txt">http://www.ietf.org/rfc/rfc3280.txt</a></td>
                        </tr>
                        <tr>
                                <td class="author-text" id="reference-rfc3339">[RFC 3339]</td>
                                <td class="author-text">Klyne, G. and Newman, C.  "Date and Time on the Internet: Timestamps".  <a href="http://www.ietf.org/rfc/rfc3339.txt">http://www.ietf.org/rfc/rfc3339.txt</a></td>
                        </tr>
                        <tr>
                                <td class="author-text" id="reference-rfc4051">[RFC 4051]</td>
                                <td class="author-text">Eastlake, D. "Additional XML Security Uniform Resource Identifiers (URIs)".  <a href="http://tools.ietf.org/rfc/rfc4051.txt">http://tools.ietf.org/rfc/rfc4051.txt</a></td>
                        </tr>
                        <tr>
                                <td class="author-text" id="reference-rfc4514">[RFC 4514]</td>
                                <td class="author-text">Zeilenga, K.  "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names".  <a href="http://www.ietf.org/rfc/rfc4514.txt">http://www.ietf.org/rfc/rfc4514.txt</a></td>
                        </tr>
                        <tr>
                                <td class="author-text" id="reference-tls">[TLS]</td>
                                <td class="author-text">Dierks, T. and Allen, C. "The TLS Protocol".  <a href="http://www.ietf.org/rfc/rfc2246.txt">http://www.ietf.org/rfc/rfc2246.txt</a></td>
                        </tr>
                </table>

                <hr/>
                <div class="toc-link"><a href="#toc">TOC</a></div>
                <h3 id='section-8'>8. Authors' Addresses</h3>
                <table>
                        <tr><td class="author">&nbsp;</td><td class="author-text">Taylor Venable</td></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">TrustBearer Labs</td></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">226 West Wayne Street</td></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">Upper Suite</td></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">Fort Wayne, IN 46802</td></tr>
                        <tr><td class="author">Email:</td><td class="author-text"><a href="mailto:taylor.venable@trustbearer.com">taylor.venable@trustbearer.com</a></td></tr>
                        <tr><td class="author">URI:</td><td class="author-text"><a href="http://www.trustbearer.com">http://www.trustbearer.com</a></td></tr>
                        <tr style="height: 16px"></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">Siddharth Bajaj</td></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">VeriSign, Inc.</td></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">487 E. Middlefield Road</td></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">Mountain View, CA 94043</td></tr>
                        <tr><td class="author">Email:</td><td class="author-text"><a href="mailto:sbajaj@verisign.com">sbajaj@verisign.com</a></td></tr>
                        <tr><td class="author">URI:</td><td class="author-text"><a href="http://www.verisign.com">http://www.verisign.com</a></td></tr>
                        <tr style="height: 16px"></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">Brian Kelly</td></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">TrustBearer Labs</td></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">226 West Wayne Street</td></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">Upper Suite</td></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">Fort Wayne, IN 46802</td></tr>
                        <tr><td class="author">Email:</td><td class="author-text"><a href="mailto:brian.kelly@trustbearer.com">brian.kelly@trustbearer.com</a></td></tr>
                        <tr><td class="author">URI:</td><td class="author-text"><a href="http://www.trustbearer.com">http://www.trustbearer.com</a></td></tr>
                        <tr style="height: 16px"></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">MingLiang Pei</td></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">VeriSign, Inc.</td></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">487 E. Middlefield Road</td></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">Mountain View, CA 94043</td></tr>
                        <tr><td class="author">Email:</td><td class="author-text"><a href="mailto:mpei@verisign.com">mpei@verisign.com</a></td></tr>
                        <tr><td class="author">URI:</td><td class="author-text"><a href="http://www.verisign.com">http://www.verisign.com</a></td></tr>
                        <tr style="height: 16px"></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">Daniel Perry</td></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">4767 New Broad St, #1007</td></tr>
                        <tr><td class="author">&nbsp;</td><td class="author-text">Orlando, FL 32814</td></tr>
                        <tr><td class="author">Email:</td><td class="author-text"><a href="mailto:dan@danielperry.com">dan@danielperry.com</a></td></tr>

                </table>
        </body>
</html>
<!-- vim:set tw=100 ts=2 sw=2 indentexpr= : -->