Today OASIS announced the commencement of the 60-day public review period for the Identity Metasystem Interoperability Version 1.0 specification. This spec is based upon, and compatible with, the Identity Selector Interoperability Profile V1.5 (ISIP 1.5) specification and related Information Card documents submitted to the IMI TC. My sincere thanks to my fellow committee members for their diligence and promptness in reviewing and improving the specification drafts, enabling us to reach today’s milestone on a timely basis. Let the public review begin!
Category: Specifications
As I just announced on openid.net, OpenID Provider Authentication Policy Extension 1.0 (PAPE) has just been just been approved as an OpenID specification. Deployment of PAPE will go a long way towards mitigating the phishing vulnerabilities of password-based OpenIDs by enabling OpenID Relying Parties to request that OpenID Providers employ phishing-resistant authentication methods when authenticating users and for OpenID Providers to inform Relying Parties whether this (and other) authentication policies were satisfied.
It’s tempting to say that the approval of the specification is the fulfillment of the promise of the OpenID/CardSpace collaboration for phishing-resistant authentication introduced by Bill Gates and Craig Mundie the RSA Security Conference last year, but it’s really just an enabling step. The true value of PAPE will come when it is widely deployed by security-conscious OpenID Relying Parties, and the use of phishing-resistant authentication methods, such as Information Cards and others, is widespread and commonplace. Let the deployments begin!
The OpenID Provider Authentication Policy Extension (PAPE) specification 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.
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. PAPE is the first new specification to be produced under this 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).
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:
- http://nerdbank.org/pape.demo/
- http://openidenabled.com/php-openid/trunk/examples/consumer/ and http://openidenabled.com/php-openid/trunk/examples/server/server.php
- http://openidenabled.com/python-openid/trunk/examples/consumer/ and http://openidenabled.com/python-openid/trunk/examples/server/
- http://openidenabled.com/ruby-openid/trunk/examples/consumer/ and http://openidenabled.com/ruby-openid/trunk/examples/
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.
This spec 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.
I’m looking forward to participating in the new OASIS Identity Metasystem Interoperability Technical Committee (IMI TC) starting next week, which will produce an Information Card standard. As I told John Fontana of Network World earlier this week after the OASIS announcement of the IMI TC, this work is coming at a logical time.
The industry has been working together on building and testing interoperable Information Card software for the past two years through the OSIS Interops. The breadth of participation and the level of interop achieved between the participants are a testament to the maturity both of the Identity Selector Interoperability Profile specification, which will be a primary input to the standardization work, and of the numerous implementations of interoperable Information Card software. I’m also pleased that the features and tests from the most recent OSIS Interop will be one of the inputs informing the standardization work, enabling the committee to benefit from the experiences that implementers have gained by seeing how their software actually interoperates with others’ solutions.
As a personal note, I haven’t been involved in standards work since I was a technical editor of the POSIX Threads standard in the late ’80s and early ’90s (eventually published as PASC 1003.1c-1995 and ISO/IEC 9945-1:1996). I’ll be curious to see how the OASIS process is like and unlike the POSIX process from nearly two decades ago. Also on a personal level, I’ll say that the committee is a great collection of individuals, and I’m really looking forward to working with them to produce an identity standard of significant long-term value.
Also, be sure to see the comprehensive posting on Cover Pages about the IMI TC, which is chock full of useful information and references. Looking forward to seeing some of you in London!
IBM and Microsoft just published the specification “Application Note: Web Services Addressing Endpoint References and Identity” at http://schemas.xmlsoap.org/ws/2006/02/addressingidentity/. This specification is referenced by the Identity Selector Interoperability Profile (ISIP) and is covered by Microsoft’s Open Specification Promise (OSP). This completes the publication and licensing under the OSP of all specifications that Information Cards based upon the ISIP depend upon.
Note: While ISIP 1.5 references the addressing identity extension using a date of July 2008, it was actually published in August. This is an erratum in the ISIP that resulted from the publication of the extension taking longer than anticipated — not a reference to a different document. Both consistently use the URL http://schemas.xmlsoap.org/ws/2006/02/addressingidentity/.
I am pleased to announce the publication of the Identity Selector Interoperability Profile V1.5 and companion guides. The ISIP (as it’s come to be called) documents the protocols and data formats used by Windows CardSpace so as to enable others to build compatible Information Card software.
Version 1.0 of these documents corresponded to the.NET Framework 3.0 version of CardSpace. Version 1.5 corresponds to CardSpace as of .NET Framework 3.5 Service Pack 1. Like the previous version, ISIP 1.5 is licensed under Microsoft’s Open Specification Promise.
Significant new content covers:
- Relying Parties without SSL certificates
- Use of WS-Trust 1.3 and WS-SecurityPolicy 1.2
- Relying Party STSs
- More stable PPID algorithm
- Specifications for computing ic:IssuerId and ic:IssuerName
- Token references by Identity Providers via wst:RequestedAttachedReference and wst:RequestedUnattachedReference elements
- Custom issuer information in cards
- Custom error messages
- Clarification that an ic:MasterKey is required for managed cards
- Plus numerous of clarifications that were found by others building Information Card software — especially during the OSIS interops
The three new document versions are:
- Identity Selector Interoperability Profile V1.5 by Arun Nanda and yours truly, which provides normative specifications of the protocol elements and data interchange formats employed by CardSpace-compatible Identity Selectors and other interoperable Information Card components,
- An Implementer’s Guide to the Identity Selector Interoperability Profile V1.5, co-authored by Microsoft and Ping Identity, which provides informative advice and commentary on how to use the ISIP specifications when building interoperable Information Card software, and
- A Guide to Using the Identity Selector Interoperability Profile V1.5 within Web Applications and Browsers, also by yours truly, which provides informative advice and commentary on how these specifications are used by Web sites that accept Information Cards and by Web browsers when communicating with these sites.
Thanks to the literally dozens of you who provided comments on ways to improve the ISIP and companion docs and who reviewed drafts of this material. This version of the docs benefited substantially from your detailed knowledge of and experience with the previous spec gained through implementing interoperable Information Card software.
Finally, I’d like to thank the members of the CardSpace team who diligently documented many of these features on the CardSpace Team Blog in advance of their publication under the ISIP. Your work let the industry gain early experience with implementing these features and was a tremendous resource to me as I was producing these versions of the documents.
This morning at the Internet Identity Workshop, the OpenID Foundation announced that the OpenID 2.0 Specification and a set of related specifications are now complete. Furthermore, Intellectual Property Contribution Agreements have been executed by all the contributors to these specifications.
Here’s a camera-phone photo of Dick Hardt of Sxip Identity, Josh Hoyt of JanRain, and David Recordon of Six Apart making the announcement. Congratulations to the OpenID community on this significant accomplishment!
David Recordon just posted a simple draft OpenID specification enabling OpenID relying parties to request that a phishing-resistant authentication method be used by the OpenID provider and for providers to inform relying parties whether a phishing-resistant authentication method, such as Windows CardSpace, was used. This is a major step forward in fulfilling the promise of the JanRain/Microsoft/Sxip Identity/VeriSign OpenID/Windows CardSpace collaboration announcement introduced by Bill Gates and Craig Mundie at the RSA Security Conference this year.
In his post “Bringing Useful Scalable Security to OpenID” David wrote:
The integration cost of OpenID as a Relying Party is extremely low, the technology is free and as Brian Ellin and I showed at Web 2.0 Expo the time commitment is also low due to a lot of great Open Source code out there which takes care of the heavy lifting. So now the RP has successfully integrated OpenID and removed the need for new users to create yet another password for their site, though they no longer have the control over the strength of a user’s authentication process. The RP may be a simple Web 2.0 site and not care beyond that the user has a password, it may store marginally sensitive information and want to make sure that the Provider did something to help protect the user from common phishing attacks, or maybe it’s a site which has truly sensitive information and wants to make sure that a second-factor device, such as a VIP token, was used.
With the OpenID Provider Authentication Policy Extension that I just published, this is now possible. This extension to OpenID 1.1 and 2.0 allows Relying Parties to express preferences around the authentication, such as “use technology which is phishing resistant” (stemming from the collaboration announcement at the RSA conference earlier in the year), for the Provider to inform the user of the request, guide them through the authentication process, and then inform the Relying Party what happened. By taking advantage of existing specifications from the likes of the National Institute of Standards and Technology (NIST), Providers can also convey information as to the strength of a password or combination of a password and digital certificate or hardware device used. While the high-end of the specification may be beyond the uses of OpenID today, it certainly fulfills the scalable security vision that we have. Through this specification not only can I now strongly protect my OpenID identity, but let others know that I’m doing so and truly take advantage of a reduction in credentials needed when browsing the web.
I can’t wait to use the implementations that are sure to follow shortly!
New versions of three Information Card documents are now available:
- Identity Selector Interoperability Profile V1.0 by Arun Nanda, which provides normative specifications of the protocol elements and data interchange formats employed by Identity Selectors and other interoperable Information Card components,
- An Implementer’s Guide to the Identity Selector Interoperability Profile V1.0, co-authored by Microsoft and Ping Identity, which provides informative advice and commentary on how to use these specifications when building interoperable Information Card software, and
- A Guide to Using the Identity Selector Interoperability Profile V1.0 within Web Applications and Browsers by yours truly, which provides informative advice and commentary on how these specifications are used by Web sites that accept Information Cards and by Web browsers when communicating with these sites.
These documents are intended for people building software that plays any of the roles in the Information Card ecosystem: Identity Providers to issue cards, Relying Parties to accept cards, and Identity Selectors to put the person in control by enabling them to employ Information Cards when and where they choose. They include the specifications necessary to move Information Cards from one Identity Selector implementation to another, enabling card portability. And they’re also for those of you who just want to look under the hood and understand how it all works…
Along with these updated documents also comes updated licensing. We recently completed the technical and legal review of the normative specifications that enabled us to bring them under Microsoft’s Open Specification Promise. While this had been in the queue since the beginning, sometimes good things take time and come in stages. Once we had a complete, highly reviewed (and community reviewed) version of the interoperability specifications, that enabled us to complete this licensing work as well.
Thanks to all of you who reviewed earlier versions of these docs and especially those of you who built software based upon them. These documents greatly benefited from the substantial community feedback we received.
A footnote for those of you who have used earlier drafts of these documents… The “Identity Selector Interoperability Profile V1.0” was formerly known as “A Technical Reference to the Information Card Profile V1.0”; “An Implementer’s Guide to the Identity Selector Interoperability Profile V1.0” was formerly known as “A Guide to Interoperating with the Information Card Profile V1.0”; “A Guide to Using the Identity Selector Interoperability Profile V1.0 within Web Applications and Browsers” was formerly known as “A Guide to Supporting Information Cards within Web Applications and Browsers as of the Information Card Profile V1.0”.