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

Chris Messina chris.messina at gmail.com
Fri Jun 5 00:44:12 UTC 2009


On Thu, Jun 4, 2009 at 3:24 PM, Breno de Medeiros <breno at google.com> wrote:

> How are we going to coordinate this discussion towards a deliverable?
>
> Are we going to start formal work on authentication 2.1?
>

+1. I think it's time to formalize this work in a WG, rather than continue
to beat this thing to death with no binding outcome in sight. This is what
the WG process was created for!


>
> Are we going to form the discovery WG that was proposed 5-6 months ago? The
> original scope for that WG was not a specification, but a guidance document
> on how to use discovery in OpenID (so that authentication 2.1 could use only
> a few sentences, such as "in this document, whenever we refer to discovery,
> we mean XRD discovery, see <reference> for how to use XRD discovery in
> OpenID and also how to deal with legacy discovery mechanisms that were
> specified in previous versions of the spec" or some equivalent language).
>

Would that be a wise separation of effort? In some ways separating out
discovery allows for the clean division of labor that you suggest above;
OTOH, OpenID 2.1 is contingent upon having a clear discovery spec/approach
and so could introduce too much risk if 2.1 can't advice before the work of
a Discovery WG is wrapped up.

What do you recommend? Is it just a matter of distilling the useful bits
from WebFinger and XRD into a series of recommendations?


>
> I am weary of engaging in yet another thread(s) about discovery with a
> clear prospect for a tangible deliverable.
>

Completely agreed. The question was raised recently about the value of
membership in the foundation; though anyone can participate in WG's, I think
the foundation role in hosting WGs is where the value lives — and if people
want their membership dollars to result in some kind of return, turning
these discussions into an active WG (with a specific owner/leader!!) is what
must happen.

Chris


>
>
> On Thu, Jun 4, 2009 at 2:09 PM, David Fuelling <sappenin at gmail.com> wrote:
>
>> Peter (et al):
>>
>> I'm open to discussing the "type" of identifier that OpenID 2.1 should
>> support.  I rather agree with one of your (Peter's) previous posts that
>> OpenID should allow _any_ type of identifier.  I would add the following
>> caveats to that support, as follows:
>>
>>    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).
>>
>>    2. *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.).
>>
>>    3. *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).  This Identifier extensibility model would accomplish the
>>    following:
>>
>>    1. It will preclude the need to actually _decide_  whether and which
>>       types of new identifiers to include in the 2.1 spec (email identifiers not
>>       withstanding).
>>       2. It would allow the community to vote on each new particular
>>       identifier type on its own merits, preventing the "stall" of the 2.1 spec.
>>       3. It would ensure that OP's and RP's are only required to support
>>       a baseline of OpenID functionality, while at the same time leaving room some
>>       new form of identifier that might take off in the future (Google Wave?
>>       Nah....Looks like that will still have an email address format for
>>       Identifiers).
>>
>>       4. *Some Other Requirement?
>>    *Am I missing something?
>>
>>
>> On Thu, Jun 4, 2009 at 8:21 PM, Peter Williams <pwilliams at rapattoni.com>wrote:
>>
>>> There is no open discovery protocol. There is simply use of 2 externally
>>> defined protocols (yadis and xri resolution).
>>>
>>> As it stands, openid auth spec constrains ane canonicalizes c the allowed
>>> inputs to those protocols, when used.
>>>
>>> Are you guys also proposing that an op might discover an rp realm xrd,
>>> from a rp identified in openid auth that is not either an http/s scheme url
>>> or an xri?
>>>
>>> Will it be mandatory for op to support webfinger, if the rp realm chooses
>>> to so identify itself?
>>>
>>> Why this one and not all the others such as gc and ldap? (apart from, its
>>> in the news today)
>>>
>>> ________________________________
>>>
>>
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
>>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>


-- 
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/c833d22d/attachment.htm>


More information about the general mailing list