The U-Prove technologies enable two key properties: minimal disclosure and unlinkability. For more about U-Prove and today’s Community Technology Preview (CTP) release, see the Microsoft U-Prove site, the post announcing the release, and Vittorio’s post (with links to videos).

While this is often said, this achievement is truly the result of a community effort. While by no means a comprehensive list, thanks are due to many, including the OSIS members whose diligent efforts ensured that Information Cards are interoperable across vendors and platforms, the Information Card Foundation members for their adoption and thought leadership work, and the IMI TC members, including co-chairs Marc Goodner and Tony Nadalin, and Mike McIntosh, who was my co-editor. Paul Trevithick and Mary Ruddy get enormous credit for starting and leading the Higgins Project, as does Dale Olds for the Bandit Project. Kaliya Hamlin and Phil Windley were instrumental behind the scenes by running the IIWs. Axel Nennker has been a tireless force, producing both ideas and software, as has Pamela Dingle. Jamie Lewis, Bob Blakley, and Craig Burton all provided insightful guidance on the practical aspects of birthing a new technology. Arun Nanda deserves enormous thanks for doing the heavy lifting to produce the ISIP 1.0 spec. And of course, none of this would have occurred without the leadership and vision of Kim Cameron. Thanks one and all!

Relying Parties often identify subjects using the Private Personal Identifier (PPID) claim and Signing Key values sent by an Information Card. Thus, it is important that the PPID and Signing Key values produced by a card be stable and long-lived.

Unfortunately, the PPIDs and Signing Keys generated by self-issued (a.k.a. personal) Information Cards using the algorithm originally shipped with Windows CardSpace (and documented in ISIP V1.0) for sites using regular certificates were not stable under several important conditions. Therefore, after considering industry feedback on the long-term problems that this continued instability would cause, and in consultation with other Identity Selector authors, a decision was made to change these algorithms in a way that will provide much better long-term stability of these important Subject identifiers for Relying Parties. The new algorithm is documented in the Identity Selector Interoperability Profile (ISIP) V1.5.

This change shipped with the version of Windows CardSpace in the .NET Framework 3.5 Service Pack 1. This service pack will be installed by Windows Update on systems with the .NET Framework 2.0, 3.0, and 3.5 in the coming months. I know that the Bandit and Higgins projects have implemented the new algorithm as well.

Unfortunately, this change means that the PPIDs and Signing Keys for self-issued cards used at existing Relying Parties that employ standard SSL certificates will change after this installation.

What Sites Need to Do

Sites need to ensure that they have tested mechanisms in place to enable their users to re-associate their Information Card with their account when the card’s PPID and Signing Key change. The good news is that these mechanisms are likely already in place in the form of “lost card” handling procedures.

When the card is used after the update, it will appear to be an unrecognized card. Just as sites’ lost card procedures can be used today to associate a new Information Card with their account, these same procedures can be used to re-associate the existing card with the account after these changes.

These lost card procedures will typically involve sending the user a message at the e-mail address of record for the account. This message contains a link that enables them to associate an Information Card with their account. This flow is nearly identical to the “lost password” flows often found on sites. Best practices for lost card handling are documented in the “Enabling Information Card Recovery” section of Patterns for Supporting Information Cards at Web Sites: Personal Cards for Sign up and Signing In.

Additional Steps Sites Could Take

In the short term, sites could also choose to add text to their Information Card login pages warning users that their existing cards will not be recognized as being associated with their accounts after the .NET update, and directing them to use the “lost card” feature of the site to remedy this situation.

EV and no-SSL Sites Not Affected

None of this affects sites using Extended Validation (EV) certificates or sites not using SSL certificates. These algorithms were already stable and have not changed. No action is required in these cases.

Background on the Problem

Because the original PPID and Signing Key algorithms used the entire certificate chain, these values could change under several circumstances:

• First, as sites renew their certificates, it is common for the certificate chain for the new cert to differ from the old one. This would change the PPID, breaking the user’s self-issued cards at those sites. And of course, the chain always changes if the site changes its certificate provider.
• Second, because the algorithm for converting the bytes of the chain certificates into characters was not fully specified by ISIP V1.0 for some OIDs, for some kinds of certificates, different Identity Selectors produced different results for the PPID claim, Signing Key, Client Pseudonym PPID, and IP Identifier values.
• Finally, in ISIP V1.0, the PPID for a site using a non-EV certificate is different than the PPID for a site that uses an EV certificate, even in the case where the non-EV leaf cert content meets the EV issuance criteria. This means that when a site upgraded to using an EV certificate, user’s cards would stop working at that site.

Overview of the Solution

To address these issues, the computation of the PPID and Signing Key for sites using regular certificates has been changed to no longer include information from the certificate chain, but only information from the leaf certificate. This will provide stability both when certificates are renewed and when a certificate is obtained from a new issuer.

Furthermore, the new algorithm generates the same PPID values for sites using EV and non-EV certificates with the same leaf certificate information, while generating different Signing Keys. This will help enable a smooth migration path for sites upgrading from non-EV to EV certificates because the PPID remaining the same can be used as evidence that the same card is being used before and after the certificate upgrade.

More about the specifics of the algorithm change can be found in Section 8.6.1 of ISIP V1.5 and additional guidance and commentary can be found in the corresponding section of the ISIP V1.5 Guide.

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.

Launched in September 2006, the IDSP was established by the American National Standards Institute (ANSI) and Better Business Bureau (BBB) to identify and catalog existing standards, guidelines, and best practices related to identity theft prevention.
Panel members considered the entire life cycle of identity management: from the issuance of identity documents by government and commercial entities, to the acceptance and exchange of identity data, and to the ongoing maintenance and management of identity information. Hundreds of documents – including the applicable laws, regulations, proposed legislation, white papers, and research studies and reports – are identified in the catalog.
The report also includes recommendations for business and government agencies to:

• enhance the security of identity issuance processes to facilitate greater interoperability between the government and commercial sectors;
• improve the integrity of identity credentials;
• strengthen best practices for authentication;
• augment data security management best practices such as the use and storage of Social Security numbers;
• create uniform guidance for organizations on data breach notification and remediation;
• increase consumer understanding of ID theft preventative strategies, including the benefits and limitations of security freezes.

This report provides one of the most comprehensive looks to date at the problem of identity theft and the fraud that accompanies it. It both surveys the current identity landscape and makes recommendations for business, government, and consumers to mitigate these threats both in the offline and online environments.

Chock full of useful, actionable information covering the “whys”, “whats”, and “hows” of employing safer, easier-to-use, privacy-preserving digital identities. Insightful perspectives, on topics from cryptography and protocols to user interfaces and online threats to businesses drivers, make this an essential resource!

Come ’n get it!

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!

Chock full of useful, actionable information covering the “whys”, “whats”, and “hows” of employing safer, easier-to-use, privacy-preserving digital identities. Insightful perspectives, on topics from cryptography and protocols to user interfaces and online threats to businesses drivers, make this an essential resource!

A must-have for anyone deploying or considering deploying Information Cards. And if you can’t wait for the book to be published, you can also purchase a first draft of the book from Rough Cuts. Enjoy!

Last night OSIS and the Burton Group held the third in a series of user-centric identity Interop events where companies and projects building user-centric identity software components came together and tested the interoperation of their software together. Following on the Interops at IIW in May and Catalyst in June, the participants continued their joint work of ensuring that the identity software we’re all building works great together.

This Interop had a broader scope along several dimensions than the previous ones:

• We welcomed new participants a.t.e Software, Fraunhofer, JanRain, LinkSafe, ooTao, Sun Microsystems, Siemens, and ThoughtWorks.
• We tested interoperation of OpenID software (including i-name software) in addition to Information Card software.
• Several kinds of interop between Information Card and OpenID software were demonstrated, including:
  1. OpenID providers implementing the OpenID phishing-resistant authentication specification using Information Cards to enable phishing-resistant sign-in to OpenIDs, and
  2. using OpenID Information Cards to supply OpenIDs to OpenID relying parties.
• Unlike previous Interops, the endpoints and testing results are all publicly available so that others can benefit from them.
• Many of the participants have committed to keeping their sites up beyond Catalyst to allow for continued public interop testing. For instance, Microsoft’s sites will remain up at http://www.federatedidentity.net/.

An excerpt from Bob Blakley’s insightful-as-always commentary on the Interop is:

The participants have posted their results on the wiki, and a few words are in order about these results. The first thing you’ll notice is that there are a significant number of “failure” and “issue” results. This is very good news for two reasons.

The first reason it’s good news is that it means enough new test cases were designed for this interop to uncover new problems. What you don’t see in the matrix is that when testing began, there were even more failures – which means that a lot of the new issues identified during the exercise have already been fixed.

The second reason the “failure” and “issue” results are good news is that they’re outnumbered by the successes. When you consider that the things tested in Barcelona were all identified as problems at the previous interop, you’ll get an idea of how much work has been done by the OSIS community in only 4 months to improve interoperability and agree on standards of component behavior.

Be sure to read his full post for more details on what the participants accomplished together. And of course, this isn’t the end of the story. An even wider and deeper Interop event is planned for the RSA Conference in April 2008. Great progress on building the Internet identity layer together!

During Catalyst in San Francisco we announced the now-familiar Information Card icon and its accompanying usage guidelines. Since then we’ve received community feedback on clarifications we could make to the guidelines. In response, we’ve publish an updated version of the guidelines addressing that feedback and an accompanying updated complete icon zip file during Catalyst in Barcelona.

Specifically, we were asked if we could be clearer that the icon can be used in contexts discussing and promoting Information Cards, not just in software, and some felt that the spacing guidelines were overly restrictive. My favorite feedback along these lines came from Dale Olds, in his wonderful Fashions in information card beachware post, where he wrote:

Thanks to Mike for the information card shirt. I try to wear it in compliance with the logo usage guidelines, but I think I probably sometimes stand too close to other images and I spilled some salsa on it. I’ll keep working on it.

So don’t worry Dale… I’m glad you’re enjoying your shirt and displaying the icon to the world. Heck, you can even print some cool new ones of your own using it if you want. (And if you do, it’d love it if you saved one for me!)

Second, on the blog they’ve started a series of posts about new features to come in the .Net Framework 3.5, which will ship with Windows Vista Service Pack 1 and be available as a free download for Windows XP and Windows Server 2003. The first post in the series describes the ability to use Information Cards at relying parties over http connections, without requiring a SSL certificate. This was a feature a number of you had asked for and the team responded.

Subscribe to the blog and read the series! Also, check out Vittorio Bertocci’s useful commentary on the no-SSL feature.

This combination has several advantages over standard OpenID usage. First, there’s no OpenID string to type when you use your OpenID, which should make OpenIDs easier for more people to use. Second, this is a phishing-resistant authentication method. Finally, it lets you recognize and choose your OpenID visually, based on the card graphics supplied by the OpenID provider.

Sxip also backed this specification by a sample implementation, which you can check out at https://openidcards.sxip.com/. Now for some more details….

Here’s how it works: In this model, the OpenID relying party asks for an OpenID Information Card using an object tag on the page rather than having the user type the OpenID as a string (while probably also giving the user the option to instead type in the string for backwards compatibility). The user’s Identity Selector then lets the user choose which OpenID card to send to the site. The card transmits the actual OpenID string to the site as a claim. From that point on, standard OpenID protocol interactions ensue.

For instance, the sample relying party page asks you to “Login with an OpenID InfoCard” and requests the card using this evocative graphic:

Upon clicking the graphic, my identity selector is invoked, which shows me that I can use this OpenID Information Card at the site (which I’d previously obtained here):

After that, the sample performed a standard OpenID attribute exchange and the relying party greeted me with:

Welcome! You have logged in using your https://openidcards.sxip.com/i/mbj OpenID identifier.

Phone: (omitted)
Country: USA
Email: mbj@microsoft.com
City: Redmond
Address: One Microsoft Way, Building 40/5138
LastName: Jones
FirstName: Mike

Behind the scenes, the relying party had received this OpenID assertion:

<openid:OpenIDToken xmlns:openid="http://specs.openid.net/auth/2.0">openid.ns:http://specs.openid.net/auth/2.0
openid.op_endpoint:https://openidcards.sxip.com/op/
openid.claimed_id:https://openidcards.sxip.com/i/mbj
openid.response_nonce:2007-08-26T20:55:34Z0
openid.mode:id_res
openid.identity:https://openidcards.sxip.com/i/mbj
openid.return_to:https://openidcards.sxip.com/demorp/
openid.assoc_handle:f27d249fc4108198
openid.signed:op_endpoint,claimed_id,identity,return_to,response_nonce,assoc_handle
openid.sig:gKKpDjEbgByJo48Q800Jq4gCJng=
openid.ns.ext1:http://openid.net/srv/ax/1.0-draft4
openid.ext1.mode:fetch_response
openid.ext1.type.attr1:http://axschema.org/contact/phone/default
openid.ext1.value.attr1:(omitted)
openid.ext1.type.attr2:http://axschema.org/contact/country/home
openid.ext1.value.attr2:USA
openid.ext1.type.attr3:http://axschema.org/contact/email
openid.ext1.value.attr3:mbj@microsoft.com
openid.ext1.type.attr4:http://axschema.org/contact/city/home
openid.ext1.value.attr4:Redmond
openid.ext1.type.attr5:http://axschema.org/contact/postalAddress/home
openid.ext1.value.attr5:One Microsoft Way, Building 40/5138
openid.ext1.type.attr6:http://axschema.org/namePerson/last
openid.ext1.value.attr6:Jones
openid.ext1.type.attr7:http://axschema.org/namePerson/first
openid.ext1.value.attr7:Mike
</openid:OpenIDToken>

One final technical note that will be of interest to some of you: OpenID Information Cards do not use SAML tokens. They use one of two variants of openid:OpenIDToken tokens (depending upon whether the OpenID relying party uses OpenID 1.1 or 2.0 authentication).

Go get yourself an OpenID Information Card and give it a spin! Read and comment on the spec. Or even better yet, implement it and tell us about your experience!

An updated version of the Information Card Deployment Guide is now available. Among other improvements, it’s been updated to employ the Information Card Icon. As the original deployment guide announcement said:

So you’ve decided to use Information Cards on your web site… Now what? I’m pleased to announce that we’ve just published a document giving step-by-step guidance to Web developers on what we believe are the best practices for doing this. The document walks Web site developers through two different deployment scenarios: sites exclusively using Information Cards for authentication, and mixed-mode sites allowing the use of either passwords or Information Cards. Examples are given for site sign-in, site sign-up, and handling lost Information Cards, including suggested confirmation text for each of these scenarios.

This link to the document Patterns for Supporting Information Cards at Web Sites: Personal Cards for Sign up and Signing In references the current version and will be updated to point to any future revisions as well. The Sample Information Card Site employs these guidelines and is built using the Information Card Relying Party Resources announced earlier. Enjoy adding Information Card support to your web sites!