Consolidated Delegate Proposal

Dick Hardt dick at sxip.com
Tue Oct 10 09:51:02 UTC 2006


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