Mike Jones: self-issued

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.

No Comments » Posted under Documentation & Information Cards & Interoperability & Windows CardSpace

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

No Comments » Posted under Documentation & Information Cards & Interoperability & Windows CardSpace

Congratulations 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!

No Comments » Posted under Information Cards & Interoperability & OpenID

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.

2 Comments » Posted under Documentation & Information Cards & Interoperability & Windows CardSpace

Kim 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…

2 Comments » Posted under Claims & Information Cards & Interoperability & OpenID & Phishing Resistance & Privacy & Windows CardSpace

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

1 Comment » Posted under Documentation & Information Cards & Windows CardSpace

Last 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

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

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.

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

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

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.

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

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

Using the Card at SocialNet

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

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

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

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

Using the Card at OnlineWineMerchant.com

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

My IDology verified Information Card is accepted by the site. I choose it and click “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.

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.

4 Comments » Posted under Claims & Information Cards & Windows CardSpace

In May 2005, when I wrote the whitepaper “Microsoft’s Vision for an Identity Metasystem”, these sentences were aspirational:

Microsoft’s implementation will be fully interoperable via WS-* protocols with other identity selector implementations, with other relying party implementations, and with other identity provider implementations.

Non-Microsoft applications will have the same ability to use "InfoCard" to manage their identities as Microsoft applications will. Non-Windows operating systems will be able to be full participants of the identity metasystem we are building in cooperation with the industry. Others can build an entire end-to-end implementation of the metasystem without any Microsoft software, payments to Microsoft, or usage of any Microsoft online identity service.

Now they are present-day reality.

This didn’t happen overnight and it wasn’t easy. Indeed, despite it being hard, the identity industry saw it as vitally important, and made it happen through concerted, cooperative effort. Key steps along the way included the Laws of Identity, the Berkman Center Identity Workshops in 2005 and 2006, the Internet Identity Workshops, the establishment of OSIS, the formation of the Higgins, Bandit, OpenSSO, xmldap, and Pamela projects, publication of the Identity Selector Interoperability Profile, the Open Specification Promise, the OSIS user-centric identity interops (I1 rehearsal, I1, I2, I3, and the current I4), the OpenID anti-phishing collaboration, the Information Card icon, and of course numerous software releases by individuals and companies for all major development platforms, including releases by Sun, CA, and IBM.

Of course, despite all the groundwork that’s been laid and the cooperation that’s been established, the fun is really just beginning. What most excites me about the group of companies that have come together around Information Cards is that many of them are potential deployers of Information Cards, rather than just being producers of the underlying software.

The Internet is still missing a much-needed ubiquitous identity layer. The good news is that the broad industry collaboration that has emerged around Information Cards and the visual Information Card metaphor is a key enabler for building it, together in partnership with other key technologies and organizations.

The members of the Information Card Foundation (and many others also working with us) share this vision from the conclusion of the whitepaper:

We believe that many of the dangers, complications, annoyances, and uncertainties of today’s online experiences can be a thing of the past. Widespread deployment of the identity metasystem has the potential to solve many of these problems, benefiting everyone and accelerating the long-term growth of connectivity by making the online world safer, more trustworthy, and easier to use.

In that spirit, please join me in welcoming all of these companies and individuals to the Information Card Foundation: founding corporate board members Equifax, Google, Microsoft, Novell, Oracle, and PayPal; founding individual board members Kim Cameron, Pamela Dingle, Patrick Harding, Andrew Hodgkinson, Ben Laurie, Axel Nennker, Drummond Reed, Mary Ruddy, and Paul Trevithick; launch members Arcot Systems, Aristotle, A.T.E. Software, BackgroundChecks.com, CORISECIO, FuGen Solutions, Fun Communications, Gemalto, IDology, IPcommerce, ooTao, Parity Communications, Ping Identity, Privo, Wave Systems, and WSO2; associate members Fraunhofer Institute and Liberty Alliance; individual members Daniel Bartholomew and Sid Sidner.

8 Comments » Posted under Bandit Project & Higgins Project & Information Cards & Interoperability & Pamela Project & People & Phishing Resistance & Windows CardSpace

Sean Nolan, chief architect of Microsoft’s HealthVault service, posted an article about giving their users choice for the identities they use to access their information. He announced that in addition to accepting LiveIDs, HealthVault is about to start accepting OpenIDs from two OpenID Providers and is also building native Information Card support. As Sean wrote:

As we’ve always said, HealthVault is about consumer control — empowering individuals with tools that let them choose how to share and safeguard their personal health information. OpenID support is a natural fit for this approach, because it allows users to choose the “locksmith” that they are most comfortable with.

You can certainly expect to see more such options in the future. For example, we are in the process of building in native support for Information Cards, which provide some unique advantages, in particular around foiling phishing attempts.

Talking about OpenID, Sean also wrote:

As we learn more, and as OpenID continues to mature, we fully expect to broaden the set of providers that work with HealthVault. We believe that a critical part of that expansion is the formalization and adoption of PAPE, which gives relying parties a richer set of tools to determine if they are comfortable with the policies of an identity provider.

Please join me in congratulating the HealthVault team on being the first Microsoft service to employ OpenID and for their commitment to providing their users convenient, secure access to their healthcare data.

2 Comments » Posted under Information Cards & LiveID & OpenID & Phishing Resistance

While gone phishing, I discovered that the use of JavaScript puts one barrier up that phishers have to overcome to impersonate a legitimate site. In a characteristically hilarious post, Paul Madsen points out that, besides having to overcome active defenses like Sxipper (“Down girl!”), phishers may also inadvertently present pages localized for their locale, rather than the victim’s.

Intrepid identity adventurer though Paul may be, this stopped him dead in his tracks:

Of course, maybe Paul’s German was better than he thought, as the page was urging him to “Gehen Sie auf Nummer sicher! Schützen Sie sich von Phishing und Identitätsdiebstahl.” – “Go safe! Protect yourself from phishing and identity theft.” :-)

No Comments » Posted under OpenID & Phishing Resistance

Fun Communications’ site idtheft.fun.de lets you mount your very own man-in-the-middle based phishing attack against the OpenID provider of your choosing. Rather than redirecting you to the OpenID provider you specify, it instead redirects you to a page impersonating the OpenID provider, created using content scraped from the real site behind the scenes.

This is the same kind of attack shown in Kim’s phishing video. idtheft.fun.de lets you have the fun of doing it yourself!

I tried it myself with several OpenID providers I use. Predictably, I was typically able to “steal” the passwords for OpenIDs when logging into them with passwords and hijack the resulting logged-in sessions. “Protecting” an account with a one-time-password (OTP) device did nothing to stop this; my “attack” still succeeded in hijacking the session established using a password in combination with an OTP value.

Two things did defeat these attacks. Because Information Cards generate site-specific sign-in information and the attacker’s site is different than the authentic site, even when I was “tricked” into submitting an Information Card to the imposter site, it didn’t give the imposter the ability to log into the real site. No shared secret was present to steal and no session was established to hijack.

The other thing that defeated this specific attack was the use of JavaScript in the sign-in process by the OpenID provider. While a slightly more sophisticated attack could almost certainly get past this obstacle, idtheft.fun.de apparently doesn’t correctly mimic JavaScript site features like “Sign In” buttons invoking an onclick method.

This ability to both phish passwords and hijack the resulting logged-in sessions is exactly why I and others are working on finishing the OpenID Provider Authentication Policy Extension (PAPE) extension. As I wrote when the first draft was published, PAPE enables “OpenID relying parties to request that a phishing-resistant authentication method be used by the OpenID provider and for providers to inform relying parties whether a phishing-resistant authentication method, such as Windows CardSpace, was used.” It’s time for PAPE to become an OpenID standard.

What follows are screen shots from a successful phishing attack and a thwarted one – both against the same OP. The difference is whether passwords or Information Cards were used to log in.

Figure 1: About to mount my attack against my OpenID at myopenid.com. I’ve typed the URL of my OpenID into the relying party.

Figure 2: Next, I’m logging in with a password. An observant user could notice several things wrong: the address bar shows the imposter’s URL, the imposter’s URL is present in the “You must sign in to authenticate to …” message, and the “Your Personal Icon” space is blank. Unfortunately, there is strong evidence that users are not observant.

Figure 3: Phishing already accomplished. Same cues are present that something’s amiss. Of course, a more sophisticated attack could replace the imposter’s URL in the page with the “real one” in both of these screens, eliminating the most obvious cue. I scroll down and click “Allow Once”.

Figure 4: Result after being redirected back to the “relying party”. Yes, that was my real password.

Next, I tried to attack my account again but was surprised that I wasn’t asked to log in this time. Of course – the attacker’s session was already logged in! So I signed out as the man-in-the-middle (that was weird), enabling me to try again.

My next steps looked just like Figures 1 and 2, except instead of typing a password I clicked the purple Information Card button. This brought me to:

Figure 5: CardSpace informs me that I’ve never sent a card to this site before. An observant user would realize that they don’t normally see this screen and might decline. But then, we’ve already discussed how observant users aren’t. I click “Yes”, choose the card I normally use to log into myopenid.com, and send it.

Figure 6: Phishing prevented. “Error processing Information Card token” isn’t the most informative error message I’ve ever seen but behind it is great news: the phishing attack failed because the token constructed for the imposter site wasn’t usable at the real site.

And thanks to idtheft.fun.de, you can try this at home!

14 Comments » Posted under Information Cards & OpenID & Phishing Resistance & Windows CardSpace

Johannes Feulner of Fun Communications recently showed me three different identity sites they’ve created, each fun and valuable in its own way. The first, www.webcard-loyalty.com, lets companies create online loyalty cards for their customers. These loyalty Information Cards enable merchants to offer bonuses and discounts when the cards are used, similarly to how physical loyalty cards such as frequent flyer cards and frequent shopper cards are used to provide these benefits in the offline world. You can read more about “virtual loyalty cards” and about the innovation prize they won.

The second, openidbycard.com, dynamically creates a site-specific OpenID to use at an OpenID relying party from any Information Card offering the privatepersonalidentifier (PPID) claim. Type “openidbycard.com” as your OpenID identifier into any OpenID login form and an OpenID will be created for the site based on the site identity and the PPID returned by the card. While I understand value of using public identifiers (such as self-issued.info) in some contexts, it’s great to also have the choice of using unidirectional identifiers at OpenID sites.

Finally, idtheft.fun.de demonstrates the ability of attackers to mount man-in-the-middle attacks against OpenID sites (and lets you try it yourself!). The site phishes OpenID passwords and other information sent through the browser, all via web pages that look authentic, but that are actually under control of the attacker. This will be the subject of my next post.

No Comments » Posted under Information Cards & OpenID & Phishing Resistance

As reported in InternetNews (and brought to my attention by Tony Nadalin), IBM has expanded the scope of its Tivoli Federated Identity Manager product to include support for Information Cards and OpenID. This is a fantastic development, as it puts software enabling use of these user-centric identity technologies into the hands of IBM’s numerous important customers, ranging from enterprises to Internet businesses. Congratulations to IBM and the Tivoli team for this significant achievement!

No Comments » Posted under Information Cards & OpenID & Software

I was just reading Ryan Janssen’s post Becoming an RP with the Pamela Project (pt. 1) and when I got to the end where he wrote “Since it’s going to take a few hours to get my SSL cert issued and installed, I think I’ll post this and go outside for a break!” it reminded me of the certificate odyssey I went through in April last year. After eventually getting the certificate created and installed, I wrote this about it at the time to Stuart Kwan (hip Internet terminologist):

Getting and installing the certificate was an unbelievable odyssey. It was an *incredibly complicated* process, that in my case, involved many visits to Network Solutions’ and GoDaddy’s support sites, several hours of my afternoon on Saturday, using cryptic openssl commands on Linux to create a key pair and a cert signing request (and later to strip the password off the key pair so Apache would start without the password), lots of help on IM from Pam Dingle, and the creation or use of 6 different passwords. Oh, and the cert wasn’t even installed by that point!

And it would have been *so easy* to get any of the steps wrong and have a cert request that was incorrect or to obtain a cert that didn’t do what I wanted it to. I understand the value that certificates provide (and it’s substantial). But we, as an industry, haven’t exactly made it easy for people to obtain and use them…

I’m tempted to blog about that, but I won’t… :-)

But seeing that Ryan is about to go through the same odyssey, I’ve reconsidered, hence this post. I’m now eagerly awaiting part two of his description to see how his experience compares to mine.

Of course, now that CardSpace and other identity selectors have support for no-SSL sites, hopefully this will be an optional odyssey soon – employed only when the security benefits of SSL certificates are called for. I know that Pamela plans to add no-SSL support to PamelaWare for WordPress soon, so after that, the pain that I went through and that Ryan’s in the midst of during a beautiful sunny day on the Lower East Side can be a thing of the past.

4 Comments » Posted under Information Cards & Pamela Project & Software & Windows CardSpace

Today CA published the whitepaper “CA and Microsoft Support for User-Centric Identity and the Identity Metasystem” in which they describe their shared vision with Microsoft to build the Identity Metasystem. In particular, the whitepaper describes CA’s plans to enable SiteMinder customers to authenticate to resources protected by SiteMinder using Information Cards and to enable claims to be delivered to applications. Read Jeff Broberg’s introduction to the paper and the whitepaper itself.

This is a fantastic development for the Identity Metasystem, as SiteMinder is a key component of the identity infrastructure for numerous businesses large and small across heterogeneous platforms, including some of the largest consumer web sites. I can’t wait to see the valuable and creative uses of Information Cards that will result from CA’s commitment to the Metasystem.

4 Comments » Posted under Information Cards & Software

33 Companies…
24 Projects…
57 Participants working together to build an interoperable user-centric identity layer for the Internet!

Come join us!

Tuesday and Wednesday, April 8 and 9 at RSA 2008, Moscone Center, San Francisco, California
Location: Mezzanine Level Room 220
Interactive Working Sessions: Tuesday and Wednesday, 11am - 4pm
Demonstrations: Tuesday and Wednesday, 4pm - 6pm
Reception: Wednesday, 4pm - 6pm

3 Comments » Posted under Bandit Project & Firefox & Higgins Project & I-names & Information Cards & Interoperability & JanRain & OpenID & Pamela Project & Phishing Resistance & Shibboleth & Software & Windows CardSpace

Congratulations to Gerald Beuchelt of Sun Microsystems and the rest of the OpenSSO team for their release of Information Card support in OpenSSO. As Gerald wrote:

It took quite a while, but by now it is out. Please welcome the Windows CardSpace Information Card extensions for OpenSSO:

https://opensso.dev.java.net/source/browse/opensso/extensions/authnicip/

When I started working on this last spring, I was not even hoping to see this released in open source and part of the OpenSSO extensions family in less than a year. It took the goodwill and talent of quite a few people to get this off the ground, but with the public release of this code and the upcoming OSIS interop during the RSA conference, OpenSSO is now “speaking ISIP” …

Just in time for the in-person interop testing at RSA!

No Comments » Posted under Information Cards & Interoperability & Software

I recently encountered Ryan Janssen’s insightful series entitled “The History of Tomorrow’s Internet” and immediately read the whole thing in one sitting. Among other gems, I found in it the clearest explanation of the value and promise of XRI/XDI that I’ve ever read. Great stuff!

The most recent installment detailed his experiences of “how it feels for a regular person to use Cardspace”. In particular, he documented his experience of using CardSpace for the first time to leave a comment on this blog. He introduced his narrative with:

… as someone who’s business it is to build great software, I KNOW how hard good UI is. Believe me, I work with a GREAT product team and we try REALLY hard to make intuitive software and we fail EVERY day. Having said that, this post isn’t going to paint a real pretty picture.

I’ll let each of you read his blow-by-blow narrative yourself. He closes with:

So what’s the final analysis? Well, as I stated in the beginning, the purpose of this post isn’t to bash Microsoft or Cardspace. Like I said, I build software and when I actually see a normal person use it for the first time, I’m inevitably embarrassed at how difficult it is. Software is hard and Cardspace is brand new. Nonetheless, this does show how far the technology has to go before Mom and Dad are going to be using it. Usernames and Passwords are UBIQUITOUS. We’ve been trained on the visual metaphors for at least a decade. Replacing that with ANY other paradigm is going to rough. To have any chance of success, the Cardspace workflow will need to be much improved.

Because I’m a member of the CardSpace team, I can say that as much as the team is understandably proud of what they accomplished in V1, they’re also pragmatic realists who are fully aware of the issues that Ryan documents so well and the vital importance of addressing them in our future releases. It’s exciting participating in that very process on the fifth floor of Microsoft building 40, day in, day out, as the team defines and refines what the next release will contain. Greatly improved usability is certainly one of our highest-priority goals.

I know that Ryan has also motivated Pamela and me to take a look at how the flow on the blog can be improved. PamelaWare for WordPress isn’t even yet a V1 release (it’s at v0.9 currently) and I know Pamela has lots of ideas on how to improve it. Ryan’s experiences will certainly help inform the next release.

Also, I’ll remark on these excellent observations:

Ready to post? Not yet. Since my iCard is self-issued, Mike’s site (yes, the site is called self-issued.info ironically enough) doesn’t trust me and has now decided that I need to verify my email address. This is obviously a little annoying, but it brings up a good use-case for the first Claim Provider–one that has verified my email address, home address, and phone numbers, so I NEVER have to respond to an email or text message like this again.

Asking the user to verify his or her e-mail address is a way of obtaining a backup means of authentication that can be used in the case where user has lost his Information Card. Just like many accounts backed by passwords use e-mail in the “lost password” flow, PamelaWare uses e-mail to the user in the “lost card” flow and verifies ownership of the e-mail address at account creation time. Ryan correctly points out that if I had received a verified e-mail address as a claim there’s several steps we could have skipped. Making this scenario a reality is one of my personal goals for the Identity Layer we’re all building together.

There’s nothing like real user data to inform what needs to happen next. Thanks, Ryan, for taking the time to provide it to all of us. I look forward to reading the next installment of the series!

No Comments » Posted under Claims & Information Cards & Pamela Project & People & Windows CardSpace

Thanks and congratulations to Axel for his new release of the Firefox Information Card add-on that tames all that JavaScript Kung Fu with ease! I’ve updated the pertinent OSIS interop results page from “Issues” to “Works”.

3 Comments » Posted under Firefox & Information Cards & Windows CardSpace

Two important identity interoperability demonstrations will occur at RSA two weeks from now: the OSIS User-Centric Identity Interop and the Concordia Multi-Protocol Federation Interop. During both you’ll see different projects and vendors publicly showing their identity software working together. But what you won’t see at the conference is what’s happening right now – the engineers behind these implementations working together to refine their deployments and their software to ensure that solutions that should work together in theory actually do in practice.

Like the previous OSIS Interop, the current one is testing both Information Card and OpenID implementations – sometimes in combination. I’m especially excited about this Interop for three reasons. First, the set of participants has expanded again by over 50% and includes many commercial deployments of these relatively new technologies. Second, much deeper testing is occurring than ever before. Thanks, in part, to significant efforts by Pamela Dingle and the Microsoft Identity Lab team, during this Interop not only are people trying their implementations with one another’s – they’re also systematically testing their support for an important range of protocol features using interop endpoints designed and deployed for this very purpose. Third, this Interop won’t end when the conference ends. Most of the participants plan to leave their endpoints up after the conference is over, enabling new participants to join and test later and for existing participants to re-test their implementations against the others when they deploy new versions. Visit the OSIS Interop demonstrations in person if you can, especially between 4:00-6:00 on both Tuesday and Wednesday during the conference.

The Concordia Interop is showing the use of Information Cards to sign into both SAML 2.0 and WS-Federation based federations. Both these federations are using SAML 2.0 tokens carrying consistent authentication context information. (I believe that this is the first public demonstration of WS-Federation implementations using SAML 2.0 tokens.) Furthermore, the Concordia Interop demonstrates the ability to bridge between WS-Federation and SAML federations, allowing identities originating in one to be used to authenticate to services in the other. Visit the Concordia workshop during the conference on Monday from 9:00-12:30.

Finally, I’m not the only one excited by these Interops. Axel Nennker, Francis Shanahan, Gerald Beuchelt, Prabath Siriwardena, Scott Kveton, Vittorio Bertocci, and Will Norris have all written about the upcoming OSIS Interop. There’s also a press release from the Concordia project. Hope to see many of you at RSA!

2 Comments » Posted under Federation & Information Cards & Interoperability & OpenID