Consolidated Delegate Proposal

[Dick Hardt]

I think a i-name IdP would have a display name for each i-name and  
show that consistent display name to the user. Why have the RP involved?

I think this delegate stuff is getting over complicated.

-- Dick

On 9-Oct-06, at 3:06 PM, Drummond Reed wrote:

> Dick,
>
> As Josh explains in
> http://openid.net/pipermail/specs/2006-October/000296.html, the  
> primary
> motivation for openid.display is when the user enters an i-name  
> into the RP.
> As Josh puts it:
>
> "Basically, =foo and =bar could both be tied to the same i-number.  
> Doing
> resolution on =foo and =bar will yield the same "canonical id,"  
> which means
> that they represent one logical entity. Drummond wants the display  
> name to
> tell the IdP *which* synonym the user entered at the RP so that the  
> IdP can
> present that same synonym in the UI, since the "canonical id" is both
> the IdP user identifier and the RP user identifier, but is not
> user-friendly (=!1234.1234.1234.1234)"
>
> It boils down to this:
>
> * If what the user enters at the RP is a URL, then there is at  
> least one and
> at most two identifiers involved -- the Claimed Identifier and an  
> optional
> Delegate Identifier.
> * If what the user enters at the RP is an XRI, then there are at  
> least two
> and at most three identifiers involved -- the Display Name (i- 
> name), the
> Claimed Identifier (i-number -- "CanonicalID"), and an optional  
> Delegate
> Identifier (which is usually the same CanonicalID but does not have  
> to be).
>
> Thus openid.display gives IdPs who support XRIs the ability to echo  
> back to
> the user the i-name synonym they typed in at the RP, rather than by  
> their
> CanonicalID i-number, which they are about as likely to know as  
> their IP
> address.
>
> If we decide that's totally unnecessary -- that it's always okay  
> for an IdP
> to just address an XRI user by an internal account name and not the  
> i-name
> synonym they used at the RP -- then we can drop openid.display.
>
> =Drummond
>
> -----Original Message-----
> From: Dick Hardt [mailto:dick at sxip.com]
> Sent: Monday, October 09, 2006 2:19 PM
> To: Drummond Reed
> Cc: 'Josh Hoyt'; 'Recordon, David'; specs at openid.net
> Subject: Re: Consolidated Delegate Proposal
>
> I have finally got up on this thread and don't see the value of the
> openid.display parameter.
>
> The RP does not know who the user is when the user is using OpenID to
> login, since that is why the RP is using OpenID, to find out who the
> user is.
>
> Having the user type in another parameter just lets the user see the
> same thing at the IdP. What's the point?
>
> The user clearly knows they are at two different sites, and I think
> it is more important to have a consistent experience at the IdP
> across RPs then to have a consistent experience between the RP and
> the IdP.
>
> The IdP must know who the user is in order to create a positive
> response back to the RP, so the IdP will already have some display
> values to show the user.
>
> ... so what am I missing?
>
> -- Dick
>
>
> On 9-Oct-06, at 10:56 AM, Drummond Reed wrote:
>
>> Josh, your message arrived while I was writing my reply to David's.
>>
>> I agree completely that openid.display is primarily useful for i-name
>> synonyms.
>>
>> You go on to say, "For URIs, the display name *must* be the same as
>> the RP
>> user identifier, because there is no other value is verifiable by
>> the IdP."
>>
>> I was proposing that openid.display be treated simply a string, so
>> neither
>> an RP nor an IdP would ever never resolve it, verify it, use it as
>> key, etc.
>>
>> openid.display would default to openid.rpuserid if the RP didn't
>> send an
>> openid.display value. And if openid.rpuserid was a CanonicalID,
>> then an RP
>> SHOULD at least send the i-name as openid.display.
>>
>> However if the RP wanted to prompt a user for a short Display Name,
>> even if
>> the User's Claimed Identifier was a URL, the RP *could* send this
>> Display
>> Name to the IdP, and the IdP *could* display it so the user
>> experience was
>> consistent across the two sites.
>>
>> For example:
>>
>> At RP site the prompts are:
>>
>> OpenID Identifier:
>> Your Preferred Display Name:
>>
>> The user enters:
>>
>> OpenID Identifier: example.idp.com/some/long/URL
>> Your Preferred Display Name: DSR
>>
>> The RP sends to IdP:
>>
>> openid.identity = http://example.idp.com/some/long/URL
>> openid.rpuserid = http://example.idp.com/some/long/URL
>> openid.display = DSR
>>
>> The IdP displays:
>>
>> Hello DSR. Do you want to login to YourFriendlyRP?
>> Password: [                ]
>> [Accept Once] {Accept Always] [Cancel]
>>
>>
>> =Drummond
>>
>> -----Original Message-----
>> From: joshhoyt at gmail.com [mailto:joshhoyt at gmail.com] On Behalf Of
>> Josh Hoyt
>> Sent: Monday, October 09, 2006 10:28 AM
>> To: Recordon, David
>> Cc: Drummond Reed; specs at openid.net
>> Subject: Re: Consolidated Delegate Proposal
>>
>> On 10/9/06, Recordon, David <drecordon at verisign.com> wrote:
>>> 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?
>>
>> The display name is only useful for XRI synonyms. Basically, =foo and
>> =bar could both be tied to the same i-number. Doing resolution on  
>> =foo
>> and =bar will yield the same "canonical id," which means that they
>> represent one logical entity. Drummond wants the display name to tell
>> the IdP *which* synonym the user entered at the RP so that the IdP  
>> can
>> present that same synonym in the UI, since the "canonical id" is both
>> the IdP user identifier and the RP user identifier, but is not
>> user-friendly (=!1234.1234.1234.1234)
>>
>> For URIs, the display name *must* be the same as the RP user
>> identifier, because there is no other value is verifiable by the IdP.
>>
>> Does that explanation help?
>>
>> Josh
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>>
>
>
>