On both the Internet and behind the firewall, the identity problem gets uglier every year. How many passwords do you have? If you’re in IT, how much pain do you go through getting your all your apps to share a notion of who someone is? There are a lot of smart people working on these problems, but progress has been crushingly slow. We’re doing a little something with OpenID this week that won’t turn the world inside out but I think shows that progress is possible.
OpenID (see my previous write-up) is a cheap-and-cheerful easy-to-implement way to bind an identity to a URI. It allows a Web site talking to a browser to look at the URI and reliably ask its server to confirm (or not) that the person behind the browser has OpenID rights to the URI. It’s simple, straightforward, and it works.
Unfortunately, at the moment, it isn’t good for much, because the OpenID might be pointing at a server that’s evil or silly. It’s good enough for blog comments and that’s about it.
Sun’s an Internet company and so the Identity cabal here really likes OpenID’s notion of using a URI for an identifier. The experts here think there’s a whole lot more to the identity problem than that, but it still feels like a good start. (Bear in mind that one of Sun’s most successful product areas is Identity software, in the directory and access-manager space). So we’re doing an announcement today that says, more or less, “We like OpenID and we’re going to start supporting it more.”
What’s more interesting is that we’re rolling out an OpenID provider, but with a twist: You can’t get an OpenID there unless you’re a Sun employee, and if someone offers an OpenID whose URI is there, and it authenticates, you can be really sure that they’re a Sun employee. It doesn’t tell you their name or address or anything else; that’s up to the individual to provide (or not). The authentication relies on our Access Manager product, and it’s pretty strong; employees here have to use those crypto-magic SecureCard token generators for serious authentication, passwords aren’t good enough.
The applications are obvious; if anyone wants to offer deals or special treatment online to Sun employees, well, that’s easy now. (I know of at least one company named after a fruit whose online store offers a nice Sun employee discount based on knowing a “secret” URL; this would have to be a much better alternative).
I suspect there are a few other problems like that. At last Java One I was talking to a CIO from a big community college with tens of thousands of students, and literally dozens of external partners who wanted to be able to verify that someone behind a browser was in fact a student; this would take care of that cheaply, neatly, and safely.
What’s probably more interesting in the big picture is that
openid.sun.com shows that OpenID can be put to work on something
with actual business value.
The technology is pretty interesting too. Our Access Manager product is a big, mature, enterprise-scale offering, but that group really hadn’t imagined an application like this, so there was quite a bit of engineering involved in getting it to talk OpenID to the Web at large. But it works now, and I’m hoping one of the developers will blog the details. It’ll be open source, of course.
This does not mean the Identity nut has been cracked, in the big picture. But I’m a huge fan of solutions to big problems that start out small, simple, and efficient; this qualifies.
Contributions
Comment feed for ongoing:
From: Antone Roundy (May 07 2007, at 12:03)
Here's something that would be nice to be able to do -- you get an OpenID that you aren't going to lose when you change jobs, ISPs, etc., and register it with your employer, school, etc. Then when you go to get your discount (or other benefit), you give the merchant your OpenID URI and tell them your an employee of such and such company, they do the normal OpenID check to verify that you're the owner of that URI, and then contact your company to verify that your OpenID URI is owned by one of its employees. This type of arrangement would make it a lot easier for the individual who gets benefits from various places based on their employer, school, membership in some organization, etc., since they'd only have to keep track of one OpenID.
It would be slightly less secure since there would be two points of attack -- the OpenID provider and the company, school, etc. Perhaps the entity giving the benefit could reduce the risk by requiring the use a known and trusted OpenID provider.
Any obvious problems or reasons why some other approach would be better?
[link]
From: Simon Willison (May 07 2007, at 12:47)
I'm really excited about this. I've been advocating this exact approach in talks I've given about OpenID, so it's great to see it actually happening in practice. My hope is that popular Open Source groupware software (stuff like MediaWiki, Bugzilla and so on) will start both supporting OpenID /and/ providing a way of saying "only accept OpenIDs that match this specific pattern" - so organisations that run their own OpenID providers can trivially install intranet and/or extranet software that can only be accessed by their employees.
[link]
From: Sam Ruby (May 07 2007, at 14:29)
So... Tim, when are you going to 'claim' this blog? :-)
Antone: Tim's had this blog before he joined Sun, and will still have it should he ever leave, so this URI works just fine.
This URI can 'delegate' via a YADIS file to any number of providers. That file can be updated at will.
[link]
From: M. David Peterson (May 07 2007, at 14:42)
@Antone,
If not mistaken, this is already possible using delegates, though you're OpenID service provider would need to support delegation. That said, this type of arrangement would require the use of multiple URI's for each account you would want to validate against, as as far as I know, there is no way to use one URI with multiple delegates (nor would it really make any sense to even attempt.)
Of course, the simple solution would be to maintain a separate URI for each delegate (e.g. openid.tbray.org/sun, openid.tbray.org/some-other-org), and in many regards this would really be preferable as it would allow greater pin-point control over which URI you associated with with various sites (something more personal for non-work related logins, something more professional for work-related logins)
[link]
From: Eric Norlin (May 08 2007, at 05:11)
Along all of these lines, I blogged my "history of identity protocols in a nutshell" yesterday for those that wanna catch up ;-)
http://blogs.csoonline.com/a_brief_history_of_identity_protocols
[link]
From: Mark Scrimshire (May 08 2007, at 05:40)
In answer to Antone's point. Couldn't the Referer capability in OpenID be used so that when we go to work for someone like Sun who supports OpenID we get to specify where our OpenID URI is resolved.
So my authentication gets redirected back to a single authenticating site.
[link]
From: Eugene Chan (May 08 2007, at 07:22)
Tim:
What happens when employees leave the company? At that point, who owns the OpenID--the person or the company?
Thanks for the peek inside Sun, though. Very cool.
Eugene
[link]
From: Antone Roundy (May 08 2007, at 08:57)
I've just finished reading through the Open ID spec (I've only glanced over it before), and as long as the company store (or whoever the "Consumer", to use the spec language, is) is smart enough, it's possible to get close enough to what I'm after. Let me describe it a little more clearly.
Goal: To only have to remember a single Open ID URI (or a few that are almost identical) and perhaps a single password.
Example: I'd like to have the option of using either a single Open ID URI, or a set of very similar URIs like the following, and perhaps a single password to identify myself to third parties as an member of Gecko Tribe, LLC, a San Francisco State University alumnus, a member of Gold Key, Mensa, a GEICO customer, etc.
example.com/antone/geckotribe
example.com/antone/sfsu
example.com/antone/goldkey
example.com/antone/mensa
example.com/antone/geico
Reason: The above would be much easier to remember than, for example, the following and a separate password for each:
www.geckotribe.com/OpenID/antone
openid.sfsu.edu/alumni/antoneroundy
https://secure.goldenkey.org/openid/ar18476
www.us.mensa.org/members/open-id/1384812
https://open-id.geico.com/193488584
I see that by using delegation, I could use my easier-to-remember URIs, and I suppose the Consumers could accept those URLs since they'd recognize the Identity Providers to whom authentication was delegated.
So I guess that's close enough IFF the Consumers are smart enough to accept my easy-to-remember URIs. If I want to only have to remember a single password, I can use the same password with all of my Open ID providers. If I want more security, I can choose different passwords and accept the burden of remembering them all. I would have to remember the last part of each of my URIs, but that shouldn't be too difficult.
[link]
From: M. David Peterson (May 09 2007, at 12:13)
@Sam,
YADIS is something that I know very little to nothing about. Seems I need to do some reading to better understand, but from the outside looking in it seems this is obviously a wonderful thing.
[link]
From: Peter Motyka (May 09 2007, at 22:09)
http://www.tbray.org/ongoing/When/200x/2007/05/07/OpenID-at-Sun#c1178639867.449335
"Example: I'd like to have the option of using either a single Open ID URI, or a set of very similar URIs like the following, and perhaps a single password to identify myself to third parties as an member of Gecko Tribe, LLC, a San Francisco State University alumnus, a member of Gold Key, Mensa, a GEICO customer, etc.
example.com/antone/geckotribe
example.com/antone/sfsu
example.com/antone/goldkey
example.com/antone/mensa
example.com/antone/geico"
It would be more convenient to maintain a single OpenID URI, example.com/peter and provide a collection of openid.server/openid.delegate tags for the consumer to decide with IdP to use for verification. For example, when becoming an employee of Sun, simply add openid.server/openid.delegate tags for openid.sun.com and then the URI could be used to access resources which require a Sun verified OpenID. The key being, a single OpenID URI which offers delegation to many IdPs, one is chosen by the consumer based on the resource being accessed.
[link]
From: Tim Cole (May 10 2007, at 11:03)
At the European Identity Conference here in Munich today we talked about doing "identity federation lite" with Microsoft CardSpace, and since Kim Cameron and Dick Hardt and his OpenID friends have announced that they will make both systems compatible what we talked about could be relevant here as well. The problem, it seems, is that nobody wants to be an OpenID identity provider because there's no real business model, or at least no obvious way of making lots of money right away. But companies do like to proviude added servies to their customers, so wouldn't someone like, say, Lifthansa be very interested in providing a CardSpace or OpenID equivalent of their "Miles and More" members card as a managed card that Lufthansa customers could use to authenticate to Lufthansa's many affiliates (Star Alliance airlines, car rental companies like Sixt, hotels, etc.). These affiliates would only know that, yes, Tim Cole is a trusted customer of Lufthansa, which isn't enough for them to base high (or even low) value transactions on, but they might be interested in offering "no-value" transactions like gibing me a couple of rebate points on my next car rental or hotel room, based on the fact that I have a M&M card, without my having to produce the physical card.
In fact, wouldn't we be creating a kind of "circle of trust" here, but without the bells & whistles (read: legal hassle of drwaing up lots of contracts to handle liability issues and fmaking lots of lawyers even richer)? And shouldn't we be calling this "federation lite"? Intersting thought IMHO.
Tim Cole
Kuppinger Cole + Partner
[link]