[OpenID] Delegation leading to new accounts on websites

[John Bradley]

Delegation chaining is not supported in any RP I know of.   The user  
must enter the correct endpoint for the OP and the identifier the OP  
is to authenticate as the LocaID.

John B.
On 23-Jun-09, at 6:48 AM, Allen Tom wrote:
> Hi John -
>
> Your description accurately describes how the Yahoo OP is  
> implemented, and it is the RP's responsibility to keep track of the  
> user's URL that was delegated to the OP.
>
> One possible possible issue is that Flickr itself delegates to  
> Yahoo, so users are probably better off delegating to their default  
> machine generated Yahoo OpenID (of the form https://me.yahoo.com/a/ 
> <random string>) than to to their Flickr Photos url.
>
> Tom - can you try delegating your personal URL to your default Yahoo  
> OpenID? This will eliminate the extra round trip to Flickr, which is  
> probably causing your problem.  The easiest way to find out what  
> your Yahoo OpenID is to go here:
>
> http://openid.yahoo.com/
> Click Get Started
> Type in your password
> and take a look at the identifiers at the bottom of the screen.
>
> Unfortunately, this doesn't seem to work on GetSatisfaction. :/
> Allen
>
>
>
> 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.
>>
>> If the RP doesn't do this step anyone with a Yahoo account can log  
>> into any openID that is delegated to Yahoo.
>>
>> 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 wrote:
>>
>>> Date: Mon, 22 Jun 2009 11:44:03 -0400
>>> From: George Fletcher <gffletch at aol.com>
>>> Subject: Re: [OpenID] Delegation leading to new accounts on websites
>>> To: Andrew Arnott <andrewarnott at gmail.com>
>>> Cc: "general at openid.net" <general at openid.net>
>>> Message-ID: <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
>>
>

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