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

Sat Jun 6 00:04:01 UTC 2009

Wasn't there some work done, or at least discussion about, making the spec
more modular?  I seem to recall some threads on that topic, but can't seem
to locate them in my mail client.

On Fri, Jun 5, 2009 at 10:25 PM, Breno de Medeiros <breno at google.com> wrote:

> We also just need a more readable spec. From my experience listening to
> many confessions, it takes the average skilled web developer several months
> before they can understand the differences between what identifiers are
> displayed (claimed_id sans fragment), used to authenticate at the OP (local
> id), at the RP (claimed id + fragment). Then there is the issue with OP
> identifiers+identifier select, unsolicited assertions, etc.
>
> Reading from the current spec all the possible flows that result in
> obtaining this tripartite identity (displayed, local at OP, local at RP) and
> convincing oneself that the whole thing is secure requires an exercise of
> intense concentration and many, many passes through it. That is before we
> get into details such as the fact that some URLs are machine generated and
> ugly in displays, etc.
>
> Adding some identifier abstraction might help to clarify things.
>
>
> On Fri, Jun 5, 2009 at 3:03 PM, John Bradley <john.bradley at wingaa.com>wrote:
>
>> 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
>>>
>>>
>>
>>
>> _______________________________________________
>> 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090606/3e958a13/attachment.htm>