[OpenID] Delegation leading to new accounts on websites

[George Fletcher]

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
>
> =