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:[EMAIL PROTECTED] > Sent: Monday, October 09, 2006 2:19 PM > To: Drummond Reed > Cc: 'Josh Hoyt'; 'Recordon, David'; specs@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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of >> Josh Hoyt >> Sent: Monday, October 09, 2006 10:28 AM >> To: Recordon, David >> Cc: Drummond Reed; specs@openid.net >> Subject: Re: Consolidated Delegate Proposal >> >> On 10/9/06, Recordon, David <[EMAIL PROTECTED]> 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@openid.net >> http://openid.net/mailman/listinfo/specs >> >> > > > _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs