Consolidated Delegate Proposal

[Recordon, David]

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:dick at sxip.com] 
Sent: Tuesday, October 10, 2006 4:51 AM
To: Drummond Reed
Cc: Recordon, David; specs at 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:drecordon at verisign.com]
> Sent: Monday, October 09, 2006 9:38 AM
> To: Drummond Reed; specs at 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:drummond.reed at cordance.net]
> Sent: Monday, October 09, 2006 1:20 AM
> To: Recordon, David; specs at 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 at openid.net
> http://openid.net/mailman/listinfo/specs
>
>