Thanks David, but I don't think it is needed. In the flow that I proposed, I don't see that I need it, as I see that the delegate is only used by the IdP. What am I missing if anything?
-- Dick On 10-Oct-06, at 4:47 AM, Recordon, David wrote: > Dick, > It is needed in the case where there is delegation with a URL, > openid.identity is the actual URL on the IdP and then > openid.rpuserid is > the URL that the user entered which delegates to openid.identity. > This > is then also used in the similar case with XRI delegation. > > --David > > -----Original Message----- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 10, 2006 4:51 AM > To: Drummond Reed > Cc: Recordon, David; specs@openid.net > Subject: Re: Consolidated Delegate Proposal > > I am really unclear on why do we need both openid.identity and > openid.rpuserid? > > -- Dick > > On 10-Oct-06, at 12:47 AM, Drummond Reed wrote: > >> David, >> >> Based on feedback, I've backed openid.display out of the consolidated >> proposal at http://www.lifewiki.net/openid/ >> ConsolidatedDelegationProposal. >> >> This simplifies it to just two parameters, openid.identity and >> openid.rpuserid, which I believe now meet both Josh's and Martin's >> use > >> cases. >> >> =Drummond >> >> -----Original Message----- >> From: Recordon, David [mailto:[EMAIL PROTECTED] >> Sent: Monday, October 09, 2006 9:38 AM >> To: Drummond Reed; specs@openid.net >> Subject: RE: Consolidated Delegate Proposal >> >> In terms of openid.display, shouldn't the IdP greet the user in >> whatever manner it uses? Thus if the user has an account on the IdP, >> the IdP should always greet the user in the same manner with it. >> Seems like both a usability, phishing, and potential XSS issue if the >> IdP greets the user with a string from the RP. >> >> Am I just missing something there? >> >> --David >> >> -----Original Message----- >> From: Drummond Reed [mailto:[EMAIL PROTECTED] >> Sent: Monday, October 09, 2006 1:20 AM >> To: Recordon, David; specs@openid.net >> Subject: RE: Consolidated Delegate Proposal >> >>> 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 >> >> > > > _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs