Consolidated Delegate Proposal

[Drummond Reed]

No, you're not missing anything. That's what I thought at the outset too.
And you may well be right -- the IdP can always use openid.identity to
lookup the user's IdP account and retrieve an an internal display name from
there.

However I don't believe there's a security or phishing issue here -- the IdP
would only echo the Display Name, if any, passed from the IdP. In other
words, if the RP prompts for a Display Name, and the User enters one at the
RP, then it's perfectly natural that the IdP can turn around and address the
User by the same Display Name, since the IdP is authenticating the User's
identity in the context of the RP.

That doesn't mean the IdP can't also display it's own identifier(s) for the
User if it wants (or other tokens that help prove to the User that they are
not being phished).

It's not just for i-names that openid.display is useful -- it's also handy
for long URLs, where an RP is motivated to give the user a shorter display
name to better control screen real estate.

Anyway, those are the basic use cases. If there's not enough value in
openid.display then we can drop it. openid.rpuserid is the meat of the
proposal, because it enables a clean separation between the IdP-facing
identifier (openid.identity) and the RP-facing-identifier (openid.rpuserid).

=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