Building identity on top of OAuth 2.0?

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


>The second is the actual user identifier. This is what needs to be 
>hosted over SSL if it's a URL and is ultimately what clients use to 
>distinguish between users.

The shift, as I understand it, is from a URI/OP delegation model 
(where the OP is assumed to have exercised due diligence in keeping 
the user's identity secure, but RP's rely on the URI being secure), 
to an OP model (where RP's rely on the OP being secure). The essence 
of this shift is that you have removed the (presumed-to-be) insecure 
*URI*, which delegated *to* OP's.

I propose modifying this shift/split: continue focusing on this 
reliance upon the *OP* to be secure, but also leave room for a *URI* 
being primary *if and only if* that URI (which delegates to OP's) is 
*also* served over SSL.

The essence of this modification would be a split between the 
concepts of "secure identifier" and "convenience of identifying": 
both concentrated in the OP by default, but if you want to have a URI 
that you trust as "secure identifier" (however difficult it is to 
effect any changes this way), and an OP that serves for day-to-day 
business, this is acceptable too.

-Shade


More information about the specs mailing list