[OpenID] Community Opinion on OID 2.1 Discovery and Identifiers...

Fri Jun 5 22:03:55 UTC 2009

David,

I am on the modular spec side.  I believe that other auth methods  
could also be considered.

I don't see why LID or others need to be excluded from the overall  
framework that is openID.

I am referring to identifier abstraction to make certain that we  
clearly understand the need for a primary key vs a display identifier.

We ran into this with XRI and the presumption that the claimed_id is  
what is displayed for the user.

With XMPP identifiers you may have multiple identifiers that resolve  
to the same XRD and hence have the same claimed_id but may want your  
input identifier represented in some way.

Perhaps we need more that one identifier at the API layer.

What I am saying is that if the core spec assumes URI then there will  
be a built in bias as there is now.

We need to consider how provider portability could be achieved or at- 
least not be precluded by core design choices.

John B.

On 5-Jun-09, at 4:27 PM, David Fuelling wrote:

> Replies inline...
>
> On Fri, Jun 5, 2009 at 7:28 PM, John Bradley  
> <john.bradley at wingaa.com> wrote:
> David,
>
> I tried to vote but RPX and Jyte seems to have some issue with me :)
>
> Wierd, aren't those two products made by the same company?
>
>
> One option that should be discussed is abstracting all identifiers  
> out of the core spec.
>
> +1
>
>
> When I originally proposed that last year in the early 2.1  
> discussions it was rejected.
>
> Unless we have some reasonable abstraction layer for identifiers  
> adding new ones will never work properly.
>
> Can you detail this a bit more?  Maybe I'm missing something, but if  
> 2.1 says something like, "an identifier that can be resolved to an  
> XRD document is can be used", wouldn't this work?  If we have an  
> XRD, then we should be able to do the OpenID dance.
>
>
>
> My proposal is that all identifiers including URL are removed from  
> the core spec and placed in there respective binding extension  
> documents.
>
> I am open to this.  More and more I'm leaning towards the idea that  
> their should be "Identifier" parity...namely, if you can give me an  
> XRD, then you can be my identifier (somebody should write a song  
> with that title).
>
> If this is rejected due to the argument that developers are only  
> willing to read one document, then my argument that leaving URL in  
> the core spec makes all the other identifiers second class citizens  
> is proved.
>
> I think the JSF (XMPP) has disproved this, at least from the  
> perspective that a successful spec can have a "core", with  
> supplemental pieces of the spec.  Whether or not XMPP is more  
> difficult to understand than OpenID is debatable.
>
> This again raises the question of what is openID.  Is it an  
> authentication protocol,  a discovery methodology,  a Identity  
> abstraction layer for applications,  or a marketing term?
>
> I think OpenID is a little bit of each.
>
> I might re-frame the question to be "how to we enable OpenID to play  
> in all of these different areas".  I think a good solution would be  
> a more modular spec.
>
>
> I think we need to understand the answers to the latter questions  
> before deciding what should be in the core spec.
>
> John B.
>
> On 5-Jun-09, at 3:00 PM, general-request at openid.net wrote:
>
>> Date: Fri, 5 Jun 2009 18:51:48 +0000
>> From: David Fuelling <sappenin at gmail.com>
>> Subject: [OpenID] Community Opinion on OID 2.1 Discovery and
>> 	Identifiers...
>> To: general at openid.net
>> Message-ID:
>> 	<51dae84d0906051151i24578169l2595c9d4e291bb1d at mail.gmail.com>
>> Content-Type: multipart/alternative;
>> 	boundary=0016364582b282ac08046b9e62a0
>>
>> --0016364582b282ac08046b9e62a0
>> Content-Type: text/plain; charset=ISO-8859-1
>> Content-Transfer-Encoding: 7bit
>>
>> The point below (about the community needing to decide if it's  
>> going to
>> support webfinger) is just one of many questions I'd like community  
>> to
>> decide concerning OID Auth 2.1 Discovery and Identifier support.
>>
>> Maybe this is where a WG should be formed....I'm not really sure.   
>> It seems
>> kind of backwards to form a working group about something like email
>> identifiers (e.g.) and then come back to the community with some  
>> decision.
>> It seems like the community should reach some consensus first, and  
>> then we
>> start a WG.  Perhaps I have the wrong notion of what a Working  
>> Group is.
>>
>> At any rate, *in the absence of a WG* on any of these issues, I'm  
>> curious to
>> know the community's opinion on these questions so we can all know  
>> what the
>> general consensus is.
>>
>> So, at the risk of igniting a firestorm, I created a bunch of Jyte  
>> claims
>> and embedded them in the wiki.  Please share your vote (and thus your
>> opinion) if you so wish.
>>
>> https://openid.pbworks.com/Identifier-and-Discovery-2_1-Questions
>>
>> Also, please note that I'm not authoritative about the questions.   
>> Feel free
>> to embed your own claim into the wiki page (though I tried to be  
>> fair in the
>> framing of the questions).
>>
>> David
>>
>> On Fri, Jun 5, 2009 at 4:38 AM, Santosh Rajan <santrajan at gmail.com>  
>> wrote:
>>
>>>
>>>
>>> On Tue, Jun 2, 2009 at 11:33 PM, Dirk Balfanz <balfanz at google.com>  
>>> wrote:
>>>
>>>> I Webfinger gives you everything you need. The OpenID community  
>>>> just needs
>>>> to decide whether the email-like identifiers falling out of  
>>>> webfinger are
>>>> acceptable OpenIDs.
>>>>
>>>
>>>
>>> I think you have a raised a very valid issue here. I didn't  
>>> realize that
>>> first time round. You are right. I don't see any point in  
>>> continuing with
>>> the email issue without a clear answer to this question.
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net
>>> http://openid.net/mailman/listinfo/general
>>>
>>>
>>
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090605/37f69a24/attachment.htm>