The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

NEWS
Cover Stories
Articles & Papers
Press Releases

CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG

TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps

EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Created: October 22, 2008.
News: Cover StoriesPrevious News ItemNext News Item

Public Review for OpenID Provider Authentication Policy Extension (PAPE) 1.0.

Contents

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

As presented in the Final version of OpenID Authentication 2.0, "OpenID Authentication provides a way to prove that an end user controls an Identifier. It does this without the Relying Party needing access to end user credentials such as a password or to other sensitive information such as an email address... The authentication scheme plays nicely with "AJAX"-style setups. This means an end user can prove their Identity to a Relying Party without having to leave their current Web page. OpenID Authentication uses only standard HTTP(S) requests and responses, so it does not require any special capabilities of the User-Agent or other client software. OpenID is not tied to the use of cookies or any other specific mechanism of Relying Party or OpenID Provider session management. Extensions to User-Agents can simplify the end user interaction, though are not required to utilize the protocol..."

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

PAPE Draft 7: Bibliographic Information

OpenID Provider Authentication Policy Extension 1.0 - Draft 7. October 20, 2008. By David Recordon (Six Apart, Ltd), Michael B. Jones (Microsoft Corporation), Johnny Bufu (Specification Editor, Independent), Jonathan Daugherty (Specification Editor, JanRain), and Nat Sakimura (Nomura Research Institute, Ltd). Produced by members of the OpenID Provider Authentication Policy Extension (PAPE) Working Group.

Blogs, Commentary, Related Work

  • [October 22, 2008] PAPE Specification Entering Public Review Period. By Mike Jones. Blog. "The PAPE Working Group just recommended that the OpenID Foundation members approve the current draft (Draft 7) as an OpenID specification. Today starts a 60 day review period required as part of the OpenID specification process, which occurs prior to an approval vote by the members... There are already four implementations of this spec in existence and even better, there are public testing endpoints for these implementations where you can kick the tires. You can try the DotNetOpenId and JanRain implementations at these sites [...] You should also be able to test the relying parties with signon.com and myopenid.com, which currently implement earlier drafts, since the authentication policy syntax didn't change...

  • [October 06, 2008] Building on the OpenID PAPE specification. By Brian Kelly. Blog. "A few members of a related industry group, the Initiative for Open Authentication (OATH), got together and discussed the PAPE specification. Together we came to the conclusion that specific assertions about how a user authenticated to an OP were needed. This group is tentatively calling our suggested changes OpenID Provider Authentication Policy Extension - Authentication Mechanisms (PAPE-AM). Even though specific authentication methods change more often than the higher-level policies presented in PAPE, they are much more definitive..."

  • [October 12, 2008] Comments on OpenID2 PAPE proposal. Peter Williams. Blog. Comments (apparently) on draft version 5. "...I'm getting now into WG comments, rather than last call issues. So feel free to scorn me. 2.1 makes it clear that metadata SHALL be used to select OP based on their support for the RP's authentication "policies". Given the YADIS model (n different copies of the user's metadata exist as resources located at different URLs, only some of which may be under the formal security policy control of an OP), a user with n metadata files each with 1 authentication policy can be signaling his/her requirements/limits on a given RP. 2.1 implies that an RP may refuse, by local means, to proceed with OpenID Auth if the metadata contains authentication policies that do not intersect with the RP's requirements..."

PAPE Working Group

From the Proposal to create the PAPE Working Group (Mike Jones, May 22, 2008):

This message is being sent to revise the proposal to create the PAPE working group, changing only one word, so that the projected completion date is July 2008, rather than May 2008. The complete text of the revised proposal follows. — Mike Jones

In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are:

A. Proposal/Charter

(i) WG Name: Provider Authentication Policy Extension (PAPE)

(ii) Purpose: Produce a standard OpenID extension to the OpenID Authentication protocol that: 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 and 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 and/or multi-factor authentication method.

(iii) Scope: Produce a revision of the PAPE 1.0 Draft 2 specification that clarifies its intent, while maintaining compatibility for existing Draft 2 implementations. Adding any support for communicating requests for or the use of specific authentication methods (as opposed to authentication policies) is explicitly out of scope.

(iv) Proposed List of Specifications: Provider Authentication Policy Extension 1.0, spec completion expected during July 2008.

(v) Anticipated audience or users of the work: Implementers of OpenID Providers and Relying Parties — especially those interested in mitigating the phishing vulnerabilities of logging into OpenID providers with passwords.

(vi) Language in which the WG will conduct business: English.

(vii) Method of work: E-mail discussions on the working group mailing list, working group conference calls, and possibly a face-to-face meeting at the Internet Identity Workshop.

(viii) Basis for determining when the work of the WG is completed: Proposed changes to draft 2 will be evaluated on the basis of whether they increase or decrease consensus within the working group. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope.

B. Background Information

(i) Related work being done in other WGs or organizations: Assurance Levels as defined by the National Institute of Standards and Technology (NIST) in Special Publication 800-63 (Burr, W., Dodson, D., and W. Polk, Ed., Electronic Authentication Guideline, April 2006.) [NIST_SP800-63]. This working group is needed to enable authentication policy statements to be exchanged by OpenID endpoints. No coordination is needed with NIST, as the PAPE specification uses elements of the NIST specification in the intended fashion.

(ii) Proposers:

  • Michael B. Jones (Microsoft Corporation)
  • David Recordon (Six Apart Corporation)
  • Ben Laurie (Google Corporation)
  • Drummond Reed (Cordance Corporation)
  • John Bradley (Wingaa Corporation)
  • Johnny Bufu (Independent)
  • Dick Hardt (Sxip Identity Corporation)

Editors:

  • Michael B. Jones (Microsoft Corporation)
  • David Recordon (Six Apart Corporation)

(iii) Anticipated Contributions: None.

[Source posting]


Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Bottom Globe Image

Document URI: http://xml.coverpages.org/ni2008-10-22-a.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org