Scott Kveton

OpenID 2.0 Status

First off, I’m just summarizing a bunch of really hard work that everyone is doing on the OpenID specifications mailing list. Josh Hoyt, David Recordon, Brad Fitzpatrick, Dick Hardt and the entire OpenID community are really slaving away on making OpenID v2.0 really great.

There are a few changes still pending but the current goal is to have the v2.0 specification completed by Friday 10/13/2006. Code should be quick to follow for Python, PHP, Ruby, Perl and Java (quick == days not weeks). Most of the remaining changes are technical in nature and don’t have a major impact on the functionality of OpenID.

Work continues on the specification as we’re starting to move up the stack. Dick Hardt has proposed a specification around attribute exchange and the vocabulary around that exchange. Attribute exchange is one of those things that will really start to make OpenID compelling. OpenID gives me a unique identifier that I can use anywhere that consumes them. This is my single, unique identifier that describes me. Attribute exchange allows the user to associate name/value pairs with that identifier. Now I can do things like deliver shipping address or my avatar to a site once-and-for-all without having to enter it again and again. Very cool stuff.

We’re also working on a data exchange protocol for OpenID as well. This will really round-out OpenID as a real platform for identity. The use-case is simple; messaging today sucks. Email is broken beyond reason (anybody can forge the From: field), instant messaging is a completely fragmented market (I love Meebo but its a kludge because we have 4+ IM networks that don’t interoperate). If I have a single, unique identifier with OpenID wouldn’t it be great if I could use it for messaging? Wouldn’t it be great if I could do it securely? I could send a message to an OpenID user that they know came from me and that I know only they can read. The possibilities here are endless. Email. Instant messaging. Legal documents. Medical records, etc. Now we’re not delusional here; this is all going to take time. However, its coming.

We’re making progress and OpenID is really starting to gain some momentum. More and more users and sites are looking to adopt it and we’re so glad people have been patient while we’ve been getting v2.0 as ready-as-we-can-get-it. Keep an eye on this space for more updates about OpenID.

About The Author

kveton

7th

October 2006

bykveton
posted in Identity, JanRain, OpenID
12 Comments »

12 Comments Add Yours ↓

The upper is the most recent comment

Forsooth #

10.07.2006 22:35
1
As a casual observer I’m concerned about i-name support. I think worst-case-scenario it could kill mass adoption. You better have a really good reason to add such massive complexity, recentralization and user confusion. It seems to go against everything OpenID stands for. Classical example of programmer-driven design and not practical use-case driven design.
Forsooth #

10.07.2006 23:21
2
Data exchange protocol kind of a broad name since that’s what OpenID already does.

Also as PKI app it will never fly unless it’s brain-dead, which means no revocation or trusted 3rd parties or any of that crap. This was already discussed on the lists.

The only benefit I can think of for email is guaranteed delivery since that would seem to be an intrinsic feature. The post-office has it, doesn’t really work with email, even with return receipts and the new domain-key infrastructre. This of course would require a queue which means now it’s looking more like classical email. Hmmm… Maybe we should just fix email instead.

Offhand view of the optimal evolution of components dependent upon but seperate from OpenID 1.1 (which should’t be touched imo. otherwise you’ll get something like XML 1.1 or XHTML 2.0 or other braindead committee driven crap):

attributes w/:
easy extension mechanism
arbitrary data structures
xpath-like addressability w/ URL/browser support
assertion support
self-documenting with comment fields
ideally forms should be able to be created from meta-data alone

pub-sub with guaranteed delivery

ecology of aggregators, which would include:
search engines
reputation services
browsers (FOF navigation etc)
memberships
attribute types (for sorting out redundancies, versioning, etc)

and finally, the icing: virtual agents
this would necessitate a structured set of attributes relating to user-prefences and would be used to both actively navigate the structured attribute data (residing behind personal, business, and aggregator OpenIDs) and to passively respond to requests initiated by trusted and reputation service-brokered OpenIDs
Kai Hendry #

10.08.2006 23:19
3
Couldn’t OpenID parse microformat’s hCard to gleam user’s information?

Perhaps it could be at least an optional feature of a server to help fill in the blanks…

http://microformats.org/wiki/hcard
kveton #

10.09.2006 15:36
4
Forsooth: I think i-names support has been critical to the early adoption of OpenID. I am also a little concerned about confusion for end-users but I still believe its important today.

OpenID is just authentication with a dash of discovery and attribute exchange on the horizon. It is not data exchange today. I should also point out that the draft for the data transfer protocol that I listed in this post is quite out of date.
kveton #

10.09.2006 15:39
5
Kai Hendry: I actually really love that idea and have thought in a general sense it would quickly get us to attribute exchange without re-inventing the wheel. You could couple this with the data transfer protocol if you want to do it securely (in the case where you want to make sure that the user is who they say they are).

I’ve heard Brad over at LiveJournal mention that he would support microformats if Technorati would support OpenID. I think that would be fantastic and we’d have a great feedback loop on two really simple technologies that would just feed off of each other.

Kai: you want to go ahead and propose that to the OpenID general list? :-)
Forsooth #

10.09.2006 17:00
6
I-name support is not even in OpenID yet, how has it been critical to early adoption?

I disagree about OpenID not being about data exchange. Really HTTP is obviously all you need for data exchange, the only disadvantage is that it’s not peer-to-peer. (asymmetry between requester and responder) Whereas OpenID + HTTP allows either parter to initiate a request because of shared secrets allowing the requester to be authenticated as well as the responder.

Anyway don’t mean to sound hypercritical or anything, I think you guys are doing a great job, and keep up the good work!
kveton #

10.09.2006 17:50
7
i-name support has been critical because of its place in the identity world. Lots of people really are liking the i-name concept, the people behind it and the possibilities it may enable.

And yes, if you put it in terms of HTTP then yes, OpenID is a data exchange … but c’mon!! That sounds o’ so not sexy! :-)

Thanks for the comments and kudos Forsooth … I appreciate folks keepin’ me/us honest … :-)
Forsooth #

10.09.2006 20:45
8
Hey no problemo…

I do think there’s lots of goodness in i-names when used for attributes. But I would go so far to say that it’s broken in implementation complexity when used as a top-level namespace. This will become readily apparent to implementors fairly soon, so I’m actually not too worried that it will ever find its way in.
http://robin.myopenid.com/ #

10.10.2006 13:50
9
I think 2.0 is too bulky. I\’d like to see, at least, a 2.0mini which will remove some of the complexity that 2.0 draft 9 is plagued with.

Robin
kveton #

10.10.2006 13:52
10
Robin: what is some of the complexity that you’re concerned about? It should be just as easy with v2.0 to implement as v1.1 with the libraries that will be released a few days after the specification is finalized.
James #

10.11.2006 10:26
11
Perhaps this is out of scope for OpenID itself, but one feature request I saw was the ability for a user to swap one identity provider for another – eg say I don’t want to use typekey any more and instead set up my own OpenID provider. How can I tell all the sites that+use my typekey to authenticate against my own provider, but keep the associated data? Or is the openid URI supposed to be the only identifier … *reads up on i-name* maybe i-name is what I want.

*recovers comment from cookie, fails to post using openid*
http://kveton.myopenid.com/ #

10.11.2006 15:44
12
James: there is no way to transfer your identity information from one provider to another right now. If you have your own domain, however, you can simply point it at whatever provider you choose.

i-names maintains a central database of i-names-to-i-numbers. This allows you to seamlessly move from i-broker to i-broker without having to lose your information. This is a centralized model and one that might not work for everyone; there is a central repository that is managed by the i-brokers. Think root servers on the Internet and registrars.

OpenID 2.0 Status

About The Author

kveton

7th

October 2006

12 Comments Add Yours ↓

Your Comment

About Scott Kveton

Recent Tweets

Archives

Tags Cloud

Latest Post