[OpenID] Delegation leading to new accounts on websites

[John Bradley]

George,

Part of the problem is that Flickr is not doing delegation to Yahoo.

They are leveraging the fact that the Yahoo OP ignores the  
openid.identity.

I don't think that has a name I can repeat:)   It however is not  
delegation.

The spec didn't really anticipate the behavior of doing directed  
identity where the special URI
was not sent in the openid.claimed_id.

The thing is Yahoo doesn't always asset a new claimed_id they will  
attempt to return the claimed_id that was sent in the request.   They  
will return the authenticated id in the openid.identity.

That is why the RP needs to check that the returned openid.identiy is  
the localID in the XRDS.
Otherwise some other user may be using the delegated identity  
leveraging an alternate directed identity.

Allan and I have gone back and forth on this a number of times over  
the last year.

I think the combination of delegation and directed identity is  
difficult for RPs to understand and get correct.    However I don't  
loose too much sleep over it.

Now that people are using there flickr URLs as openID that complicates  
the situation even more.

John B.

On 22-Jun-09, at 8:43 PM, George Fletcher wrote:

> If I understand this correctly...
>
> 1. I enter http://www.flickr.com/photos/gffphotos (shameless plug  
> for my photo stream:)
> 2. The RP  normalizes the "user entered identifier" (in this case  
> it's the same URL)
> 3. The RP does discovery on the "user entered identifier" and the  
> HTML defines the OP as yahoo (no local_id)
> 4. The RP sends the AuthN request with openid.identity=http://www.flickr.com/photos/gffphotos
> 5. Yahoo ignores the openid.identity field and does directed identity
> 6. Yahoo sends back an openid.claimed_id=https://me.yahoo.com/ 
> <randomstring>
> 7. Since the openid.identity value the RP sent does not equal the  
> value the OP returned, the RP does discovery on the https://me.yahoo.com/ 
> <randomstring>
> 8. Discovery shows that the yahoo OP is indeed authoritative for the  
> URL
> 9. The RP has to ignore the value entered by the user (e.g. http://www.flickr.com/photos/gffphotos) 
>  and just use the value the OP returned (e.g. https://me.yahoo.com/ 
> <randomestring>) because there is no way to know whether the  
> returned identifier from yahoo actually maps to the value entered by  
> the user
>
> The following is also true if I try and delegate my vanity URL to an  
> flickr based OpenID.
>
> I believe that if the RP sends an identifier for the user that is  
> NOT the directed identity select URL, then the OP should either (A)  
> authenticate only the specified identity or (B) fail the request.  
> Allowing the request to succeed but for an identity totally  
> different than what the user identified to the RP is just confusing.
>
> Thanks,
> George
>
> P.S. More comments inline
>
> John Bradley wrote:
>> George,
>>
>> The combination of directed identity is still a real interop issue  
>> because it is not well explained in openID 2.0.
>>
>> When the claimed_id (less fragment)  or the identity are different  
>> in the response from the request the RP must rediscover the  
>> openid.claimed_id.
>>
>> If delegation was done the openid.identity must match the LocalID  
>> in the XRD.
> I don't think this will work in the Yahoo case. The openid.identity  
> value returned by Yahoo is the https://me.yahoo.com/<randomstring>.  
> If I do a discovery on this identifier, it case say that the  
> "LocalID" at Yahoo is the same value, but that doesn't mean it  
> matches to the URL the user entered at the RP. If the XRDS response,  
> somehow ties the directed identity value back to the flickr URL the  
> all the pseudonymous benefits of directed identity are broken.
>>
>> If the RP doesn't do this step anyone with a Yahoo account can log  
>> into any openID that is delegated to Yahoo.
> It isn't the discovery of the returned openid.claimed_id value that  
> protects against this case. It's the fact that the RP ignores the  
> value the user entered and even it's associated local_id value and  
> instead just uses the values returned by the OP. It is impossible to  
> associate in anyway the value the user entered with the value the OP  
> returns.
>>
>> Yahoo is following the spec as intended.
>> There is an OSIS test for RPs to check if they are vulnerable to  
>> this.
>>
>> If the second discovery verifies then 1 can still be used safely as  
>> the users identifier.
>>
>> I had to sit Johnny Bufu down to explain it to me what they  
>> intended when they wrote 2.0.
>>
>> I couldn't extract the logic from the spec itself for the  
>> delegating to a directed identity flow.
>>
>> John B.
>>
>> On 22-Jun-09, at 11:45 AM, general-request at openid.net <mailto:general-request at openid.net 
>> > wrote:
>>
>>> Date: Mon, 22 Jun 2009 11:44:03 -0400
>>> From: George Fletcher <gffletch at aol.com <mailto:gffletch at aol.com>>
>>> Subject: Re: [OpenID] Delegation leading to new accounts on websites
>>> To: Andrew Arnott <andrewarnott at gmail.com <mailto:andrewarnott at gmail.com 
>>> >>
>>> Cc: "general at openid.net <mailto:general at openid.net>" <general at openid.net 
>>>  <mailto:general at openid.net>>
>>> Message-ID: <4A3FA6C3.9060305 at aol.com <mailto:4A3FA6C3.9060305 at aol.com 
>>> >>
>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>
>>> Isn't one of the underlying issues the fact that there are really  
>>> 3 identifiers in this scenario?
>>> 1. the identifier entered by the user (claimed_id or i-name)
>>> 2. the discovered/resolved identifier ("local_id" or "i-number")
>>> 3. the identifier returned by the OP
>>>
>>> In the case of OpenID 2.0 protocol flow, the RP has to remember #1  
>>> and send #2 as the openid.identity parameter. If the OP does NOT  
>>> return openid.identity == #2, then the OP has chosen to do  
>>> directed identity regardless of the request and the RP must throw  
>>> out #1 and take #3 as the user's identifier.
>>>
>>> This causes some weird user experience issues, but this is what we  
>>> ran into when implementing OpenID 2.0 Relying Party support.
>>>
>>> Thanks,
>>> George
>>
>> =
>