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
