Archive for the 'Windows CardSpace' Category

February 15, 2011
Personal Reflections on the CardSpace Journey

CardSpace IconToday, Microsoft announced that it will not be shipping Windows CardSpace 2.0. Having made a significant personal investment in working to make CardSpace a success and the Information Card vision a reality, I wanted to take the opportunity to share a few personal reflections on the CardSpace journey and the lessons we might want to take away from it.

I’ll start by saying how much I appreciate getting to work with the amazing and diverse set of people that came together around the Information Card idea. I’m still amazed when I look at the sets of participants at the interop events in Barcelona in 2007 and San Francisco in 2008. That many people and organizations don’t come together to work on something together unless they see something valuable there. OSIS (originally an acronym for “Open Source Identity Selector”), the Information Card Foundation, the OASIS IMI TC, and labors of love like the Pamela Project, XMLDAP, the Higgins Project, the Bandit Project, and openinfocard are likewise testaments to the compelling nature of the Information Card vision. I’ve loved working on this with all of you!

So with all this support and energy behind Information Cards, why aren’t we on the path to ubiquitous adoption? While there are many reasons, I’ll highlight two, based upon my personal experiences…

  • Not solving an immediate perceived problem: In my extensive experience talking with potential adopters, while many/most thought that CardSpace was a good idea, because they didn’t see it solving a top-5 pain point that they were facing at that moment or providing immediate compelling value, they never actually allocated resources to do the adoption at their site.
  • Not drop-dead simple to use: Users were often confused by their first encounter with CardSpace; many didn’t succeed at the task at hand. Indeed, many saw it as something complicated getting in the way of what they were actually there to do.

While are plenty of other reasons that were contributing factors, such as requiring a client that wasn’t ubiquitously available and not having server software available to go with the client, I firmly believe that if people thought that CardSpace would provide immediate compelling value and that it was easy to use, that Information Cards would now be an everyday part of the Internet. Not having achieved those things, we are where we are today.

Not that this is the end of the line by any means. I believe there’s still tremendous value in the principles behind The Laws of Identity, the vision of user empowerment we all called user-centric identity, and the benefits of verified claims; the Internet is still missing an identity layer. Part of the great news for me personally is that I’m getting to continue working on making these things a reality with many of you who believed in the vision behind CardSpace and what it was trying to achieve.

As we go forward, hopefully the lessons learned from the CardSpace journey will help us succeed in ways that Windows CardSpace itself never did.

May 21, 2010
Card Issuance CTP for AD FS 2.0

Information Card IconToday Microsoft released a Community Technology Preview (CTP) of software for issuing Information Cards that works with the recently released Active Directory Federation Services (AD FS) 2.0 server software. This means that as well as supporting identities using WS-Federation and SAML 2.0, people can try out scenarios where their identities are based on Active Directory, AD FS 2.0 provides the claims for them using WS-Trust, and cards using the AD FS 2.0 WS-Trust endpoints are issued using the CTP.

As well as working with the current CardSpace 2.0 beta, these cards work with CardSpace 1, which shipped with Windows 7 and Windows Vista and is available for download on Windows XP. They should also work with other identity selectors, both on Windows and on other platforms.

You can ask questions about this at ici-ctp@microsoft.com or by participating in the CardSpace forum.

May 4, 2010
Update to Identity Selector Detection Script for IE8

Information Card IconIn December, 2006 Garrett Serack (Fear the Cowboy!) wrote about Detecting CardSpace support, including FireFox. His detection script since made its way onto numerous sites and into relying party software releases.

Unfortunately, this script didn’t detect selectors on Internet Explorer 8 due to changes between IE7 and IE8. Andrew Arnot asked the question Why don’t InfoCards work in IE8? on StackOverflow.com, and then subsequently answered his own question, with help from the IE8 team. Given I’ve referred people to this answer numerous times since, I decided to re-post it here, both for others, and for my own ease of reference.

Here’s the fix… If you’re using Garrett’s original JavaScript, replace the line:
    embed.setAttribute("type", "application/x-informationcard");
with
    embed.type = "application/x-informationcard";
Then your relying party will work with IE7, IE8, and Firefox.

March 2, 2010
U-Prove Specifications Licensed and Sample Code Released

U-Prove logoThis morning at the RSA conference, Scott Charney announced that Microsoft has licensed the U-Prove technology under the Open Specification Promise and released sample implementations in C# and Java under the BSD license. Implementers will be interested in two specifications: the “U-Prove Cryptographic Specification V1.0”, which documents U-Prove’s cryptographic operations, and “U-Prove Technology Integration into the Identity Metasystem V1.0”, which documents how to use U-Prove tokens with WS-Trust. These specifications are intended to enable interoperable implementations.

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

December 18, 2009
Updated Federated Identity Product Releases

Today Microsoft announced the availability of new releases of several identity products: Active Directory Federation Services (AD FS) 2.0, the Windows Identity Foundation, and CardSpace 2 (which collectively were formerly referred to as “Geneva”), as well as Federation Extensions for SharePoint. See Announcing the AD FS 2.0 Release Candidate and More and Announcing WIF support for Windows Server 2003 for the release announcements as well as links to numerous step-by-step guides, samples, docs, and video. Thanks to all those who did interop work with us (including at Catalyst, Liberty, and pair-wise) to help ensure that these releases will work well with other’s implementations.

November 16, 2009
An Experimental Identity Selector for OpenID

OpenID logoThe OpenID community has been talking about the value that an optional active client could bring to OpenID for well over a year. To concretely explore this possibility, as many of you know by now, a team at Microsoft built a prototype multi-protocol identity selector supporting OpenID, starting with CardSpace 2, which I and others demonstrated at the OpenID Summit and the Internet Identity Workshop. We did this to stimulate discussion and engage the community about the value of adding active client support to OpenID. And I’ll say up front that enormous thanks go to Joseph Smarr at Plaxo, the team at JanRain, and Andrew Arnott for building demonstration relying parties that worked with the prototype, which made the demonstrations possible.

While you may have read about it on Kim’s blog and many of you were there in person, I wanted to capture screen shots from the demos to make them available, so those who weren’t there can join the discussion as well. Plus, I’ve posted the presentation that accompanied the demos, rather than reproducing that content here. Now, on to the demo, which closely follows the one actually given at the Summit…

 


Using a selector for the first time

I start by demonstrating the user experience for a first-time selector user at a a selector-enabled OpenID relying party.

 

Plaxo signin
The first screen shot shows a standard Plaxo login screen, but augmented behind the covers to enable it to pass its OpenID authentication request parameters to an active client, if present. I will click on the “Sign in with OpenID” button on the Plaxo signin page, invoking the selector.

In the prototype, selector-enabled relying parties use a variant of the Information Card object tag to communicate their request parameters to the selector. The object tag parameters used on Plaxo’s RP page are:
<object type="application/x-informationCard" id=infoCardObjectTag>
<param name=protocol value="http://specs.openid.net/auth/2.0"/>
<param name=tokenType value="http://specs.openid.net/auth/2.0"/>
<param name=issuer value="Google.com/accounts/o8/id Yahoo.com myOpenID.com"/>
<param name=issuerExclusive value=false/>
<param name=OpenIDAuthParameters value=
"openid.ns:http://specs.openid.net/auth/2.0
openid.return_to:http://www.plaxo.com/openid?actionType=complete
openid.realm:http://*.plaxo.com/
openid.ns.sreg:http://openid.net/extensions/sreg/1.1
openid.sreg.required:email
openid.sreg.optional:fullname,nickname,dob,gender,postcode,country,language,timezone
openid.sreg.policy_url:http://www.plaxo.com/about/privacy_policy
"/>
</object>

 

Plaxo empty selector
Here I’ve clicked on the “Sign in with OpenID” button, invoking the selector. (The “Google” and “Yahoo” buttons would have invoked the selector too.) This shows the first-time selector user experience, where it isn’t yet remembering any OpenIDs for me. The three OPs suggested by Plaxo – Google, Yahoo, and MyOpenID, are shown, as well as the option to type in a different OpenID. I click on the Yahoo suggestion.

 

Plaxo Yahoo first time
Clicking on Plaxo’s Yahoo suggestion resulted in a Yahoo OpenID card being made available for use. Note that, by default, the selector will remember this card for me. (Those of you who know OpenID well are probably thinking “Where did the selector get the Yahoo logo and friendly name string”? For this prototype, they are baked into the selector. Longer term, the right way is for the selector to retrieve these from the OP’s discovery document. The OpenID UX working group is considering defining discovery syntax for doing just that.)

Once I’ve clicked “OK” to select the identity to use, the selector (not the RP) redirects the browser to the OP – in this case, to the Yahoo login page. The selector’s work is done at this point. The remainder of the protocol flow is standard OpenID 2.0.

 

Yahoo Plaxo signin
This is the standard Yahoo OpenID signin page, which the selector redirected the browser to after I choose to use the suggested Yahoo OpenID. I sign into Yahoo.

 

Yahoo Plaxo permission
The signin page is followed by the standard Yahoo permissions page. I click “Agree”.

 

Plaxo signed in
After logging with Yahoo, I’m redirected back to Plaxo. Because I’d previously associated my Yahoo OpenID with my Plaxo account, I’m now logged into Plaxo. My status “Michael is demonstrating an OpenID selector at the OpenID Summit”, which I updated live during the demo at the OpenID Summit, is shown.

 


Selector defaults to the OpenID last used at the site

At this point in the demo, I’ve signed out of Plaxo and returned to the selector-enabled sign-in page. After clicking “Sign in with OpenID” again, the selector reappears.

Plaxo Yahoo second time
This time, the selector has remembered the OpenID I last used at the site and tells me when I last used it there. (This is one of the ways that a selector can help protect people from phishing.) By default, the OpenID last used at a relying party is automatically selected – in this case, Yahoo. I click “OK” to select it, with the rest of the flow again being the standard OpenID 2.0 flow.

 


Experience at a new RP plus a trusted OP experience

Interscope homepage
JanRain selector-enabled several production sites, including interscope.com, uservoice.com, and pibb.com, which use JanRain’s hosted RPX service. This could be done with no impact on users without a selector by using JavaScript to detect whether a selector is present or not, and customizing the page accordingly. The page above is the production Interscope Records page. I click the OpenID button on the right under the “Join The Community” banner.

 

Interscope signon
The OpenID button invokes the RPX “NASCAR” experience. (Arguably, this page could be omitted from the experience if a selector is detected.) I click the OpenID button on the “NASCAR” page.

 

Interscope Yahoo never used here
The selector is invoked by Interscope (really, by RPX) to let me choose an OpenID. My Yahoo OpenID is shown and the “Never used here” tells me that I haven’t used it at this site before. I could choose it by clicking OK or hitting Enter. Instead, I click the “Other OpenIDs” button to explore other options.

 

Interscope other OpenIDs
The “Other OpenIDs” tile shows me the OpenID providers suggested by Interscope – in this case, Flickr, Yahoo, and Google. I click on the Google suggestion.

 

Interscope Google first time
The selector has created a Google OpenID card for me to use. It is marked “Verified” because it (like Yahoo) was on a whitelist in the selector and considered “safe” to use. Of course, in production use, such a whitelist would have to be maintained by a neutral third party or parties and dynamically updated. In the prototype, we hard-coded a few common providers so we could show a user experience that relies on a whitelist of OPs, to start the discussion about that possibility. I hit Enter to use the new Google card at Interscope.

 

Google UniversalMusic signin
Once I chose to use my Google card, the selector redirected me to Google’s signin page, with the actual RP for Interscope being signup.universalmusic.com. I sign into Google.

 

Google UniversalMusic permission
Following signin, Google asks me permission to release information to signup.universalmusic.com. I allow it.

 

Interscope registration
I’m redirected back to Interscope, which asked me to complete a sign-up process by supplying more information via a web form.

 


Selector remembering which OpenID’s you’ve used where

Interscope Google second time
When visiting Interscope again after having signed out, signing in with OpenID shows me that I last used my Google OpenID here. For that reason, it’s selected as the default. I can also see that I haven’t used my Yahoo OpenID here.

 


Trusted versus untrusted OpenIDs

test-id signin
Andrew Arnott created the first selector-enabled relying party site for us, which is shown above. I click “Log in using your OpenID Selector”.

 

test-id Google never used here
Now I have both Yahoo and Google cards, but neither have been used at test-id.org. I notice that I can get more details about my cards, and click “More details” on the Google card.

 

test-id Google more details
“More details” tells me where and when I used the card (signup.universalmusic.com), the discovered OpenID endpoint, and that this OpenID was on the selector’s whitelist. I could now use either of these OpenIDs, but I select “Other OpenIDs” instead.

 

test-id other OpenIDs
The “Other OpenIDs” panel shows me OPs suggested by the site, as well as a dialog box to enter another OpenID. I decide to enter my blog URL self-issued.info, which is also an OpenID.

 

test-id self-issued being entered
Here I’m entering my blog URL self-issued.info into the selector. I then click Verify or OK to have the selector perform discovery on the OpenID to add it as one of my choices.

 

test-id self-issued not verified
Discovery has succeeded, but the OP my blog is delegated to, signon.com, is not on the selector’s whitelist. Because it’s not, a warning shield is shown, rather than the OP logo. I’ll also have to make an explicit decision to trust this OpenID provider before the selector will let me use it. The same would have happened if I chose an OP suggested by the RP if the OP was not on the whitelist. This is another aspect of the selector’s phishing protection. I check the “Continue, I trust this provider” box.

 

test-id self-issued trusted
After checking the “Continue, I trust this provider” box, the warning shield is replaced by either the OP logo, if it can be discovered, or a generic OpenID logo, as in this case. I click OK to use this OpenID.

 

signon test-id signin
The selector follows my delegation link from self-issued.info and redirects me to signon.com. (Ping, are you going to fix the signon.com UX issue above someday?) I sign into signon.com.

 

test-id signed in
Having signed into my OpenID at signon.com, I’m redirected back to the test site, which received an authentication response from the OP. I click “Reset test” to sign out, in preparation for another test.

 


More details

test-id self-issued second time
Upon a second visit to test-id.org, the selector has remembered that I last used the OpenID self-issued.info, which is actually delegated to mbj.signon.com. I click “More details” to learn more about this OpenID.

 

test-id self-issued more details
“More details” tells me where and when I last used the OpenID and that the OpenID has been verified. But unlike my Google OpenID, which was verified via the whitelist, I told the selector to trust this OpenID myself.

 


Delegation to a trusted OP

test-id davidrecordon being entered
At the OpenID Summit, people wanted to see the untrusted user experience again, so I entered an OpenID that I was sure wasn’t on our built-in whitelist – davidrecordon.com. However, verifying the OpenID actually brought me and those in attendance a surprise…

 

test-id davidrecordon verified
Because davidrecordon.com is delegated to myopenid.com, which is on the whitelist, it turns out that the prototype considered davidrecordon.com to be trusted as well. Upon reflection, this is probably the right behavior, but I’d never seen it until giving the demo live. (Great job, Oren!) I tried factoryjoe.com next and got the same result. Finally Will Norris helped me out by saying that willnorris.com isn’t delegated, so we got to see the untrusted user experience again.

 


Conclusion

I’d like to thank Chuck Reeves and Oren Melzer for quickly building a killer prototype and to thank Ariel Gordon and Arun Nanda for helping design it, as well as others, both from Microsoft and other companies, who provided feedback that helped us fine-tune it as we built it. See the presentation for a much more comprehensive list of thank-yous.

I’ll close by saying that in the OpenID v.Next planning meeting at IIW, there was an unopposed consensus that optional active client support should be included as a feature of v.Next. Hopefully our demo, as well as those by others, including Markus Sabadello of Higgins, helped the community decide that this is a good idea by enabling people to concretely experience the benefits that an active client can bring to OpenID. If so, I’d call the experiment a success!

May 11, 2009
“Geneva” Beta 2 is Here

Microsoft announced the availability of the second beta of its forthcoming “Geneva” claims-based identity software today during Tech•Ed. This is a significant milestone for the team along the path to releasing production versions of the “Geneva” software family, which includes the server, framework, and CardSpace. I’m personally particularly proud of all the interop work that has been done in preparation for this release. I believe that you’ll find it to be high-quality and interoperable with others’ identity software using WS-*, SAML 2.0, and Information Cards.

For more details, see What’s New in Beta 2 on the “Geneva” Team Blog. Visit the “Geneva” information page. Check out the Identity Developer Training Kit. Learn from team experts on the ID Element show. Download the beta. And let us know how it works for you, so the final versions can be even better.

Enjoy!

March 12, 2009
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 https://www.secure2cardspace.com/ 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 https://www.secure2cardspace.com/ demo site, and also try document signing using your Avoco Secure managed card at http://www.secure2signonline.com/.

January 28, 2009
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.

November 17, 2008
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.

FederatedIdentity.net 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 FederatedIdentity.net team has created a relying party page using the CardTile at https://relyingparty.federatedidentity.net/AnyIssuerRelyingParty/Login.aspx?tile=true. It should work both with selectors that do and don’t support the CardTile feature. Try it yourself!

November 16, 2008
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

October 29, 2008
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…

October 28, 2008
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.

October 28, 2008
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.

August 27, 2008
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.

August 27, 2008
WS-Addressing Identity Extension Published

Information Card IconIBM 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/.

August 11, 2008
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.

July 4, 2008
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

July 3, 2008
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. :-)

June 28, 2008
First Verified Age Information Cards

IDology Verified Over 18 cardLast week IDology demonstrated a first that many of us see great possibilities for: an Information Card making a verified age claim. I’m excited at this first step towards the goal of enabling people to routinely use interoperable verified claims about themselves via Information Cards.

Obtaining my age-verified card online was easy. I submitted my name, address, and birth date (via a self-issued card) to IDology’s verification process. Next they asked me a few additional questions to confirm that I was likely to be the person who I claimed to be. With correct answers in hand, they proceeded to issue me an Information Card enabling me to make IDology-verified claims on my own behalf.

I used the card at two (demo) relying parties: a social networking site that restricts membership to people 18 and over and an online wine store. You can also imagine verified identity information being valuable at job and career sites, at dating sites, when applying for insurance or credit, for enrolling in promotions, etc. The possibilities are endless.

Please join me in congratulating IDology on this significant achievement. I believe it will be the first of many good things to come in the verified identity space!


The remainder of this post shows the process of obtaining and using my verified identity Information Card. In some cases I intentionally went through extra steps, such as previewing the cards before sending them, to make it completely clear what is occurring. The address of the demo site is obscured at IDology’s request because this is not yet a production service. Some of the (real) data about me used to obtain the card is obscured for privacy reasons.

Signing Up for a Verified Age Card

SocialNet start page

The experience starts by visiting the “SocialNet” site, which invites me to join. I click “Join SocialNet Today”.

SocialNet join page

SocialNet lets me join either by typing my information into a web form or by providing it via an Information Card. I click the Information Card icon.

SocialNet join card selection

This brings up CardSpace, where I choose a self-issued card with my home address.

SocialNet join card preview

I preview the card, seeing that the site will be sent my name, address, and birth date. I click “Send”.

SocialNet verification questions

I’m asked two questions that I should know the answers to to help confirm that I am who I say I am. I answer them correctly.

SocialNet joined

Having passed the identity verification process, I’m given the opportunity to download an Information Card for my newly verified identity. I click on “Download Managed InfoCard”.

Install IDology card

I click the “Install and Exit” button to install my verified identity Information Card.

Using the Card at SocialNet

SocialNet login page

Now that I have a verified age card, I use it to sign in at SocialNet by clicking on the Information Card icon.

SocialNet login card selection

I choose my IDology verified Information Card and click “Preview” to review the claims I’m being asked for.

SocialNet login card preview

SocialNet is only asking for my name and the PPID for my card. I send them.

SocialNet logged in

I’m logged into SocialNet using my verified Information Card.

Using the Card at OnlineWineMerchant.com

OnlineWineMerchant login page

Now I go to another site that accepts my verified age Information Card: “OnlineWineMerchant.com”. I click the Information Card icon to sign in.

OnlineWineMerchant login card selection

My IDology verified Information Card is accepted by the site. I choose it and click “Preview”.

OnlineWineMerchant login card preview

OnlineWineMerchant.com is also only asking for my name and a PPID. (In a real deployment, I suspect it would be asking for an age claim of some kind too.) I send the card.

OnlineWineMerchant logged in

I’m logged into OnlineWineMerchant.com using my verified age card, letting me take advantage of the verification I did for SocialNet on this site too. This is the synergy that will make Information Cards with verified identity claims a valuable addition to the identity landscape.

Next »