[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:

Section 2: Terminology

    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.


and later ...


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.


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


+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