Unless I'm misunderstanding, that will work with the OpenID Connect proposal.
I have https://davidrecordon.com/ and have signed up for Example Server which lets me specify a custom user identifier. LRDD on davidrecordon.compoints to the token endpoint on https://example-server.com/. Example Server then issues https://davidrecordon.com/ as the user identifier. Or of course I could run all of this myself on davidrecordon.com via SSL. --David On Sun, May 16, 2010 at 3:00 PM, SitG Admin <[email protected] > wrote: > 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 >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
