I'd like to amend my proposal for changing the delegation mechanism: Revised Proposal ================
As it stands, "openid.identity" is the identifier by which the IdP knows the user. There is no parameter by which the RP knows the user. I propose to add a field called "openid.rp_user_id" in "checkid_*" and "id_res" that defaults to "openid.identity" if it is missing. This field is the identifier by which the relying party knows the user. This is the identifier on which discovery was performed by the relying party. The name "openid.rp_user_id" is not the best, but it *is* very specific. Other suggestions welcome. Benefits ======== This proposal retains the current behaviour in terms of who is responsible for discovery and verification. It makes the messages between the RP and IdP more explicit. It is completely backwards-compatible. IdP-driven identifier selection can now return a delegated identifier (if the user wishes to do so). Drawbacks ========= The IdP now has knowledge of the identifier that the user entered at the relying party. Discussion ========== I think there is general agreement that the protocol messages on the wire can lead to confusing results. I also think that it's easy to get the relying party implementation wrong because it has to keep track of state to ensure that the user gets the right identifier. I don't think that most relying parties will have a problem keeping state, but I think it's not a good idea to make proper behavior (using the right identifier) *depend* on the relying party's implementation of state storage. This proposal is similar in spirit to Martin's proposal, in that it acknowledges that delegation is not really a special case. The main difference is that (a) it is obvious from the protocol messages what is going on and (b) discovery is entirely unchanged. Related threads =============== Original proposal: http://openid.net/pipermail/specs/2006-September/000002.html Brad's explanation of openid.delegate: http://openid.net/pipermail/specs/2006-October/000182.html Regarding the purpose of delegation: http://openid.net/pipermail/specs/2006-October/000170.html Martin's similar proposal: http://openid.net/pipermail/specs/2006-October/000216.html Josh _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs