Interesting arrival at the identity party OpenID. It’s simple, so it might spread fast.
This is a design that works with the existing web infrastructure. No need to update the installed base of client software. Good, that’s a nearly immovable object.
The usage scenario is straight forward. A random anonymous visitor wanders into supicious site. Supicious site would like to know more about this visitor. It asks the user for the name of some site that can vouch for him. The user enters a domain name. The suspicious site fetches the home page of that domain. Secreted away in the header of the home page is information about where the suspicious site can go to have a conversation with the vouching site. Using that info the two sites can then work with the user to make everybody happy.
It’s a nice design because the user explicitly reveals the name of the vouching site he’d like to use.
The spec could use some careful security review. The design is currently silent on why the supicious site would trust the vouching site. The design lacks any tools for fine grain control over what’s revealed about the user, and the distribution of that info.
The usual scheme to bootstrap finding the vouching site is to use a shared cookie; this is a nice alternative. The server in your basement might be able to play the vouching role. That’s something geeks like in a design.
Regarding the “fine grain control” over what’s revealed, I don’t really see what you mean. The only thing that OpenID reveals is the answer to the question “Does the user own this identity URL?”. I suppose that implicitly reveals a URL for the user, though that URL need point to nothing more interesting than a blank HTML document with a LINK element in its HEAD.
OpenID explicitly avoids profile exchange because that’s someone else’s problem. I believe the current thinking is that the identity URL can also have a FOAF auto-discovery URL which sites could potentially use, though that’s not part of OpenID and something like this will likely just become a de-facto standard as people start to use OpenID for different things.
The fine grain control comment was triggered by two things.
In the linked description there appears this bit “… server then returns to the client’s browser the: … the user’s identity server URL …
Perhaps a FOAF URL …” That’s a red flag for me; since FOAF tends to encourage users into revealing more information than is actually necessary.
The second reason was that I didn’t see a clear policy to keep what’s revealed extremely minimal; and it’s necessary complement a means to extend that. Any such mechinism will have to interact with the user to gain his permission, and that notches up the complexity of getting it all right.
Now having been forced to think about this aspect some more I recall that it’s key to get right early that the sources for revealed information not get tied to the vouching entity too tightly. The vouching entity has a advantagous position, as the first stop for info about the user, and a good design strives to keep the vouching agent with as little information about the user as is technically possible.
Pingback: Ascription is an Anathema to any Enthusiasm » Blog Archive » OpenID - Part II
Pingback: How OpenID works | neumeier.org