[OpenID] OpenID 2.1 clarification on use of LocalID

Breno de Medeiros breno at google.com
Thu Apr 9 18:57:33 UTC 2009


Actually, the OpenID terminology implies that openid.identity must be
an http(s) URI or XRI. See:

==quote
Section 2: Terminology

Identifier:
    An Identifier is either a "http" or "https" URI, (commonly
referred to as a "URL" within this document), or an XRI (Reed, D. and
D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” .)
[XRI_Syntax_2.0]. This document defines various kinds of Identifiers,
designed for use in different contexts.

==/quote

and later ...

==quote

OP-Local Identifier:
    An alternate Identifier for an end user that is local to a
particular OP and thus not necessarily under the end user's control.

==/quote


So if the spec writers intended that openid.identity could be
anything, that is not what the spec actually says.


On Thu, Apr 9, 2009 at 11:51 AM, John Bradley <john.bradley at wingaa.com> wrote:
> Yes that has come up in the XRD 1.0 work.
>
> The <LocalID>  is a string and can be a XRI, URI, e-mail or any other thing
> that the OP uses to identify the user.
>
> In most cases that is a URL or a XRI but it could be anything.
>
> Delegation is a term that carried over from openID 1.0 and probably is not
> accurate any more.
>
> The provider you are asserting is your provider.
>
> If for some reason you provider knows you by some identifier other than the
> claimed_id then you can use the local_id to send an arbitrary string in the
> openid.identity.
>
> The only identifier that the RP should discover is the claimed_id.  If in
> the returned assertion by the OP the claimed_id and the openid.identity are
> not equal (less hash)  the openid.identiy must be the <LocalID> in the
> discovered information.
>
> RP's not properly verifying that is an issue where someone delegates to a OP
> doing "Identifier Select".  (By issue I mean gaping security hole)
>
> That is a RP problem that can only occur when the User delegates there
> identity.
>
> Someone delegating a URI to a iName would be entering a XRI like =jbradley
> as the <LocalID>.
>
> It is also possible that someone delegating might not include the scheme ie
> ve7jtb.pip.verisignlabs.com as the <LocalID> that should work.
>
> John Bradley
>
> On 9-Apr-09, at 11:27 AM, Andrew Arnott wrote:
>
>> No where in the OpenID 1.x or 2.0 spec (that I can find) is the user's
>> LocalID (openid.identity) mandated to be a URI.  Yes, it's a "local
>> identifier", but the OP might choose to let that be simply the local
>> username like "andrew".  In this case, the OP hosted identity page might
>> include something like this:
>>
>> <link rel="openid2.provider" href="http://provider/opendpoint">
>> <link rel="openid2.local_id" href="andrew">
>>
>> So this looks like delegation because a local_id is given, but in this
>> case it's not.  It just causes the RP to customize the openid.identity
>> parameter to be 'andrew', which the OP will use to look up the username that
>> should control the claimed_id.
>>
>> The reason I bring this up is because I've seen many libraries assume that
>> local_id is a URI and treat it as such.  I've even heard ideas of performing
>> discovery on the local_id.  Now, there's no reason to perform discovery on
>> the local_id... only the claimed_id needs to be discovered.
>>
>> I don't even know if any OP out there uses non-URIs for local_id's.  But
>> since it's not a contradiction in the OpenID 1.1 or 2.0 specs, I think that
>> the 2.1 spec should call out EITHER that it MUST be a URI (and indicate
>> whether discovery is required to succeed) OR that it CAN be any string at
>> all that the OP is expecting.
>>
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the death
>> your right to say it." - Voltaire
>
> _______________________________________________
> 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)



More information about the general mailing list