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

[Chris Messina]

On Thu, Jun 4, 2009 at 2:09 PM, David Fuelling <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090604/1aac91ec/attachment.htm>