To understand this discussion, start here and then follow the continuation links until you return to this posting. Click on the images below to see a larger and more readable version.
In the demo, as shown in the following screen shot, only the HelloWorld card is illuminated – all the other cards were “greyed out” as inappropriate:
This happened because in the Information Card login page, the “relying party” expressed a requirement that a HelloWorld card be presented. This was done by embedding “policy” in the “object tag” that tells the browser (and through it, CardSpace) what Information Cards will be accepted. To drill into this, let's look again at the login page:
Here's the HTML that created it:
You'll see that one of the PARAMs in the OBJECT tag is “tokenType”. It's set to a completely arbitrary value – one I made up to show you can do whatever you want – of http://kcameron11/identity/helloworldToken, Since I specified this specific token type, only Information Cards that support it will illuminate at selection time when you go to this web page. Further, the other PARAM specifies “requiredClaims”. Only Information Cards that support these values will be possible candidates.
To understand this discussion, start here and then follow the continuation links. Click on any of the images below to see a larger and more readable version.
When you pressed the “Install” button on the “try it” page, you would have seen the normal “Open or Save” dialog:
If you then clicked “Open”, CardSpace would have brought you the standard “Reputation and Privacy” dialog, showing the certified details of the HelloWorld identity provider, and asking if you want to install its card:
Armed with your new card, you would have begun the “usage” demo by going to the HelloWorld information card login page:
Clicking on the InfoCard image to log in, CardSpace would have shown the “Relying Party Reputation and Privacy” page for Identityblog. (If you normally use InfoCards at Identityblog, you won't see it. In order to avoid “clickthrough syndrome”, it only shows up when you start a new relationship with a relying party.)
Once you approve starting the identity relationship, you are taken to your CardSpace card selector, and your HelloWorld card will be illuminated, since in this demo, the relying party has asked for that kind of card:
When you click on the card, you can preview what will be sent to the relying party should you opt to proceed. To get any information out of the HelloWorld identity provider, you need to authenticate to it. The first version of CardSpace supports four ways to do this (more in a later piece). This demo uses the simplest mechanism – entering a password within the protected CardSpace environment:
Now you'll have a chance to review the contents which will be sent from the identity provider to the relying party:
The contents include “favorite snack” – an attempt to show the elasticity of the contents. If you decide to proceed, the HelloWorld token is transfered to the relying party, which displays it verbatim:
For those who are multi-tasking as they read this, I'll show the token full size to make sure the format and contents are as clear as possible.
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.
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:
User is presented with OpenID login form by the Consumer
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.
Consumer canonicalizes the OpenID URL and uses the canonical version to request (GET) a document from the Identity Server.
Identity Server returns the HTML document named by the OpenID URL
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
The OpenID Server returns a login screen.
User sends (POST) a login ID and password to OpenID Server. {fs: I assume you can authenticate how ever your OpenID server likes}
OpenID Server returns a trust form asking the User if they want to trust Consumer (identified by URL) with their Identity
User POSTs response to OpenID Server.
User is redirected to either the success URL or the failure URL returned in (5) depending on the User response
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.
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
a way that a relying party can ask for claims of “some kind”;
a safe environment through which the user can understand what's happening; and
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.
be user-friendly, i.e. it should pass the mother-in-law test; and
work on the web platform without special software or browser plugin
“So, why is this suddenly a problem?
“Not really, phishing is a perennial problem on the Internet that researchers and developers have been trying to solve for many years now. OpenID just accentuates it because RPs are unregulated. You don’t need any agreement with any OP, essentially anyone can set up a web site and put the OpenID login button. If OpenID takes off, RP sites will grow like ’shrooms and user will get used to the idea that if they see the OpenID logo, they can type their URL to login. This only makes it harder for users to discern the good RPs from the bad ones.”
Actually, the problem is worse than the one we currently face. We are not just dealing with “the perennial problem”. If you use one OpenID account to go to two hundred sites, the thief who steals your OpenID credentials gains access to any of the 200 sites. That's new.
“This is really a social problem, and not a fault of the OpenID protocol. Users need only to trust their OP, and not the RPs that they interact with. If a rogue RP sends you to a page the poses as your OP but the URL doesn’t match your OP’s, you bail out. Doesn’t that sound simple? Well, the cold hard fact is that phishing works and there is research1 to prove that people get tricked very easily.”
Dready's right about the research. But rather than calling it a “social problem” I'd call it a “social engineering attack”. Further, there is a protocol problem. The protocol is based on telling the RP where the OP is located – such that an evil site can automate a “man in the middle attack”. Some other protocols, including the one used by CardSpace, do NOT have this problem. That's why combining CardSpace and OpenID is useful.
“Numerous ideas to mitigate phishing attacks have been floating around the OpenID list and on the OpenID mini-blogsphere. Ben Laurie argues for a client-side solution:
‘Authentication on the web is broken, and has been for a long time. The OpenID fanboys want OpenID to work on any old platform using only standard software, and so therefore are doomed to live in the world of broken authentication. This is fine if what you protect with your OpenID is worthless, but it seems clear that these types of protocol are going to be used to authenticate for things of value.
…
'This is the root of the problem: if you want to protect anything of value, you have to do better than existing Web solutions. You need better client-side software.’
“The picture is not so sunny, however, because most users:
won’t know / bother to install specialized plug-in or upgrade their browsers unless they’re forced to
won’t know the difference between citibank.com/signon and citibank.com-banking-foobar.com
“And even if they installed those anti-phishing toolbars and what not, they still fall for it!
“While I can’t decipher the wirings of the mums-and-dads who fall prey for phishing attacks, I know that I get lazy sometimes and just don’t bother. Then I remember this little trick that Firefox introduced to ensure that users get the warning before installing extensions — Introduce a delay in the dialog box before it can be dismissed. That sort of worked for me, at least for that 5 seconds I can’t click so I might as well read a little.” (Code follows here…)
This may help Dready and in that sense it may be a welcome finger in the dike. But as OpenID becomes successful and is used for sites of value, this kind of solution clearly won't stand up to attack or scale to embrace the population.
People really need to think about what it will mean to actually have “single signon”, rather than just talk about it.
You cannot overestimate the value of your single signon credentials, or the extent to which they will attract attack.
I don't think browser-based solutions will do anything for us long term – the whole point of browsers is to make it easy to introduce cool new behaviors and empower the RP to give the user great experience. They are vulnerable because they put the RP in control – by design.
This doesn't mean plugins can't play a role in getting us to our destination. But ultimately, you need defense in depth, many layers of defense. If we think of the browser as a “broadband communications channel” inundating the user with information, we also need a “narrowband communications channel” honed to protection of the user. The CardSpace work represents an attempt to create this.
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. …
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 …
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. …
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, …
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. …
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. …
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. …
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. …
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. …
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. …
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. …
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. …
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). …
(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. …
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 . …
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? …
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. …
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. …
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. …
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. …
I love Tailrank and its little pictures of blogs as this page on the CardSpace OpenID Collaboration Announcement shows. I wonder how long the pages persist? I'll have to remember to come back and look at this link in a couple of months.
Meanwhile, I thought I would explore Tailrank further and got to the part where I had to sign in and said to myself, “No, I don't have time for that”.
Then it occured that this was just one more concrete example of a Web 2.0 opportunity going down the drain.
It seems so clear to me the Web 2.0 community should climb on board this user-centric identity thing ASAP.
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:
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.
Gabe Wachob claims a certain clairvoyance in this post. But I don't want anyone to underestimate the drama even for me. Friendly discussion is slightly different from everyone actually landing on the same page.
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.
Today, there was an announcement (see Scott Kveton, Dick Hardt, Michael Graves, David Recordon, Johannes Ernst, or Kim Cameron for details) that Janrain, SXIP, Verisign and Microsoft ” will collaborate on interoperability between OpenID and Windows CardSpaceâ„¢ to make the Internet safer and easier to use.” Let me assure you that from personal experience I know the parties involved all want to make OpenID and Cardspace succeed – the agendas here are amazingly open and transparent.
This is a big deal folks – i encourage you to read those blog entries, rather than have me summarize it here. Apparently Bill G even spoke about openid at the RSA keynote this morning!
Gabe was also part of an IPR podcast that sounds interesting and is described here.
There's a nice piece on the announcement in O'Reilly Radar here.
