[OpenID] Delegation leading to new accounts on websites

[George Fletcher]

Thanks Allen, good to know.

I'm assuming for this behavior to work, the user must first have enabled 
their flickr URL as an OpenID. When I try with a flickr URL that is not 
yet enabled as an OpenID then I get the "directed identity" behavior. 
This is the behavior I described in my flow earlier.

The confusion comes in that the RP MUST do late binding and can NOT 
assume that the identifier entered by the user is valid for the session. 
As long as the RP ignores what the user entered if the AuthN request 
claimed_id does not equal the AuthN response claimed_id there will be no 
mis-identity issues.

Thanks,
George

Allen Tom wrote:
> 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
>
>