What is meant by “token independence”?

I don't want to get sidetracked into a discussion of the nuances the SAML protocol and token independence, but imagine readers will want me to share a comment by Scott Cantor – one of the principal creators of Shibboleth.  He knows something about SAML too – since he was the editor of the Version 2.0 spec.  He is responding to my recent post about why communications protocol, trust system and token payload must become three orthogonal axes:

SAML doesn’t have the problem Kim is referring to either. Both trust model and token format are out of scope of SAML protocol exchanges. The former is generally understood, but the token issue is the source of a lot of FUD, or in Kim’s case just misunderstanding SAML. This is largely SAML’s own fault, as the specs do not explain the issue well.

It is true that SAML protocols generally return assertions. What isn’t true is that a SAML assertion in and of itself is a security token. What turns a SAML assertion into such a token is the SubjectConfirmation construct inside it. That construct is extensible/open to any token type, proof mechanism, trust model, etc.

So the difference between SAML and WS-Trust is that SAML returns other tokens by bridging them from a SAML assertion so as to create a common baseline to work from, while WS-Trust returns the other tokens by themselves. This isn’t more or less functional, it’s simply a different design. I suppose you could say that it validates both of them, since they end up with the same answer in the end.

An obvious strategy for bridging SAML and OpenID is using an OpenID confirmation method. That would be one possible “simple” profile, although others are possible, and some have been discussed.

I'm not sure I really misunderstand SAML.  I actually do understand that the SubjectConfirmation within SAML offers quite a bit of elasticity.  But SAML does have a bunch of built-in assumptions within the Assertion that make it, well, SAML (Security Assertion Markup Language).  These aren't always the assumptions you want to make.  I'll share one of my own experiences with you.

CardSpace supports a mode of operation we call “non-auditing”.  In this mode, the identity of the relying party is never conveyed to the identity provider.

The identity provider can still create assertions for the relying party, sign them, and send them back to CardSpace, which can in turn forward them to the relying party.  If done properly, using a reasonable caching scheme, this provides a high degree of privacy, since the identity provider is blind to the usage of its tokens.  For example, one could imagine a school system issuing my daughter a token that says she's under sixteen that she could use to get into protected chat rooms.  In non-auditing mode  the school system would not track which chat rooms she was visiting, and the chat room would only know she is of the correct age.  This is certainly an increasingly important use case.

My first instinct was to use SAML Assertions as the means for creating this kind of non-audited assertion.  But as Arun Nanda and I started our design we discovered that SAML – even SAML 2.0 – just wouldn't work for us. 

In the specification (latest draft), section 2.3.3 says a SAML Assertion MUST have a unique ID.  It must also have an IssueInstant.  When that is the case, the identity provider can always collaborate with the relying party to do a search on the unique ID or IssueInstant, so the desired privacy characteristics dissipate.

Being a person of some deviousness who just wants to get things done, I said to Arun, “I know you won't like this, but I wonder if we couldn't just create an ID that would be the canonical ‘untraceable identifier’?”  I hesitate to admit this and do so only to show I really was trying to get reuse.

But within a few seconds, Arun pointed out the following stipulation from section 1.3.4: 

Any party that assigns an identifier MUST ensure that there is negligible probability that that party or any other party will accidentally assign the same identifier to a different data object.

I could have argued we weren't reassigning it “accidentally”, I suppose.  But there you are.  I needed a new “Assertion” type – by which I'm referring to the payload hard-wired into SAML. 

It isn't that there is anything wrong with a SAML Assertion.  The “ID” requirement and “IssueInstant” make total sense when your use case is centered primarily around avoiding replay attacks.  But I had a different use case, and needed a different payload, one incompatible with the SAML protocol.  And going forward, I won't be the last to operate outside of the assumptions of any given payload, no matter how clever.

I have looked deeply at SAML, but am convinced that protocol, payload (call it assertion type or token type, I don't care) and trust fabric need all to be orthogonal.  SAML was a great step forward after PKI because it disentangled trust framework from the Assertion/Protocol pairing (in PKI they had all been mixed up in a huge ball of string).  But I like WS-Trust because it completes the process, and gets us to what I think is a cleaner architecture.

In spite of all this, I totally buy Scott's uberpoint that for a number of common use cases SAML and WS-Fed (meaning WS-Trust in http redirection mode) are not more or less functional, but simply a different design. 

OpenID? Huh?

In a posting called “OpenID? Huh?“, Francis Shanahan, whose job it is to worry about high value financial transactions and strong assertions about molecular identity, wonders why OpenID is nothing more than a reinvention of the WS wheel.  

“I don't understand OpenID [LINK].  I'm sorry.  I've tried to understand it but I just don't get it.

“The spec is confusing but thankfully Phil Windley has translated it into a diagram for us mere mortals [LINK].

“The idea of OpenID is to provide “an open, decentralized, free framework for user-centric digital identity.” 

“And here's how the flow works (at least one of the scenarios).  Note I've taken Phil's explanation and augmented it with my own understanding:

  1. User is presented with OpenID login form by the Consumer
  2. User responds with the URL that represents their OpenID (for example “FrancisShanahan.myIDServer.com”). Now the Consumer needs to determine if I actually “own” the URL I've specified.
  3. Consumer canonicalizes the OpenID URL and uses the canonical version to request (GET) a document from the Identity Server.
  4. Identity Server returns the HTML document named by the OpenID URL
  5. Consumer inspects the HTML document header for tags with the attribute rel set to openid.server and, optionally, openid.delegate. The Consumer uses the values in these tags to construct a URL with mode checkid_setup for the Identity Server and redirects the User Agent.  {fs: Said differently, the consumer directs the user to login at their ID server.}   This checkid_setup URL encodes, among other things, a URL to return to in case of success and one to return to in the case of failure or cancellation of the request
  6. The OpenID Server returns a login screen.
  7. User sends (POST) a login ID and password to OpenID Server. {fs: I assume you can authenticate how ever your OpenID server likes}
  8. OpenID Server returns a trust form asking the User if they want to trust Consumer (identified by URL) with their Identity
  9. User POSTs response to OpenID Server.
  10. User is redirected to either the success URL or the failure URL returned in (5) depending on the User response
  11. Consumer returns appropriate page to User depending on the action encoded in the URL in (10)

“Ok, makes sense but there's an obvious problem as Kim Cameron correctly points out in this post [LINK].

“If you assume the Consumer is evil, they can take the openID URL from step 2 and instead of directing the user to that legitimate URL, they can substitute it with their own faker site. This site'll look EXACTLY like the one the user's expecting. The user unwittingly enters their credentials and the scenario continues as normal. The user's never aware that they were phished.

“Clearly there's a piece missing that Kim claims can be provided by the CardSpace ID selector. By integrating OpenID with CardSpace you can avoid malicious redirections and phishing in the protocol. But then what've you actually achieved? You've just re-invented the WS-* wheel all over again using redirects and a browser? So what's the point?

“I don't get it but this is dark mojo and I'm probably missing something somewhere.”

Let me clarify what really happens.  Let's go back to step (2) above.  We know Francis by his blog URL – http://www.francisshanahan.com.  So if he was going to leave comments on my blog, he would most likely use his own blog URL as his OpenID.

Note that his blog URL isn't an identity server.  So in step (3), the consumer doesn't contact an identity server – it requests and gets Francis’ actual web page (or, at least, its header).  As explained in step (5), the header contains a “link” element telling the consumer who to trust as the identity provider for this page.

Now, in steps (5) through (10), the user is redirected to the identity server, enters his credentials, and picks up a coupon that he gives back to the consumer after another redirect.  Behind the scenes, the consumer then sends the coupon back to the identity provider (using a backchannel) to see if it is valid. (There is a potential optimization that can be used here involving exchange of a key – but it is only an optimization).

So let's think about this.  Where is the root of trust?  In conventional systems like PKI or SAML or Kerberos, the root of trust is the identity provider.  I trust the identity provider to say something about the subject.  How do I know I'm hearing from the legitimate identity provider?  I have some kind of cryptographic key.  The relevant key distribution has a cost – such as that involved in obtaining or issuing public key certificates, or registering with a Key Distribution Center.

But in OpenID, the root of trust is the OpenID URL itself.  What you see is what you get.  In the example above, I trust Francis’ web page since it represents his thinking and is under his control.  His web page delegates to his OpenID identity provider (OP) through the link mechanism in (5).  Because of that, I trust his identity provider to speak on behalf of his web page.  How do I know I am looking at his web page or talking to his identity provider?  By calling them up on DNS.

I'm delving into the details here because I think this is what gives OpenID its legs.  It is as strong, and as weak, as DNS.  In other words, it is great for transactions that won't attract criminal attack, and terrible for those that will.

This now brings us face to face with the essence of the metasystem idea.  We don't live in a one-size-fits-all world.  Identity involves different – and even contradictory – use cases.  Rather than some monolithic answer, we need a metasystem in which the cost (in complexity or money) of using identity is proportional to the value of the asset being protected.  OpenID cannot replace crypto-based approaches in which there are trusted authorities rather than trusted web pages.  But it can add a whole new dimension, and bring the “long tail” of web sites into the identity fabric.

The way I see it, there is a spectrum with DNS-based technology at one end and hardware-backed crypto technology at the other.  If we can get this continuum structured into a metasystem, the dichotomy between RESTful and Web Services approaches can be changed from a religious war to simple selection of the right tool for the right task.  That's why I want to see OpenID as an integral part of a metasystem providing a common experience while respecting the economics of identity.

This having been said, Francis is right for asking whether we've “just re-invented the WS-* wheel all over again using redirects and a browser?”.  While I think it is known I'm a strong supporter of SAML as a step forward for identity, I've been an equally vocal advocate of separating communications protocol, trust, and token payloads.  OpenID has a different token payload and trust system than SAML, but if the three axes had been properly disentangled, you could imagine OpenID as a very simple SAML profile.  Because of the entanglement, that can't be the case.

WS-Federation (possibly misnamed…) doesn't have this problem.  It can carry any token, and use any trust framework.  OpenID would work inside the WS-Federation protocol patterns, and would be able to retain its payload and trust structure.  So could SAML for that matter.  So there is the “theoretical possibility” of merging all these things.  Will it happen?  Someone would have to pass out large quantities of pain killers, but there is a possible future in which, over time, they converge.

HelloWorld Information Cards

One of the most important things about the Information Card paradigm is that the cards are just ways for the user to represent and employ digital identities (meaning sets of claims about a subject). 

The paradigm doesn't say anything about what those claims look like or how they are encoded.  Nor does it say anything about the cryptographic (or other) mechanisms used to validate the claims. 

You can really look at the InfoCard technology as just being

  1. a way that a relying party can ask for claims of “some kind”;
  2. a safe environment through which the user can understand what's happening; and
  3. the tubing through which a related payload is transfered from the user-approved identity provider to the relying party.  The goal is to satisfy the necessary claim requirements. 

If you have looked at other technologies for exchanging claims (they not called that, but are at heart the same thing), you will see this system disentangles the communication protocol, the trust framework and the payload formats, whereas previous systems conflated them.  Because there are now three independent axes, the trust frameworks and payloads can evolve without destabilizing anything.

CardSpace “comes with” a “simple self-asserted identity provider” that uses the SAML 1.1 token format.  But we just did that to “bootstrap” the system.  You could just as well send SAML 2.0 tokens through the tubing.  In fact, people who have followed the Laws of Identity and Identity Metasystem discussions know that the fifth law of identity refers to a pluralism of operators and technologies.  When speaking I've talked about why different underlying identity technologies make sense, and compared this pluralism to the plurality of transport mechanisms underlying TCP/IP.  I've spoken about the need to be “token agnostic” – and to be ready for new token formats that can use the same “tubing”.

There have been some who have rejected the open “meta” model in favor of just settling on tokens in the “concept de jour”.  They urge us to forget about all these subtleties and just adopt SAML, or PKI, or whatever else meets someone's use cases.  But the sudden rise of OpenID shows exactly why we need a token-agnostic system.  OpenID has great use cases that we should all recognize as important.  And because of the new metasystem architecture, OpenID payloads can be selected and conveyed safely through the Information Card mechanisms just as well as anything else.  To me it is amazing that the identity metasystem idea isn't more than a couple of years old and yet we already have an impressive new identity technology arising.  It provides an important example of why an elastic system like CardSpace is architecturally right. 

It's sometimes hard to explain how all this works under the hood.  So I've decided to give a tutorial about “HelloWorld” cards.  They don't follow any format previously known to man – or even woman.  They're just someting made up to show elasticity.  But I'm hoping that when you understand how the HelloWorld cards work, it will help you see the tremendous possibilities in the metasystem model.

The best way to follow this tutorial is to actually try things out.  If you want to participate, install CardSpace on XP or use Vista, download a HelloWorld Card and kick the tires.  (I'm checking now to see if other selector implementations will support this.  If not, I know that compatibility is certainly the intention on everyones’ part). 

The HelloWord card is just metadata for getting to a “helloworld” identity server.  In upcoming posts I'll explain how all this works in a way that I hope will make the technology very clear.  I'll also make the source code available.  An interesting note here:  the identity server is just a few hundred lines of code. 

To try it out, enter a login name and download a card (if you don't enter a name, you won't get an error message right now but the demonstration won't work later).  Once you have your card, click on the InfoCard icon here.  You'll see how the HelloWorld token is transferred to the relying party web site. 

This card uses passwords for authentication to the HelloWorld identity provider, and any password will do. 

Continue here…

Tailrank blog links

Tailrank did a nice summary of some of the blogging around our announcement. It's a cools site, where the results look something like this:

 

CardSpace & OpenID: Working together

kveton.com  

Found 4 days ago
The OpenID community has been having quite a few discussions about phishing and what we can do to help mitigate that problem. We have come up with a whole list of solutions that work together nicely to help address the problem. …
 

Microsoft and OpenID – commentary

identity20.com  

Found 4 days ago
Here are other posts on Microsoft and OpenID announcement: Kim Cameron (Microsoft) post Michael Grave (VeriSign) post “this is a significant step toward the convergence needed in the identity space” David Recordon (VeriSign) post “Convergence isn't new for OpenID, rather continues to show how …
 

Microsoft to Support OpenID Log on System

thomashawk.com  

Found 4 days ago
Time, Walk, Step, Turn Hosted on Zooom r [I am CEO of Zooomr] WIRED Blogs: 27B Stroke 6 : In a keynote speech at the RSA security conference earlier today Bill Gates reportedly announced that Microsoft was going to support OpenID. …
 

Microsoft Working on OpenID Support

25hoursaday.com  

Found 4 days ago
It looks like we just announced that we'll be supporting OpenID at the RSA conference. Official details are in the press release Microsoft Outlines Vision to Enable Secure and Easy Anywhere Access for People and Organizations which states To further enable the vision of secure and easy anywhere access, …
 

blogs.zdnet.com  

Found 4 days ago

With the Vista launch behind him, Bill Gates and Craig Mundie, Microsoft's chief research and strategy officer and security patron, were on stage the 16th annual RSA Conference in San Francisco before a crowd of about 15,000 security geeks and professionals. …

 

factoryjoe.com  

Found 4 days ago

You can read it around the web, but, hot on the heels of the creation of the OpenID Foundation , the news from the RSA Security conference is that Bill Gates has announced Microsoft's intention to support OpenID 2. …

 

saunderslog.com  

Found 3 days ago

Sometimes wishes to come true. It was only a few days ago that I posted a rant about Yahoo's decision to impose Yahoo ID's on Flickr account holders . And I was just one of the many voices in the blogosphere raised against Yahoo's decision. …

 

hyperthink.net  

Found 3 days ago

There's lots of buzz in the blogosphere today about the big Cardspace/OpenId collaboration that was announced this morning at RSA. Whodathunk that a technology rooted in the RESTful open source ecosystem could intermingle with a technology built by the WS-* wonks without trigging some bizarre matter/antimatter explosion. …

 

equalsdrummond.name  

Found 4 days ago

User-centric identity infrastructure just took another key step forward today: Janrain, Sxip, Verisign, and Microsoft announced they will all be working together to help OpenID users get the benefits of CardSpace and vice versa. …

 

brad.livejournal.com  

Found 4 days ago

http://kveton.com/blog/?p=221

 

blog.wachob.com  

Found 4 days ago

For those of us who've been helping to promote OpenID, today's announcement that Microsoft will work to get OpenID and Cardspace working well together is absolutely no surprise. Kim Cameron, Mike Jones and the rest of the crew have been saying both very rosy things, as well as giving some well-appreciated constructive criticism. …

 

vecosys.com  

Found 3 days ago

Unbelievably sleepy old Microsoft (we spend $4bn on R&D but has anyone seen a return) beats dithering Yahoo (should we support it or should we buy OpenID) and arrogant Google (we hate OpenID and Microformats, we only use complicated stuff we invent) to officially announce support for the OpenID movement today at the RSA conference. …

 

oreillynet.com  

Found 3 days ago

Just when you thought it was safe to make assumptions regarding whether or not MSFT understood the ” Don't Fight The Internet ” rule of doing business on the 2. …

 

phildawes.net  

Found 3 days ago

Microsoft, Verisign, Sxip and JanRain have announced that they will all support the OpenID protocol in their upcoming products. Kim Cameron has the scoop (but then he would have, being the ‘Chief Architect of Identity’ at Microsoft). …

 

nelh.blogspot.com  

Found 3 days ago

CardSpace OpenID collaboration :

 

daveman692.livejournal.com  

Found 4 days ago

http://netmesh.info/jernst/Digital_Iden

 

benlog.com  

Found 4 days ago

(There's always a dilemma between “publishing soon” and “polishing for peer review.” This is my first attempt at blog-based collaborative peer-review. Let's see how it goes!) The Problem Phishing is a serious issue, and it's only getting worse. …

 

lagesse.org  

Found 3 days ago

This is great news for the OpenID community – having companies like Verisign and Microsoft onboard certainly help the chances of achieving a way to manage your persona on the web! OpenID ( Radar post ) got a big boost today when it gained support from Microsoft . …

 

kaliyasblogs.net  

Found 4 days ago

This morning at RSA Bill Gates and Craig Mundie announced MSFT support of OpenID2.0 . ( Johannes has a good summary of the points they made too ) I wouldn't go so far to say that they got Married. But what exactly was announced? …

 

internet.seekingalpha.com  

Found 3 days ago

Thomas Hawk submits: In a keynote speech at the RSA security conference yesterday, Bill Gates reportedly announced that Microsoft was going to support OpenID. OpenID is an open, decentralized identity system that attempts to provide a solution to the multiple log on ID systems to access various sites across the internet. …

 

chimprawk.blogspot.com  

Found 3 days ago

I'm proud to announce that, as of this morning, we are going to be taking ClaimID in a slightly new direction. We're going to be concentrating our efforts on being an OpenID provider, one that is extremely simple and easy to use. …

 

blog.broadbandmechanics.com  

Found 3 days ago

So I haven't had any time to talk to Kim or Dick – but here's my take on this deal between Microsoft and their CardSpace/InfoCards standards efforts and the OpenID community (Sxip, JanRain and Verisign. …

 

blog.broadbandmechanics.com  

Found 3 days ago

Microsoft and the OpenID community have decided to support each other. In depth coverage here. Congrats to all! THis is important news! Getting Microsoft to recognize and then support an open effort like OpenID is a first step. …

Structuring our announcement

Identity Woman Kaliya, who is a key community figure and has played a pivotal role in bringing everyone together, posted this (and this) about yesterday's announcement:

This morning at RSA Bill Gates and Craig Mundie announced MSFT support of OpenID2.0. (Johannes has a good summary of the points they made too) I wouldn’t go so far to say that they got Married. But what exactly was announced? I spoke with David Recordon and Mike Jones after the announcement. (this picture is before the announcement).

The OpenID Relying parties will be able to request that the authentication be done in a Phising resistant way. Then the OpenID Provider will have it a way to assert that the authentication of the OpenID (a URL or XRI/I-name) has been done in a Phishing resistant way. CardSpace will be available as a primary way of providing this kind of authentication (for users on Windows machines).

This is a very exciting development as it expands the options available to users. Their are issues with Phishing in OpenID (as outlined here by Kim) and addressing this hole is key to making it a viable protocol that is good for users.

Kim talks about is request to the OpenID community in the blogosphere and in the meeting they had last week at JanRain (Scott blogged about that here).

My big ask was to add a way to request credentials based on phishing-resistant authentication…..[so that] the system is built to handle the dangers that would come with its own success.

The one question I have about this collaboration announcement why Cordance, NetMesh and other companies who have made major contributions and have critical stakes in the OpenID community were not listed in the announcement. I know it was pulled together very quickly but I think the contributions of those two companies have been extensive and deserved mention (and yes! they do have ‘code’).

There was also no mention of like Brad Fitzpatrick the originator of the OpenID and his company LiveJournal which is now a part of SixAppart.

This is a good question.  As I pointed out yesterday, NetMesh was one of the orginators of OpenID.  Drummon Reed and Cordance have been big proponents too, and brought their i-names and XRI technology to the party.  Brad proposed the initial concept.  There are lots of creative people and companies who are playing their part in all of this, and I consider most of them to friends.

So since, as Gabe says, everything about this announcement – and identity work in general – should be perfectly transparent, let me share what I was thinking while working on this.

I've been involved in big announcements a number of times, and they take months to pull off.  Every PR department from every company has to get involved.  Each has a constituency and message that it wants to be clear.  Every time a change is made it has to go everyone else for approval, often provoking a further change, and so it just takes time.  You plan well ahead for these things, and commit near full-time resources.

We didn't have that luxury.  Nor was this meant to be PR as such.  It was a matter of the industry shaping itself through collaboration, and doing it in the blogosphere – the only place where these magical things can happen.  The fact that Bill and Craig thought all of this was important and exciting gave us all a sudden opportunity for time travel.

If I wanted this to happen in a short time, I needed to work with representatives, not the whole community, and even then, have a great deal of luck.  But to do this without offending everyone involved, I felt we needed an objective criterion for deciding who to approach to represent the OpenID community.

It seemed to me that the best representatives were the editors of the OpenID 2.0 specification.  After all, they are at the center of landing this baby.  And the editors are David Recordon at VeriSign, Johnny Bufu at SXIP, and Josh Hoyt at JanRain.  Thus the choice of companies.  I felt they would understand the technical issues and possibilities, and that the support of their companies for collaboration would be the beginning – not the end – of a wider process.

So to be perfectly clear, we would love to see more people and companies getting involved in this collaboration and building the momentum going forward.  This isn't the end of the identity journey – just a time-warp in which we all got thrown forward.  So let's work on some of the big announcements I referred to above, and most of all, on really great technology.

Notes on Bill Gates’ Identity Keynote

Many of you know my colleague Mike Jones. He had enough wits about him to take notes on what actually transpired during the keynote earlier today. So I'll share them with you:

The flow of the identity part of the talk went something like this:

  • Slide: Evolution of Identity: Making the Vision Real (with picture of two cards in hands)
  • People are used to choosing what credential to use where for what purpose (talking about cards in our wallets)
  • We use a variety of physical tokens to represent these things
  • CardSpace creates a vehicle to allow people to have a GUI for credentials that represent their identities or personas in particular situations
  • Each thing in the physical world conveys a particular set of information and discloses just enough information
  • CardSpace provides a drag & drop interface for identity
  • People will have to acclimate to it
  • People can create their own credentials and others can give you credentials
  • The system reasons about what the right credential is for you to simplify things for users
  • WS-* hints about what credentials that are being looked for
  • CardSpace shows candidates for credentials

Then they segued to the OpenID collaboration announcement:

  • Issues of reputation and trust are foundational on the Internet
  • Different levels of trust are needed in different contexts, such as blogs and access to enterprise resources
  • People have been thinking about issues of trust
  • OpenID 2.0 is doing this in the blog / Web 2.0 world, others are coming at this from the enterprise space
  • We see these approaches as being complementary
  • “Today we are announcing that we are supporting OpenID 2.0 and that they’re extending what they’ve done to enable the use of strong credentials”
  • They're doing this because they see that it solves problems and attacks that a pure password approach has
  • We're excited about this marriage of CardSpace and Web 2.0
  • This will help eliminate the possibility of man-in-the-middle attacks
  • CardSpace is built on our work on the WS-* specifications
  • OpenID will be endorsing the CardSpace marriage later today
  • We see this as a very smooth continuum with a common GUI metaphor

Numerous enthusiastic comments followed in Mikes rendition…

OpenID Editor David Recordon

Here's what Editor David Recordon has to say:

So with the recent OpenID news, I have to say that I'm quite excited! Convergence isn't new for OpenID, rather continues to show how it is a great technology to innovate around. This isn't about one technology swallowing another, it is about true cooperation, collaboration, and ultimately convergence.At the first Internet Identity Workshop in 2005, Brad Fitzpatrick, Johannes Ernst, and I collaborated with the XRI guys and jointly developed Yadis. Suffice it to say, the technology developed by the community in Yadis is so powerful that it is now being built into the standard XRI Resolution spec at OASIS. Over this last summer there was further convergence with the XRI community, now allowing the OpenID Authentication 2.0 spec to support both URLs and XRIs as identifier formats. In August Sxip joined forces, which has caused the OpenID technology to continue to improve and has built the community to be even stronger.

Now today, we get to announce that Microsoft too has decided to collaborate with the OpenID community. I've known Kim Cameron and Mike Jones for about two years now and despite anything you may say about Microsoft, these guys continue to push for the best and engage the wider user-centric identity community in a very positive light. I'm personally really excited to be working with them, and others, in further developing the Assertion Quality Extension so that OpenID can be used within a wider range of products (including those from Microsoft). So welcome Kim and Mike, I hope to see you on the mailing lists shortly!

Johannes sends “marriage” greetings

Here's more support from another legendary member of the OpenID community, Johannes Ernst of Netmesh.  He's the inventor of LID, and one of the strongest champions for the “URL-based” identity used in OpenID.  He brought ideas his together with Brad Fitzpatrick's quite a while ago now, creating one of the first synergy-lurches for the community.

I should also point out that Johannes has also been one of the first, and most tireless, advocates of the synergy between OpenID and Information Cards.  He has given many cycles to OSIS, the group that has co-ordinated open source work around identity selectors and information card technology.  The beautiful thing here is that convergence with CardSpace MEANS convergence with Information Cards in general, including the Higgins project and work by many others in the community.  I've been concentrating on CardSpace for obvious reasons, but to me it is very important that this goes far beyond CardSpace into another whole community.

Wow! After two years of hard work, we are finally getting real convergence in identity land! Today, Bill Gates is announcing has announced in his keynote at the RSA conference that Microsoft will support OpenID. Here are some posts covering the news:

At NetMesh, we've held for a long time that URL-based identity (OpenID, with its roots LID, i-names and Sxip), and other technologies such as CardSpace have to come together so we can really get to an interoperable, multi-vendor, user-centric identity layer for the open internet. That's why we helped put together OSIS, and lots of activities of that nature.

Now even Bill Gates supports the same vision! Yippie!! (apologies for being too excited, but this is exciting!)

Just pointed out to my wife — who wrote the first line of code, ever, about three years ago, implementing URL-based identity — that in some way, she should now be famous!

So, congratulations Tammy!

Scott Kveton on CardSpace and OpenID

Many of the people adding OpenID support to their blogs and services are using JanRain's libraries.  Scott, the company's CEO, addresses the worry some members of his community may have about a big, powerful company getting involved with the bottoms-up technology they have worked on so hard.  I actually have  a lot of sympathy for this concern, and for peoples’ feelings about the technology they have developed.  If we were coming to “take over”, it would really be bad news for everyone.  But Scott Kveton, Dick Hardt, Michael Graves and myself aren't the kind of people who would let this happen.

What I really like about Scott's comments is the way he focusses, without any bias, on what is good about the component technologies and their synergy.  This is what real engineering is about, in my humble opinion.  It's one of the things that will really drive us towards the Identity Big Bang.  And the whole world will benefit.

OpenID has always been about convergence. When Brad, David and Johannes talked about how OpenID and Yadis could work together over a year ago. When the XRI folks brought their amazing people and technology to be integrated into OpenID 2.0 last Spring. This past Summer when Sxip Identity joined the OpenID party by joining in on developing the specification and offering up their attribute exchange specification to the OpenID community. And now today, we have a commitment from Microsoft to take part in the OpenID community as well as enable the technology for their future identity products.

There are a couple of points I’d like to make outside of the above announcement to hopefully address any concerns that the OpenID community might have:

  • JanRain will never require users of our libraries or services to use Windows CardSpace â„¢. We offer support for this technology as another option for users much like using our Safe SignIn and Personal Icon technologies on MyOpenID.com. We’ll also continue to support the OpenID efforts going on with Mozilla and Firefox.
  • Windows CardSpace â„¢ is shipping with Vista today and is a well thought-out technology that helps address many of the privacy and security concerns that people have had with OpenID. OpenID helps users describe their identity across many sites in a public fashion. The two together are very complimentary products and each has its strength.
  • Microsoft did not cave in to the OpenID community and the OpenID community is giving nothing up to Microsoft. This is a collaboration on bringing the best technology to the marketplace as quickly as possible to help secure users and solve the single sign-on solution once and for all.
  • Please reserve judgment on what this all means until you see it all work together. The technology is really quite simple and the ramifications for end-users is huge. It also goes a very long way to completely addressing the phishing concerns we’ve heard so much about.

Dick Hardt on CardSpace and OpenID

Here is Dick Hardt, CEO of SXIP, explaining our joint announcement on OpenID and CardSpace to people in the community who may worry that Starship Microsoft is about to land on OpenID and squish it. 

This morning Microsoft announced they would support OpenID in future identity server products. Although this is a huge endorsement for OpenID, there will likely be many people that are fearful of what Microsoft’s involvement may do to OpenID.

At ActiveState I worked with Microsoft to bring Perl and Python technology to the Windows platform. This was a win for Perl and Python programmers that wanted to use their tools on the Windows platform. It was also a win for the community at large, as a fair amount of the threading and Unicode support that is in Perl today was funded by Microsoft. Just as I bridged the Microsoft and Open Source worlds back in the 90s,

I look forward to bridging the Microsoft and OpenID worlds today. The team at Microsoft get what we are doing in OpenID, and want to enable their technology to take advantage of the reach of OpenID, as well as enable the OpenID community to take advantage of CardSpace technology. This looks like a win-win for everybody.

Dick's previous Perl work really is a good example of what came about when we “defactionalized” our industry and got momentum going.  The “identity gang” phenomenon has been a good example of the same thing since day one, and this concrete announcement takes things in an even more positive direction.

Let me say something about potential squishing. It just won't happen.  One of the best things about OpenID is its organic quality, and the last thing we want to do is interfere with that.  

My big ask was to add a way to request credentials based on phishing-resistant authentication.  The main idea was to ensure the system is built to handle the dangers that would come with its own success.  As it is more widely adopted, and used for more purposes, OpenID credentials will inevitably become a “honeypot”.  But through the collaboration going on here, and other similar initiatives, we can make sure we'll have the means in place to protect our users even before they are in danger. This in turn is key to preventing a loss of confidence in identity systems and the internet in general.

In the early 1980’s, James Martin said, “Every successful system will attract usage to the point that it becomes unsuccessful”.  He was referring to systems that gobbled up mainframe resources by attracting users until they became bogged down and unusable, but over the years I've thought of his maxim in many contexts.  I think one outcome of today's announcement will be to provide an exception, and that's worth celebrating.