[OpenID] Problems with delegation and directed identity OPs

Mon Nov 10 07:20:33 UTC 2008

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

Having just done this experiment myself, it looks like what's happening 
here is that Google's OP is ignoring openid.identity in the request in 
this case. When the positive assertion is sent back, it is not for the 
identifier I originally entered but for a generated identifier under 
google.com.

As you note, this works on Yahoo!'s OP as well because it also ignores 
openid.identity.

Arguably in both cases here the OP should fail and say that it can't 
make an assertion for the given identifier rather than sending back an 
assertion for a completely unrelated identifier. (i.e. "answering the 
wrong question".)

In any case, this isn't delegation but instead saying that Google is the 
OP for the URL, which gives Google permission to make assertions about 
that URL if it likes. In practice there's no way it could make such 
assertions since it doesn't know which Google account it belongs to.

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

This is an optimisation ensuring that the RP won't have to jump around 
following a long chain of delegations until it reaches a "real" 
identifier. You could argue that it already needs to do that to handle 
redirects, though. This could potentially be changed in OpenID 2.1 if 
RPs do not object to having to do extra discovery requests in the 
delegation case.