| By Michael Graves | May 8th, 2007 | Comments [7]
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.
May 9, 2007 at 5:37 am
But, doesn’t this run into the whole problem of multiple logins? Were this world to develop, I’d have to choose which sites I wanted to use my Sun Employee OpenID, which sites I wanted to use my college student OpenID, which I wanted to use my own personal (domain name) OpenID. Is this what we want?
Maybe this is in the works too, but wouldn’t it be better to have some way to authenticate an OpenID against multiple authorities? That is, I have a domain name that I use as my OpenID. The main reason I do this is so I can have greater control over my identity. I am free to change OpenID providers at will or even setup my own. I’m far less dependent that way–and when it comes to my identity, well, I like to be in control. Wouldn’t it make sense to have a system in the protocol for authenticating OpenIDs against servers that verify the status of that ID?
Perhaps something like a way for me to delegate an OpenID provider who will perform the functions they currently perform, and then also designate other servers (such as openid.sun.com) that can verify that my OpenID belongs to one of their employees. Obviously, I would have to associate my domain name with their system in some way. But, that seems like a better solution. It allows me the option of maintaining my single OpenID while simultaneously asserting my identity as a Sun Employee, a college student, etc.
May 9, 2007 at 8:01 am
Why not put the information to be asserted out as a DNS TXT record. SPF works that way. All you need is a compact machine-readable way of specifying a subdomain identifies which group…
May 9, 2007 at 3:32 pm
Andrew,
Thanks for the comments. Your thoughts here parallel a discussion we had on this topic yesterday. Rather than respond at length here, I’m going to turn you feedback into the starter kit for a separate post.
Should get to it today.
-Mike
May 9, 2007 at 3:55 pm
rolla,
I think that’s an option worth looking at. OpenID has purposely tried to avoid tying its adoption to the activity of the admins who control DNS Zone files, but obviously, in the case of Sun with openid.sun.com, *some* DNS tweaks were implemented.
One big drawback to the DNS-TXT approach (or similar strategies like SPF or DomainKeys), though, is that it implicates writing DNS-specific code. Dealing with openid.sun.com doesn’t require anything more than basic HTTP calls. Retrieving and parsing out what you need from a DNS TXT record *does*. It isn’t rocket science to do that, but it does require stepping out of the basic tools and idioms of web developers.
OpenID is fairly committed to keeping things limited to HTTP calls, in my view. That isn’t a matter of snobbery about HTTP, but simply a recognition that these are the tools that are ubiquitous, and thus will lend themselves to wide and rapid adoption of OpenID.
Thanks for the comments!
-Mike
May 9, 2007 at 4:30 pm
[…] a number of individuals took umbrage at some of the language and assumtions Bray made in his post, JanRain CTO Michael Graves ultimately sees it as a positive event. At any rate, it’s worth noting here that Sun’s announcement is proof positive that solutions […]
May 9, 2007 at 4:59 pm
I knew the first comment, if it were anything thoughtful, would be the exact same thing on my mind.
This is similar in vein to Freenode’s HostMasking thinger.
Right now I’m i=VxJasonxV@xmms2/troll/VxJasonxV
If the xmms2 team ever set up an open id auth system for any reason, I’d have vxjasonxv.users.xmms.se (or perhaps vxjasonxv.users.xmms2.xmms.se)
However, what about my personal commitment of vxjasonxv.webmaster.orangeloungeradio.com ?
Or my professional commitment of jsalaz.staff.myemployer.com ?
I agree that this idea doesn’t distribute in a terribly easy manner. And you can’t lump your life in together, as I’d rather not expose my job to everyone when they see my olr / xmms2 affiliation.
July 5, 2007 at 2:24 am
Aren’t this what Personas should meant?
Best
Lopo