Delegation Proposal Amendment

[Josh Hoyt]

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