[OpenID] OpenID 2.1 clarification on use of LocalID

John Bradley john.bradley at wingaa.com
Thu Apr 9 19:23:35 UTC 2009

We had this discussion a week or so ago re XRD.

At the moment the XSD has <LocalID> as Type xs:anyURI.  That includes  
absolute and relative URI.

So I stand corrected.  However as it can be a relative URI almost  
anything can be used.

The leaning is to relax that to be xs:string in XRD 1.0.

In the openID 2.0 spec you could take the hard interpretation that an  
identifier must be an absolute http:, https:, or xri: schemed URI.

I can buy that for the claimed_id however I think that is far to  
strict a reading for <LocalID> it is intended as a local or private  
identifier for the user at the OP.   As long as the value is agreed  
upon between the user and the OP I don't see the harm in it being a  

Now I understand that could be an issue if RPs are treating the  
<LocalID> as an absolute URL, though if they are supporting XRI they  
are probably treating them as strings.

So between XRD 1.0 and openID 2.1 and the desire to use e-mail  
addresses (not a http: or https: URI)  we need to clean it up.

So even those of us who work with this all the time can read our own  
opinions into the spec.

Thanks for the clarification Breno.

John Bradley

On 9-Apr-09, at 11:57 AM, Breno de Medeiros wrote:

> 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