Jackson Shaw knows as much about identity management as anyone. I very much value his thinking. If that weren't enough, there is that irresistable love of life that sweeps everyone into his energy field. I think it comes through in his new blog:
No, it's not another French post from Jackson. Tonight I did something a bit different. I headed over to the Capital Hill Art Center in downtown Seattle to watch . There were 21 speakers scheduled including Scott Kveton the CEO of the folks behind . As you probably know, my buddy Kim Cameron is the man behind the curtain for Microsoft's CardSpace initiative ( I guess I should stop calling it an initiative – it is actually part of Vista now) and at the RSA conference Microsoft announced that CardSpace would be interoperable with OpenID.
I thought since Scott was going to present I might as well go over and see what all the hub-bub was about. The format of the evening was interesting in itself. Presenters had 5 minutes – only – to present their 20 slides! That's 15 seconds a slide. Scott was third presenter in the first volley of speakers. The first talk was from Matthew Maclaurin of Microsoft Research on Programming for Fun/Children/Hobbyists/Hackers. The second was from Elisabeth Freeman (Author in the Head First Series, Works at Disney Internet Group) on The Science Behind the Head First Books: or how to write a technical book that doesn’t put your readers to sleep. Then Scott was to speak.
First, I was shocked to walk into this “art space” that was packed to the rafters with people. Was I in the wrong place? Apparently not. On the website they stated the space would hold 400 people and it was jam packed. I had this vision of a few people sitting around some tables chatting. Not so! It was pretty cool; folksy; kinda out there but very engaging. Second, what was I going to get out of a 5 minute talk? Well, the speakers kind of had the pressure on them to make their points. The ones that I saw all got to the point quickly and they all engaged the with the audience, did their thing and got off.
Check out my photos on Picasa if you want to see the shots I took which included many from Scott's talk. So, what did I learn from Scott's talk?
OpenID is single sign-on for the web
Simple, light-weight, easy-to-use, open development process
Decentralized
Lots of companies are already using it or have pledged support
12-15M users have OpenIDs; 1000+ OpenID enabled sites
10-15 new OpenID sites added each day
7% growth every week in sites
Scott predicts that in 2007 there will be 100M users, 7,500 sites, big players adopt OpenID and that OpenID services emerge. Bold predictions but something that is viral, like OpenID has a shot at it.
I have to say I was impressed. Scott finished up with a call to action that included learning more about OpenID at openidenabled.com. I'm definitely heading over there to learn more.
Jackson just “gets” the potential for contagion into the enterprise – assuming we can use OpenID in the proper roles and with the right protections. Corroborates for me the possible “charging locomotive effect”. People shouldn't be caught looking the wrong way.
As for the numbers Scott threw out, I think they are very achievable.
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.
These new documents are too low-level to be of interest to people working on the practical issues of deploying Information Cards on their Web sites.
But they may be of interest to students, researchers and the intrepid souls who really want to get their hands dirty and understand the nitty-gritty of the underlying technical elements.
The latest and most accurate version of “A Technical Reference for the Information Card Profile V1.0” is available for download here. In addition, I've posted a new version of “A Guide To Interoperating with the Information Card Profile V1.0” since it had a few grammatical errors and an inaccuracy in one of the examples – the URI of the self-issued IP claims was incorrect.
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.
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.
I'd like to share this interesting comment by Francis Shanahan, who works on identity from the vantage point of Citi:
“Your blog talks about “Cardspace enabling Apache”. Regarding the language in the post, I know I'm being picky here but…
“Wouldn't it be more correct to say “XML Tokens as an additional authentication…” rather than “…Information Cards as an additional authentication mechanism…” since I can use Kerberos or SAML tokens with Cardspace over WS-Fed.
“Wouldn't it be more correct to say “token enable” rather than “Cardspace enable”? I don't need to use the Cardspace selector with a WS-Trust enabled site.
“Wouldn't it be more correct to say “The whole identity token processing can…” rather than “The whole cardspace processing can…” and so on. CardSpace is just the ID selector used to faciliate the token exchange.
“Just don't want to confuse folks thinking there's a Cardspace specific token.”
First I'll say that technically speaking I think you make good points, and I'll try to be as careful as I can to bring out these ideas.
Then, since pointing the finger at someone else is so fashionable, I'll say I was quoting what another company said it was doing. (That, in itself, is interesting.)
But most important, I'll argue that the simplification of our current ideas into “iconic” notions is inevitable, and worthwhile, even though subtleties will be lost. So we have to achieve a balance between the irreconcilables of breadth and accuracy.
I'll start with an analogy – the analogy to file and folder icons. Computer scientists know files are potentially complex mappings of streams of bits onto blocks of storage. They know folders are doubly linked lists of pointers to these streams of bits. But if they're smart, they keep all of this to themselves – even when they're with other computer scientists and the door is closed. If we told people about the inner workings of file systems, we'd drive them crazy. In fact, they still wouldn't know how to manage documents or pictures or music.
Instead, people have gotten used to little pictures of files, and drag them from one “folder” to another – or even “onto” their mp3 players. Our official help files say things like “Double click on the document to open it”. We conveniently overlook the fact that the document exists as magnetic fields on the hard disk and you can't double click them.
There is a dualism between the science of the thing and the way we conceive of it in usage, just as there is in all aspects of reality.
When we invent new technologies, we start from the science, and it's really hard to explain what one is doing. It takes months or even years to develop an “elevator pitch” – the ten second description of what you've done that makes it seem worth doing. But that doesn't actually matter much, assuming you get funding. What matters is the way the idea eventually enters mainstream consciousness.
It is inevitable that marketers will talk about products (CardSpace, Higgins, etc) rather than technology.
While people will “get” that something is being transferred when you authenticate or authorize, I suspect they'll always see the visual image as being the identity itself, with few understanding it as “a means to manage the metadata enabling connectivity between identity providers and relying parties”.
I think protocols like WS-Federation and WS-Trust will be more or less invisible except to backbone engineers.
Once we get an Information Card icon out there and people start to use it, I think people will take it as meaning “Information Cards accepted here” – and that, in their minds, will be synonymous with CardSpace or whatever Information Card selector they run on their devices. They'll realize that some sites want some cards and other sites want others, but will never think about token types.
So my reading is that Ping, which developed the Apache product being referred to, is already thinking about how to present a message that begins to deal with taking Information Cards to a wider audience. Not out of the technology ghetto yet, but to a wider audience within the very busy technology community. It would be interesting to hear what Andre Durand has to say about this.
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. …
Yesterday I referred to a mind-altering announcement from Ping Identity Corporation. I think it's a key piece of the identity puzzle. Since it's obvious that this is a big accomplishment and that he's played a major role in it, I'll quote Ashish Jain's Identity TIcker blog:
Thanks to the efforts of our labs team, we finally have the ‘Apache Authentication Module for CardSpace‘ available for download .
Here is the product description from the SourceID website:
“The Apache Authentication Module for CardSpace is an open source module that allows applications using an Apache server for hosting or proxy to use Information Cards as an additional authentication mechanism. It allows the Apache applications to act as CardSpace relying parties (RP) by means of simple configuration. The module is responsible for decrypting the tokens submitted by CardSpace, retrieving the claims and making them available for the applications’ use.â€
The idea behind this is simple. If you have an application that is deployed on an Apache server and you want to CardSpace-enable it, drop in the module (along with the dependencies), change the httpd.conf and your application should have access to the claims in the infocard.
The postincludes proof that these guys were coding twenty-four hours a day.
To my mind this is really huge. I wonder if one day we'll see it become a part of Apache, just like the password and digest authentication modules.
The whole cardspace processing can be a black box for the administrators
The module puts the attributes in the session. So if you have a PHP application, you can do the following to retrieve the attributes
The same thing works in any other programming language, since they all give you access to your environment variables.
So this is pretty much as simple as it gets. I hope everyone with a product that runs on Apache will look at this.
But wait! There's more! When I wrote to Ashish to congratulate him on this development, he added:
We also have a .jar file for java that serves the similar purpose (we internally refer it as the cardspace-magic.jar and we will open source some day). Same idea…drop the .jar file in, then:
xmltoken in -> attribute’s map out
So if you use Java, you can go that way too.
But wait! There's still more!!
Yes, folks, Ping Identity is actually showing a demo at RSA of some of the very ideas we've been discussing over the last couple of days. Namely, use of CardSpace to log in to OpenID sites. I'll do another post to sow you some screen shots.
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.
