>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 _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs