[OpenID] Delegation leading to new accounts on websites

[John Bradley]

Can you show me what you were using to delegate?
<link rel="openid.server openid.delegate" href="http://steamreview.org/openid/ 
" />
It is a bit unusual to have the delegate and the server be the same URL.
Given that a number of RPs are using regex to pick this apart that may  
be causing part of the problem.
Split this into two rel links for openID 1.1
For openID 2.0 you need openid2.local_id and openid2.provider.
This is an example from the spec.
<link rel="openid2.provider openid.server"
       href="http://www.livejournal.com/openid/server.bml"/>
<link rel="openid2.local_id openid.delegate"
       href="http://exampleuser.livejournal.com/"/>
Without the openID 2.0 rels I wouldn't expect you to get very far.
You can check http://test-id.org for some tests.
John B.
On 23-Jun-09, at 11:19 AM, Tom Edwards wrote:

> I've tried both delegation URLs on several sites, but the only one  
> that recognises me as steamreview.org in either scenario is  
> SourceForge. The others I tried are:
> 	• getsatisfaction.com
> 	• pbworks.com
> 	• wishlistr.com
> 	• stackoverflow.com
> These all thought I was flickr.com/blah/ or yahoo.com/blah/ - I was  
> only steamreview.org when delegating to <http://steamreview.org/openid/ 
> >.
>
> Yahoo only supports OpenID 2 while my server (PhpMyID) only supports  
> OpenID 1. Could this be making a difference?
>
> This process would be a lot more reliable if the openidenabled.com  
> test suite was working. :-(
>
> 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
>>>
>>