[OpenID] Problems with delegation and directed identity OPs

Allen Tom atom at yahoo-inc.com
Mon Nov 10 06:39:04 UTC 2008


Hi Martin,

This is totally bogus, but I uploaded an HTML file to a webserver with 
the following broken delegation code:

<head>
<link rel="openid2.provider" href="https://www.google.com/accounts/o8/ud" />
</head>

And I was able to sign into Plaxo using 2 different Google accounts. I 
believe that the delegation code delegates to *any* Google Accounts 
user. I'm pretty sure that you do the same thing with the Yahoo OP if 
you don't remember to also put in the openid2.local_id value (the Yahoo 
OpenID that you're delegating to). The difference is that the Yahoo OP 
doesn't issue RP-specific OpenIDs, so you can delegate your personal URL 
to a single Yahoo OpenID.

That being said, I don't understand the purpose of needing to set 2 
values for delegation, the openid2.provider (The OP endpoint) and the 
openid2.local_id, it would seem simplest to just specify the OpenID that 
you're delegating to, and let the RP perform discovery to figure out the 
OP endpoint. It also seems broken that that user needs to know the OP 
endpoint of the OpenID that's being delegated to.

Hopefully delegation can also be cleaned up in OpenID 2.1

Allen


Martin Atkins wrote:
> Allen Tom wrote:
>> How does someone delegate their OpenID URL to Google?
>>
>> Putting following into the <head> section of the OpenID page:
>>
>> <link rel="openid2.provider" 
>> href="https://www.google.com/accounts/o8/ud" />
>>
>> seems to allow *any* user with a Google account to sign in with the 
>> delegated OpenID.
>>
>
> I'm not sure I'm completely understanding the situation you're 
> describing, but unless the openid.identity in the returned assertion 
> matches the value of openid2.local_id discovered from 
> openid.claimed_id, the RP should fail because the delegation is invalid.
>
> If you just put in the openid2.provider value and no openid2.local_id, 
> then you're effectively giving Google's OP carte blanche to make 
> assertions about that identifier, though I'm not sure why they would 
> make assertions about URLs outside of their own domain.
>
>
>




More information about the general mailing list