Tim Bray’s recent comments about OpenID and Sun’s newly announced plans for deploying OpenID there signal the development of an important step up for the OpenID ecosystem. Now, I’ll allow that there may be OpenID servers out there already that have been spun up as authoritative regarding the employment status of owners of the URLs managed by that server (if you know of any, please leave a comment here pointing to it!). But I think it’s safe to say that Sun is by far the biggest and most prominent company to make assertions like this:
Any OpenIDs authenticated by this OpenID provider are employee of this organization.
When openid.sun.com is rolled out, then, the rest of the OpenID community will be able to trust — based on the claims of Sun — that if you are dealing with an OpenID from their IDP (*.openid.sun.com), you are dealing with a Sun employee. In other words, Sun only issues OpenIDs from this IDP to its employees, and in fact has integrated their corporate security and authentication technologies into the system so that significant confidence in this claim can be expressed.
The business benefits of this are manifold; as Bray points out, OpenIDs that can be trusted as “Sun Employee” IDs are candidates for discounts, special access and any number of other benefits. Student discounts on books, computers and other items can be easily and accurately given out by vendors if they have IDP claims that can be trusted about the nature of the IDs they manage — XYZ university asserts that any IDs authorized by students.openid.xyz.edu are owned by currently enrolled students at XYZ university. And it’s not just about employment, as the student example illustrates. It’s a means to model *any* kind of authoritative assertions in OpenID. United Airlines could host an IDP at mileageplus1k.united.com that only issued OpenIDs for its customers that had “1k” status in their frequent flyer program.
Do you think people would find uses for that kind of assertion? I do.
Right now, the “assertions” around qualifications for getting an OpenID at openid.sun.com are “out-of-band”; there is no protocol provision in OpenID currently that enables a machine-readable set of assertions about the IDs a given IDP hosts. That’s a bad thing in the sense that it would be (will be) nice to have for automating trust relationships and reducing the friction and cost of various kinds of engagement and transactions. But like so much with OpenID, it’s a good thing to not have it in there, at least right now, as this is the kind of capability that often leads to the whole specification bogging down into heavy footprints and brain-numbing complexity. Anyone who has done some developement with WS-* or the assertion metadata features in Liberty will understand what I mean here.
For the time being, assertions like Sun’s (”all IDs at *.openid.sun.com are controlled by Sun employees”) will be managed as part of a business relationship, with interested systems giving special status to Sun OpenIDs based on a “hardcoded” basis — we believe Sun’s claims about *.openid.sun.com from their public statements, so we’ll reflect that in our code. Over time, as these kinds of warrantees become more popular and critical to enabling (valuable) transactions, we should expect to see these claims become either a) part of the extended OpenID specification, or b) rendered in another format or protocol that is used as a matter of convention in the OpenID community.
At any rate, it’s worth noting here that Sun’s announcement is proof positive that solutions to big problems often start out small (see Tim’s closing line of his post). Sun’s deployment of openid.sun.com isn’t a silver bullet for the problems of internet identity — not by a long shot — but this is a practical, simple step forward that, embraced widely by other organizations, will effect long-sought improvements in trust and trust and identity as building blocks for network applications.