Consolidated Delegate Proposal

[Dick Hardt]

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