Musings on Digital Identity

Category: Information Cards Page 2 of 5

Document Signing and Access Control with Avoco Secure Information Cards

Avoco Secure CardSandy Porter of Avoco Secure recently let me know that their secure2trust document security product now supports both document signing and document access control using managed Information Cards. The cards and the Avoco software enable perimeterless, secured access to documents and online web form signing.

Avoco has hosted an instance of their Identity Provider and sample document signing and document access control scenarios online, so people can give it a try now. Using the “Create an ID” tab at to create a card, and then following the instructions at the “Securing with Identity” tab, I was able to obtain a document a document that can only be opened by using the card I created.

When I open this doc (in my case, “Mike Jones.docx”), CardSpace is launched. When I submit my card, access control is granted and the document shown below is opened.

Document protected by Avoco Secure Information Card

For more information, see the page “Create and Manage your own Digital Identities with Avoco Secure’s Identity Provider“, their demo site, and also try document signing using your Avoco Secure managed card at

Information Card Specification Public Review

Information Card IconOASIS logoToday 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!

Additional 3:2 Information Card Icon Aspect Ratio

3:2 Information Card Icon10:7 Information Card IconMicrosoft has released an additional rendering of the Information Card Icon with a 3:2 aspect ratio, which can be used in addition to the existing 10:7 aspect ratio renderings. Quoting from the updated Frequently Asked Questions document:

Q: When should the 3:2 aspect ratio version of the icon be used?
A: The 3:2 aspect ratio rendering is intended for use in visual contexts when a 3:2 aspect ratio rendering of either an Information Card image or the icon may be displayed. Having a 3:2 aspect ratio rendering of the Icon (in particular, a 120×80 pixel rendering) allows it to be the same size as an Information Card image, and thus, enables the interchangeable display of the Icon or an Information Card image.

If you have a need for a 3:2 aspect ratio rendering of the icon, you can get it now from the updated download package. You can visually compare 114×80 and 120×80 renderings of the icon in this post.

Orange, eBay, and Microsoft Demonstrate New CardSpace User Experience

Orange, eBay, and Microsoft teamed up to demonstrate the CardSpace “Geneva” experience at TechEd in Barcelona. In the demo, an Orange-issued Information Card was used to sign into eBay with an early version of CardSpace “Geneva”. This post shows you the user experience we jointly developed. (And yes, this was running code — not a mockup.)

eBay login page accepting Information Cards
The user can sign into eBay either with a username and password or with an Information Card.

Using an Orange Information Card to sign into eBay
After clicking the Information Card icon in the first screen (the purple “i” symbol) to sign in with a card, CardSpace shows Alex that his Orange Information Card can be used to sign into eBay.

Always use this card at this site
Alex decides that he always wants to sign into eBay with his Orange card, and so checks the “Always use this card at this site” box for the card.

Logged into eBay
After clicking “OK” to submit his card, Alex is logged into eBay.

Login details
eBay lets Alex see details about his login.

eBay login page using a CardTile
Alex has logged out, but is ready to log into eBay again. This time, rather than showing the Information Card icon, Alex’s Orange card is shown and is ready to use, courtesy of the CardSpace CardTile. Now a single click will submit his card, logging him in again.

SUSE Linux Now Includes an Identity Selector

DigitalMe Logo

My thanks to Dale Olds for pointing out that the SUSE Linux distribution now contains an Identity SelectorDigitalMe (from the Bandit Project). He’s right — it’s important to mark significant milestones such as these. That’s now two platforms and counting…

Novell Product Release with Information Cards and WS-Federation

Novell logoAs announced in Dale Olds’ post Information Card breakthrough with Novell Access Manager 3.1, Novell has released a version of Access Manager that adds support for Information Cards and WS-Federation, partially courtesy of the Bandit Team. I was on the show floor at BrainShare in March 2007 when Novell first demonstrated WS-Federation interop (showing eDirectory users on Linux accessing SharePoint on Windows via an early version of Access Manager and ADFS), so I’m particularly glad to see that the scenarios we jointly demonstrated then can now be deployed by real customers.

It was also at that BrainShare where Novell demonstrated the first cross-platform Identity Selector (an event significant enough that I decided it was time to start blogging). It’s great to likewise see Novell’s Information Card work progress from show-floor demos to shipping product. Congratulations to Novell and the Bandits!

Try the CardSpace CardTile Yourself

CardSpace IconThe directions we’ve taken CardSpace “Geneva” are strongly shaped by feedback we received about the first version of CardSpace. One of the most frequently heard feedback points was to make the user experience less disruptive. For instance, Ashish Jain wrote about “Too many clicks”.

The new “CardTile” feature, where the image of the last card used at a site can be displayed on the site’s page, enables two-click card submission, while still providing the user feedback about the card that will be used by default. The screen shot below shows an example of the CardTile in use, displaying the image of the most recently used card in the page. CardTile page

The “Always use this card at this site” feature takes this a step further, enabling true one-click submission to sites where you have already used a card. See the recent CardSpace “Geneva” Selection Experience post for more details.

But back now to the subject of this post… The team has created a relying party page using the CardTile at It should work both with selectors that do and don’t support the CardTile feature. Try it yourself!

Equifax, the Information Card Foundation, and Interoperable Verified Claims

Equifax Verified Over 18 CardMy congratulations to Equifax for issuing the first commercially deployed Information Cards with verified claims. This is huge step forward towards a future where individuals can routinely make verified digital statements about themselves, facilitating trusted, privacy-preserving interactions online.

I’m writing to bring you some of the story-behind-the-story in Information Card Foundation member Equifax issuing these verified Information Cards. Rather than use proprietary claims schemas in their cards, Equifax chose to use claims that are designed to be interoperable with cards that will be issued by other identity providers. Their cards use a combination of the standard Information Card claims, along with a newly defined age-18-or-over claim that anyone can implement.

This new age-18-or-over claim is the first to emerge from the new Information Card Foundation Identity Schemas Working Group. This is a place where anyone can propose a new claim URI and register it for use by all. You will find the age-18-or-over claim definition in the working group’s Claims Catalog. This is an example of how the Information Card Foundation is facilitating collaboration to advance interoperable Information Cards.

I’ll close by saying that while the Equifax page promotes the new Azigo identity selector, their card uses interoperable protocols and file formats, and is compatible with all identity selectors. For instance, you’ll see a screen shot of my Equifax card in Windows CardSpace below, showing both the use some of the standard Information Card claims, as well as the new age-18-or-over claim from the ICF Claims Catalog.

Equifax Age 18 or Over Card Details

Even More News from the PDC: First Look at the Next Version of CardSpace

CardSpace IconI’m excited that the first beta of the next version of CardSpace — Windows CardSpace “Geneva” — is now available. You can download the bits for this and the other “Geneva” betas at the “Geneva” Connect site. The team posted a detailed introductory piece about the new version on the team blog, so I won’t repeat that here.

This version of CardSpace is a rewrite on a new code base designed to be much smaller, faster, and easier to use. While it’s an early build and far from feature-complete, we nonetheless wanted to get it out now so you can see the directions we’re headed and give us feedback early in the development cycle. This build runs on Windows Vista (32 and 64 bit), Windows Server 2008, and Windows 7.

We’ll be writing more about the key features of CardSpace “Geneva” soon, and as well as the rest of the “Geneva” family that enables claims-aware applications, so watch this space and the team blog. It’s great to now be able to show and discuss the work the team has been doing. I’m looking forward to the ensuing conversation…

More News from the PDC: Beta Releases of “Geneva” Platform Components

As just announced on the “Geneva” Team Blog (formerly known as the CardSpace Team Blog), beta releases of all three components of Microsoft’s “Geneva” identity platform are now available at the “Geneva” Connect site. The components are:

  • “Geneva” Framework: Previously called “Zermatt“, the Geneva Framework helps developers build claims-aware .NET applications that externalize user authentication from the application and helps them build custom Security Token Services (STSs). It supports WS-Federation, WS-Trust, and SAML 2.0.
  • “Geneva” Server: Geneva Server is an STS that issues and transforms security tokens and claims, manages user access, and enables easy federation. Based on the “Geneva” framework, it also supports WS-Federation, WS-Trust, and SAML 2.0.
  • Windows CardSpace “Geneva”: CardSpace “Geneva” will be the next version of Windows CardSpace. It has a much smaller download footprint, starts fast, and has some innovative user interface improvements made in response to feedback from the first version.

All are early betas that are works in progress, but I highly encourage those of you who are interested in claims-based identity to download them and let us know what you think. Also, be sure to check out the “Introducing ‘Geneva’” whitepaper by David Chappell.

Next News from the PDC: SAML 2.0 Protocol Support in “Geneva” Server

As Don Schmidt wrote this morning, Microsoft’s “Geneva” Identity Server product will support the SAML 2.0 protocol. Specifically, we will be supporting the SAML 2.0 IdP Lite and SP Lite profiles and the US Government GSA profile. Customers had told us that these SAML profiles are important to them and we’re responding to that feedback by implementing them in “Geneva” Server. Those of you who were at Kim Cameron’s “Identity Roadmap for Software + Services” presentation at the PDC got to see Vittorio Bertocci demonstrate SAML federation with “Geneva” Server to a site running IBM’s Tivoli Federated Identity Manager.

The “Geneva” Server is the successor to Active Directory Federation Services (ADFS). It will, of course, interoperate with existing ADFS and other federation implementations using the WS-Federation protocol. In addition, it adds WS-Trust support for issuing Information Cards, letting it work with Windows CardSpace and other Identity Selectors.

I’ll add that the SAML 2.0 support doesn’t stop with the server. SAML 2.0 is also supported by the “Geneva” Identity Framework — a .NET application development framework formerly known as “Zermatt” and “IDFX”, which likewise also supports WS-Federation and WS-Trust. In short, the same identity development framework components that are being used to build “Geneva” Server will be available to all .NET developers as the “Geneva” Identity Framework.

Finally, I’ll close by thanking the folks on the Internet 2 Shibboleth project, IBM, and Ping Identity who helped us with early interop testing of our code. You have been valuable and responsive partners in this effort, helping us make sure that what we’re building truly interoperates with other SAML 2.0 implementations deployed in the wild.

Online Identity Theft and Digital Playgrounds Whitepapers

I wanted to bring your attention to two whitepapers covering important Internet identity topics that were published by members of Microsoft’s Trustworthy Computing and Privacy teams, both announced on the blog The Data Privacy Imperative.

The first is “Online Identity Theft: Changing the Game — Protecting Personal Information on the Internet” by Jules Cohen, Brendon Lynch, and other members of Microsoft’s Trustworthy Computing team. Per the announcement, the paper:

… for the first time describes in detail Microsoft’s comprehensive strategy for curbing online identity theft. In addition to describing current Microsoft initiatives, the paper outlines long-term solutions for “changing the game” by ending reliance on “shared secrets” for authentication.

Relying on “shared secrets,” such as usernames, passwords, birthdates and government ID numbers to establish the right to do something online, creates security problems because they are relatively easy to steal and can be difficult to remember, update and manage. We need to employ new identity practices online that are just as reliable but better protect against fraud and abuse, and that’s where Information Cards come in …

The paper has been greeted by favorable reviews, including an Information Week article that also describes the role that the Information Card Foundation can play and a NetworkWorld article by Dave Kearns that concludes “Download this important paper, read it, then act on it.”

The second is “Digital Playgrounds: Creating Safer Online Environments for Children” by Jules Cohen of Microsoft’s Trustworthy Computing team and Chuck Cosson, Policy Counsel on privacy and safety issues, with some input from me. The paper was presented to the Internet Safety Technical Task Force (ISTTF) by Jules and submitted by Microsoft as input to the task force. As Jules wrote about the approach:

The Digital Playgrounds paper outlines a framework that would enable the creation of optional online “walled gardens,” specifically for children and trusted adults. These online sites would only be accessible by folks with trusted and age verified ‘digital identities.’ This framework suggests achieving this by allowing trusted offline parties, who have the ability to meet with a parent and child in real life, examine the appropriate documents and then issue extremely secure digital identities based on these in in-person proofing moments. The framework we have outlined is largely a technical solution to the age verification challenge, but we believe that the nontechnical aspects of the problem will be as difficult to solve as the technical ones, if not more so. For example, government and industry will need to work together on designing the necessary criteria for in-person proofing events as well as the subsequent issuing, auditing and revoking of these digital identity cards.

I especially encourage people to consider the possibility that existing offline identity proofing ceremonies might be leveraged to enhance safety online as well.

Information Card Standardization Work Commencing

OASIS logoI’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.

Information Card IconThe 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!

New Information Card Foundation Members from Around the World

Intel logoDeutsche Telekom logoI wanted to bring your attention to a press release about seven new members who have joined the Information Card Foundation from around the world. The new members are Deutsche Telekom of Germany, CryptoPro of Russia, Eduserv of the United Kingdom, ETRI of South Korea, Figlo of the Netherlands, Intel of the United States, and WISeKey of Switzerland. I’m particularly excited to welcome Deutsche Telekom and Intel as new board members. It’s great to see the range of companies and individuals who are coming together to help bring the benefits of Information Cards to their markets and spheres of influence.

PPID Compatibility Note for Sites Accepting Self-Issued Information Cards

Information Card IconRelying 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.

WS-Addressing Identity Extension Published

Information Card IconIBM and Microsoft just published the specification “Application Note: Web Services Addressing Endpoint References and Identity” at 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

Analysis of the Third OSIS User-Centric Identity Interop

OSIS logoCongratulations and thanks to Pamela Dingle for publishing a detailed analysis of what that the industry accomplished together during the Third OSIS User-Centric Identity Interop (I3). As Nulli Secundus writes about the paper:

The OSIS I3 Interop was a five-month event in which organizations, individuals, and projects working in the solution spaces of Information Cards and OpenID collaborated to define and demonstrate their ability to transact successfully regardless of differences in hardware or software platform. Participants worked within each solution space to define and test acceptable behaviors for various situations that crop up when loosely coupled solutions communicate with each other via open protocols. Interop participants created results within two different matrices: feature test results which recorded adherence to acceptable behavior when explicitly tested, and cross-solution results which recorded overall interoperability between solutions with complimentary roles. Combined, the participants recorded over 1200 mostly successful results.

As new solutions enter this space and existing solutions add to their feature sets, the OSIS Interop process and results serve as a metric to inform developers what features will contribute to a consistent experience for users and administrators. OSIS Interops have served as a focal point for discussion and feature concentration and a forcing function to solidify the protocols. Overall, much was accomplished but there is still work to be done. By examining participation, contribution to best practices, process and collaboration, discoveries, and obstacles, the Interop process can be refined and improved to give even more value to those involved; by doing so, diversity in product offerings will not result in difficulty for end users.

Many of the learnings and conclusions that Pamela has captured in the paper have informed the Fourth OSIS User-Centric Identity Interop (I4), which is under way and builds on the accomplishments of I3 and the previous interops. Check out the paper and if you have an implementation of Information Card or OpenID software, the time is now to participate in I4!

Identity Selector Interoperability Profile V1.5

Information Card IconI 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:

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.

Digital Identity Podcast for MySuccessGateway

MicrophoneKim Cameron and I recorded a podcast on digital identity for MySuccessGateway this week at the invitation of Jim Peake of SpeechRep Consulting. Jim was a gracious, informed, and enthusiastic host during our conversation, which covered a wide range of digital identity topics including identity theft, shared secrets, privacy, Information Cards and the Information Card Foundation, the value of verified claims, business models for identity providers, password fatigue, defeating phishing attacks, OpenID, why interoperability is essential and the interoperability testing the industry is doing together to make it a reality, some of the identity products that are shipping and forthcoming, and the Laws of Identity. He even asked us how we felt about Bill Gates’ retirement, as a kicker.

If that sounds interesting to you, give it a listen

CardSpace Consumer Website

Windows logoMicrosoft recently created a Consumer Website for CardSpace to educate end-users about Windows CardSpace and Information Cards. This complements the developer-focused information at the MSDN CardSpace site and the CardSpace Community Site.

No, it’s not the kind of content targeted at regular readers of this blog — especially the short video — but then, that’s kind of the point. :-)

Page 2 of 5

Powered by WordPress & Theme by Anders Norén