Consolidated Delegate Proposal

Dick Hardt dick at sxip.com
Tue Oct 10 19:33:24 UTC 2006


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: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
>>
>>
>
>
>




More information about the specs mailing list