Building identity on top of OAuth 2.0?

SitG Admin sysadmin at shadowsinthegarden.com
Sun May 16 22:13:37 UTC 2010


>The malicious server could only compromise user identifiers which 
>point to it. Obviously if the person controlling the malicious 
>server also controls the domain itself then they could make every 
>URI on the domain point to it.

I must be missing another middleman here, then. I thought you were 
removing delegation and replacing it with "anyone can point to the 
actual identifier, only verify this during each individual 
authentication":

"Rather delegation creates a link between your blog URL and identifier.

For example, http://www.davidrecordon.com/ has a link tag to 
https://server.myopenid.com/ and a link rel-me tag with a value of 
https://david.myopenid.com/. Thus OpenID Connect is performed against 
MyOpenID and MyOpenID returns a user identifier of 
https://david.myopenid.com/. If you wanted a bidirectional link then 
the OpenID Connect User Info API could also set the user's profile 
URL to http://www.davidrecordon.com/."

So, if MyOpenID turns evil, they can register 
http://www.youropenid.com/ and give it a link tag to 
https://server.myopenid.com/ and a link rel-me tag with a value of 
https://david.myopenid.com/, then authenticate to themselves; they 
also begin reporting that the user's new profile URL is 
http://www.youropenid.com/.

>Don't use a server you don't trust. This is no different

The difference with OpenID *used to be* that, if MyOpenID turned 
evil, you could change the links on http://www.davidrecordon.com/, 
and the RP's wouldn't accept assertions from MyOpenID anymore. The 
problem was that most people didn't have their own vanity domain that 
they personally controlled; they had http://username.domainname.com/ 
or some equivalent, and whoever hosted domainname could change the 
links to their own OP, running the same scam. I see why the URI host 
has been cut out of the equation (fewer middlemen, fewer points of 
failure in the whole chain), but I also see the responsibility for 
keeping users' identities safe being kept in the same area as those 
entities who have a direct (business) interest in their users' 
identities, and not necessarily "securely under the users' control".

Neither the old nor the new is pleasant. It's just a different kind 
of unpleasant, really.

-Shade


More information about the specs mailing list