[OpenID] OpenID 2.1 clarification on use of LocalID

[John Bradley]

It works fine if the RP performs the discovery on the returned  
claimed_id and makes certain that if the openid.identity  is not ==  
openid.clamed_id it is in the discovered information as the <LocalID>

The user supplied value is only used for the first discovery.   The  
second discovery if there is one uses the returned.clamed_id.
If the calimed_id doesn't change then you don't need a second  
discovery because you already have the discovery info.

So logically if the claimed_id that is returned by the OP is the same  
one that is sent, (as it would be for delegation) if ANY of the other  
three parameters are changed in the  assertion from the OP, that  
assertion must be rejected.

I have found RPs that were only checking for the openid.claimed_id  
changing.

This allowed me to get a OP to assert a claimed_id for a delegated ID  
while logging in with any valid ID at the OP.

Checking the values in the returned assertion against the discovery  
information is critical.

FYI Google and Yahoo are treating the combination of delegation and  
directed identity differently.

John Bradley

On 9-Apr-09, at 4:40 PM, Peter Williams wrote:

>
>
>> -----Original Message-----
>> From: general-bounces at openid.net [mailto:general- 
>> bounces at openid.net] On
>> Behalf Of John Bradley
>> Sent: Thursday, April 09, 2009 11:51 AM
>> To: Andrew Arnott
>> Cc: openid General
>> Subject: Re: [OpenID] OpenID 2.1 clarification on use of LocalID
>>
>> 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.
>
> Nah.
>
> If the values are not equal, the RP must perform discovery on the  
> value supplied. This requirement provides the openid 1.1  delegation  
> semantics, expressed now through localid (whose value is supplied  
> from the initial XRD discovery).
>
> We went through this ad nauseum during the review of openid2.0. It  
> works fine for delegation through directed identity mode, too.
>
>>
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090409/2045fcf7/attachment.htm>