[OpenID] OpenID 2.1 clarification on use of LocalID

John Bradley john.bradley at wingaa.com
Thu Apr 9 18:51:04 UTC 2009


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




More information about the general mailing list