Consolidated Delegate Proposal

Recordon, David drecordon at verisign.com
Mon Oct 9 16:37:59 UTC 2006


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 





More information about the specs mailing list