Auth 2.0 spec errata regarding delegation vs. directed identity

[Martin Atkins]

In a conversation yesterday I found out that a particular existing 
OpenID Provider[1] is acting in a way that defeats delegation. This is 
allowed by the spec, but has non-obvious degenerate behavior:

  * You delegate to your identifier with this provider
  * Another user of this provider logs in with your delegate URL
  * Provider uses the other user's existing session to determine his 
identifier, and allows the user to log in.
  * Provider returns an assertion with openid.identity set to the other 
user's identifier, but with openid.claimed_id still set to your delegate 
URL.
  * RP does discovery on the delegate URL and finds that its 
openid2.provider is the correct provider, so the assertion succeeds and 
the other user has logged in as you.

It seems to me that there are several different failings here that 
together result in this "hole":

  * The provider is not checking that openid.identity in the initial 
request is a valid identity for the active user. If it is not, an error 
message should be presented to the user. For example, in this case 
LiveJournal will say "The site you just came from seems to want to 
verify an identity that you, as exampleusername, cannot provide". Of 
course, the magic identity value for directed identity is valid for any 
user as a special case.

  * The RP, when verifying that the openid.claimed_id URL in the 
assertion is valid, checks only that the openid2.provider value is 
correct, and doesn't check that the openid2.local_id value matches 
(after removing the fragment part) the openid2.identity URL.

It's particularly concerning because it looks to the user like 
delegation is working correctly, and the user is unlikely to try to log 
in as another user to notice the vulnerability they've exposed 
themselves to.

Both of the above are currently allowed by the Auth 2.0 spec, but since 
doing the above checks doesn't seem to remove any useful possibilities, 
I think there ought to be some sort of errata that requires the checks 
I've listed above.

The latter check at the RP also suggests that OPs supporting multiple 
identifiers per user must not present the user with identifier 
substitution UI except in the directed identity case. The identifier 
asserted *must* match the identifier in the initial request, since in 
the delegation case that is the value of openid2.local_id that the RP 
will ultimately verify.

Sadly I didn't catch the full name of the guy that discovered this 
issue, but I believe his first name was John. Feel free to chime in and 
take credit for this, John!


[1] I won't name the provider here, since any users already doing 
delegation to their identifier at this provider will be vulnerable to 
the above. Folks from the provider were part of this conversation, so 
hopefully they will fix it by requiring that the requested identifier 
matches the authenticated user.