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