Consolidated Delegate Proposal

[Drummond Reed]

>David Recordon wrote:
>
>Read through it 
>(http://www.lifewiki.net/openid/ConsolidatedDelegationProposal), 
>and I'm liking how it really clears up delegation.  A
>few questions:
>
>1) In case 1, is what the user typed in ever sent from the RP to the
>IdP?  What if it is an OpenID Auth 2.0 IdP, but the user entered their
>identifier on the RP?  Or in the case where the IdP supports multiple
>identifiers for the user, shouldn't the RP send what the user entered so
>the user doesn't have to choose it again at their IdP?

Case 1 is the directed identity case. The RP *could* send what the user
types in at the RP (the identifier for the IdP's directed identity server),
but since the RP knows (from the OpenID service type) that this is an
anonymous login, and thus that the RP needs to get openid.rd_user_id *back*
from the IdP, it seemed better for the RP not to send anything. This way you
never break the rule that the IdP never changes any of the identifier
parameters than an RP sends it.

>2) This may also be part of my first question, but why is there such a
>delta between case 1 and cases 2 and 3?  How does the RP know to use
>case 1 versus case 2, they seem quite similar in their explanation?

Again, Case 1 is the directed identity case, that's why it's so unusual. The
way the RP differentiates between case 1 and cases 2/3/4/5 is that only in
case 1 is the value <Type> attribute in the OpenID service endpoint
"http://openid.net/identifier_select/2.0".

I went back and rewrote the page to make this much clearer.

>3) What is openid.display used for?

The complete explanation was in the latter part of
http://openid.net/pipermail/specs/2006-October/000278.html. But to make the
consolidated proposal easier to review, I added a "Summary of Motivations"
section at the start and put a section at the end explaining the motivation
for openid.display. 

>4) In the rules, don't you mean the IdP must return the value of the
>rp_user_id for the RP to key off of, not the value of identity?

Yes, sorry, this was unclear. What I meant was that since the RP must ALWAYS
send openid.identity, the RP could *ALWAYS* count on this in the response.
However you're right that as far as a persistent key goes 

>I think this is getting there, just either needs to be tightened up or
>the different flows better explained.

I think it just needed to be better explained. Also, Josh, note that when I
went back to edit this tonight, I found the parameter name
"openid.rp_user_id" was driving the wiki markup nuts. So I changed it to
just "openid.rpuserid". Personally, I think this reads fine and eliminates
the awkward underscores. I hope you agree.

=Drummond