- PAPE Draft 7: Bibliographic Information
- Blogs, Commentary, Related Work
- PAPE Working Group
- Principal References
On behalf of members in the OpenID Provider Authentication Policy Extension (PAPE) Working Group, Mike Jones announced that the WG now recommends approval of PAPE Draft 7 as an OpenID Specification. The 60-day public review period extends through Sunday, December 21, 2008.
OpenID "eliminates the need for multiple usernames across different websites, simplifying your online experience. You get to choose the OpenID Provider that best meets your needs and most importantly that you trust. At the same time, your OpenID can stay with you, no matter which Provider you move to. And best of all, the OpenID technology is not proprietary and is completely free... OpenID is an open, decentralized, free framework for user-centric digital identity. OpenID takes advantage of already existing internet technology (URI, HTTP, SSL, Diffie-Hellman) and realizes that people are already creating identities for themselves whether it be at their blog, photostream, profile page, etc. With OpenID you can easily transform one of these existing URIs into an account which can be used at sites which support OpenID logins... OpenID is still in the adoption phase and is becoming more and more popular, as large organizations like AOL, Microsoft, Sun, Novell, etc. begin to accept and provide OpenIDs. Today it is estimated that there are over 160-million OpenID enabled URIs with nearly ten-thousand sites supporting OpenID logins..."
PAPE: The OpenID Provider Authentication Policy Extension (PAPE) specification, according to Jones, "enables an OpenID Relying Party to request that the OpenID Provider satisfy a set of policies specified by the RP when the OP logs the user in. And it likewise enables the OP to reply to the RP saying which of the policies it satisfied... One of these policies lets the RP request that the OP perform phishing-resistant authentication, the need for which has been discussed here and elsewhere. Another capability I'm a fan of is the ability for the RP to 'freshness date' the login, requiring that the OP actively authenticate the user if the current authentication was performed longer ago than an RP-specified number of seconds..."
PAPE overview from the specification 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..."
Background: Mike Jones explains that "This specification was a collaborative effort among a number of people. David Recordon wrote the initial drafts last year, with input from the people thanked in Draft 2. Since then, Nat Sakimura was responsible for the generalization of the authentication levels to enable levels other than just those defined by NIST be used. Ben Laurie was an ardent and practical security advocate (as always). Allen Tom was a proponent of the strong 'level 0' description. Andrew Arnott of the DotNetOpenId project shared his experiences building an independent implementation with the working group, helping improve the specification. And John Bradley was a never-ending source of common sense, although he would deny it to your face if asked..."
The public review for the PAPE 7 specification draft "is held in accordance with the OpenID Foundation IPR policies and procedures... Unless issues are identified during the review that the working group believes must be addressed by revising the draft, the review period will be followed by a seven day voting period during which OpenID Foundation members will vote on whether to approve this draft as an OpenID Specification..." Mike Jones reports that "PAPE is the first new specification to be produced under this OpenID process, and I'm pleased as an OpenID board member to report we now have an existence proof that the process works — or more precisely, we will once this specification is approved..."