[OpenID] Delegation leading to new accounts on websites

[Allen Tom]

Hi George,

If you type in your Flickr Photos URL into the RP's OpenID text box, the 
Yahoo OP will return your Flickr Photos URL as your OpenID, instead of 
the the https://me.yahoo.com/<randomstring> identifier in the response.

However, if you type in "flickr.com", we'll assume directed identity, 
and we'll display a drop down for you to select which OpenID (the Flickr 
one, or the machine generated one) in the response.

Note: you must type in http://www.flickr.com/photos/gffphotos and not 
htttp://flickr.com/photos/gffphotos.

Hope that helps,
Allen


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
>>
>> = 
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general