[OpenID] OpenID 2.1 Identifier Types --> WAS [Discovery for Email like identifiers]

[Peter Williams]

Facebook are non conforming - if they didn't allow for user's to use their hxris. Shame on them. Its not exactly hard.

Using openid mechanisms to reimplement facebook connect (with variant messages) is a both a move forward and a move back. If openid is just a tech library rather than a movement for uci, im not sure it needs the overhead of the foundation.

________________________________
From: Chris Messina <chris.messina at gmail.com>
Sent: Thursday, June 04, 2009 5:49 PM
To: sappenin at gmail.com <sappenin at gmail.com>
Cc: Peter Williams <pwilliams at rapattoni.com>; Santosh Rajan <santrajan at gmail.com>; general at openid.net <general at openid.net>
Subject: Re: [OpenID] OpenID 2.1 Identifier Types --> WAS [Discovery for Email like identifiers]

On Thu, Jun 4, 2009 at 2:09 PM, David Fuelling <sappenin at gmail.com<mailto:sappenin at gmail.com>> wrote:


 1.  ALL OpenID 2.1 Identifiers MUST be Resolvable to XRD
Any OpenID Identifier MUST be able to be resolved to an XRD (with XRD being the primary "discovery" mechanism supported by OpenID 2.1).  Legacy discovery mechanisms from OpenID 1.0, 1.1, and 2.0 should still be supported, but would be restricted to URL's & XRI's (with EAUT possibly filling in the gap for email addresses).

This is a good framing.


 1.  Start With Only 3 Required Identifiers as a Baseline
OpenID 2.1 should mandate that all OP's and RP's support URL, XRI, and Email-like identifiers (only because these are the most common form of identifier -- Peter, I personally don't see a lot of LDAP identifiers being thrown around today on business cards, e.g.).

-1. I'm for extracting XRI into its own extension. As it is, it's the more complicated and convoluted part of the OpenID spec — to the degree that Facebook decided to not even both implementing it.

This is leading to bad experiences in the wild — and now that we've seen what people are willing to implement — I think that the spec and protocol should be responsive to that. In this case, it matters more what people implement than what is in the spec.

The two baseline identifier types should be URLs and email addresses — two of the most common — if not THE most common — forms of identifiers on the web.


 1.  Allow for Future Identifier Support as Decided by the Community
An extension mechanism should be defined that allows the OIDF community to endorse (via extension specifications) new OpenID 2.1 Identifiers.  The Jabber Foundation has done this sort of extensibility thing with decent success (not necessarily with Identifiers, but in general).

-1. While I support an extensibility model for additional identifier formats and types (i.e. XRI), I don't think that adding new identifiers should be mandated through community vote. That just doesn't make sense.

The point of extensibility is to allow for the protocol to serve increasingly divergent needs in the wild — and letting those real-world needs determine the destiny of the technology.

Indeed, having a tight, less complex core is something that we should aspire to — where CUTTING features should actually be something that we pursue with relish! Furthermore, it would inspire more community participation and involvement in the development of libraries — and lead to solving more interesting use cases — similar to how the OAuth community has been built out.

I don't need to belabor this point, but with a solid extensibility model, I think we can let market dynamics determine what needs to get baked into the core protocol over time.

Chris


--
Chris Messina
Open Web Advocate

Website: http://factoryjoe.com
Blog: http://factoryjoe.com/blog
Twitter: http://twitter.com/chrismessina

Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] bloggable    [X] ask first   [ ] private