RE: Consolidated Delegate Proposal
Maybe I misunderstood the directed identity protocol. Section 4.2.3.1 of Draft 9 says: *** EXCERPT *** 4.2.3.1. IdP Identifiers If the entered Identifier is an IdP Identifier, the OpenID information is contained in a service element with the following information: * An xrd:Type tag whose text content is http://openid.net/server/2.0; * An xrd:URI tag whose text content is The IdP Endpoint URL *** END *** So in the discovery phase what the RP should find is an xrd:Type tag of http://openid.net/server/2.0;. That's what I meant. Am I missing something? =Drummond -Original Message- From: Recordon, David [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 9:34 AM To: Drummond Reed; specs@openid.net Subject: RE: Consolidated Delegate Proposal Ok, that makes it more clear. I think this line was part of what was throwing me, If Claimed Identifier is EITHER a URL or XRI that maps to a directed identity server (http://openid.net/server/2.0), the values are: since in the discovery phase it should be finding the type of identifier_select. --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 1:20 AM To: Recordon, David; specs@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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
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
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
RE: Delegation Proposal Amendment
Dick, The persistent identifier I referred to in this thread was whatever identifier the RP was going to persist (proposed to be called openid.rpuserid on http://www.lifewiki.net/openid/ConsolidatedDelegationProposal). This boils down to: * If Claimed Identifier = URL, then openid.rpuserid = URL * If Claimed Identifier = XRI i-name (reassignable), then openid.rpuserid = XRI i-number (CanonicalID - persistent). Both are discoverable from the XRDS document once the RP has done discovery. That's cases 2/3/4/5 on http://www.lifewiki.net/openid/ConsolidatedDelegationProposal. Thus the only case where the RP does not have an identifier to persist is the directed identity case (Case 1). In that case, the RP does not send openid.rpuserid, but instead receives it back in the response from IdP. =Drummond -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 2:21 PM To: Drummond Reed Cc: 'Josh Hoyt'; specs@openid.net Subject: Re: Delegation Proposal Amendment Drummond How does the RP get a persistent identifier before it has called the IdP? The user could type anything into the form. -- Dick On 6-Oct-06, at 2:22 PM, Drummond Reed wrote: Josh, This is very cool. Adding openid.rp_user_id would give us an unambigous way to represent what I called the RPI in my earlier message: IPI = IdP-Persistent-Identifier = openid.identity RPI = RP-Persistent-Identifier = openid.rp_user_id It doesn't address the third identifier, which I called UPI (User-Presented-Identifier -- the one the user typed in at the RP), but let's leave that aside for now. So as I understand it, the rules would be: * ON THE RP SIDE * The RP ALWAYS does discovery on UPI. Then it applies these tests: 1) If UPI maps to a directed identity server (Typehttp://openid.net/server/2.0/Type), then: openid.rp_user_id = [empty] openid.identity = http://openid.net/identifier_select/2.0; 2) If UPI is an XRI that maps to a CanonicalID AND there is no openid:delegate element in the XRD, then: openid.rp_user_id = CanonicalID openid.identity = CanonicalID 3) If UPI is an XRI that maps to a CanonicalID AND to an IPI (via the openid:delegate element in the XRD), then: openid.rp_user_id = CanonicalID openid.identity = IPI 4) If UPI is a URL that maps to an IPI (via the openid:delegate element in the XRD), then: openid.rp_user_id = UPI openid.identity = IPI 5) Else: openid.rp_user_id = UPI openid.identity = UPI * ON THE IDP SIDE * 6) IdP ALWAYS keys on the value of openid.identity. 7) IdP ALWAYS returns the same value of openid.identity that the RP sent (so the RP can always key off this value in the response). 8) IdP ALWAYS returns the value of openid.rp_user_id UNLESS it was empty, in which case see rule 9a below. 9) IdP MAY or MAY NOT do discovery. The rules are: a) If openid.identity = http://openid.net/identifier_select/2.0;, then IdP prompts User for UPI (or detects cookie, etc.). If UPI != IPI, then IdP does discovery on UPI to get mapping to IPI. IdP authenticates against IPI, but at that point allows user to select the RPI (or generates for the user). IdP returns: openid.rp_user_id = user-selected or IdP-generated RPI openid.identity = http://openid.net/identifier_select/2.0; b) If openid.identity = UPI that IdP does not recognize, then IdP does discovery on UPI to get mapping to IPI. After authentication against IPI, IdP returns: openid.rp_user_id = UPI openid.identity = UPI c) If openid.identity = IPI, IdP does not need to do discovery, but authenticates against IPI and returns: openid.rp_user_id = [value sent by RP] openid.identity = IPI * This all works wonderfully and covers all the use cases -- congratulations! Now, let me make a case for also making the third identifier -- the UPI -- explicit in the protocol. This addresses a specific usability issue that arises due to the fact that XRIs support i-name/CanonicalID separation, which URLs don't. However I believe it can also improve usability for URLs. The motivation is that in cases 2 and 3 above, the openid.rp_user_id that the RP passes to the IdP is going to be an CanonicalID, which is an i-number. This is a very ugly string like: =!F83.62B1.44F.2813 (that's my actual i-number) However the IdP only has the choice of openid.rp_user_id or openid.identity from which to greet me to ask for my authentication credentials. Since these will both be a CanonicalID, this leads to a greeting like: Hello =!F83.62B1.44F.2813. Please confirm that you want to login to YourFavoriteRP. [Allow Once] [Allow Always] [Cancel] All it takes to solve this problem is for the RP to pass the UPI in the authentication request. Then the IdP can say: Hello
Re: [VOTE] Rename openid.nonce to openid.response_nonce
+1 Allows us to easily have a request_nonce now or in the future and have clarity on what is what -- Dick On 9-Oct-06, at 2:19 PM, Recordon, David wrote: Judging from a lack of responses, I'm guessing people don't really care. Is this a correct assessment? I'm +1 to this to add clarity, though also in the don't really care boat at the same time. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Thursday, October 05, 2006 5:25 PM To: specs@openid.net Subject: [VOTE] Rename openid.nonce to openid.response_nonce Stemming from the proposal to add a request nonce, the idea to rename the openid.nonce field to openid.response_nonce surfaced. Is this something that we should do? Vote closes Tuesday the 10th at 3:30pm PST. Votes are +1 (in support of idea), 0 (abstain), or -1 (disagree). Traditionally a -1 vote, with appropriate technical reasoning, will cause the vote as a whole to fail. In this case, I believe it will be best to make the decision tallying all votes for and against unless a strong technical argument can be made for not renaming this parameter. --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Re[2]: [PROPOSAL] Separate Public Identifier from IdP Identifier
On 6-Oct-06, at 11:14 AM, Chris Drake wrote: An ***IdP*** can *initiate* the OpenID login with the RP using openid:Token. How the User arrived at the RP with this token is not the concern of the RP. (could be javascript, browser plugins, participating IdP helper CGIs, or even the RP itself). The point is - the guts of the authentication process remains unchanged and is backwards compatible, but all the privacy-invasive components that live at the RP are thus made *optional*. Simple as that. User only needs to remember and use one ID. User only needs to type it one time each day (or however long they elect to stay logged on for). Datamatching and privacy invasion are eradicated. No need to key custom IdP anonymity URLs ever. Even facilitates double-blind anonymous logins (with inclusion of a simple RP nonce extension). Win-win-win. This is a great idea Chris! Since the protocol from the RP point of view is it receives a POST for the browser, how that gets started does not matter to the RP. Now all we need is a way for the IdP to know which URL to send the post. A couple options: 1) the RP includes the login URL in request messages to the IdP. The IdP saves it for allowing the user to bookmark. 2) the RP has the login URL somewhere easily discoverable by the IdP I would propose that both methods are supported. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation Proposal Amendment
ok -- I get it now -- I think it is a bad name as it implies that this is the identifier that the RP persists across sessions really, it is the user identifier that the RP gets -- Dick On 9-Oct-06, at 2:38 PM, Drummond Reed wrote: Dick, The persistent identifier I referred to in this thread was whatever identifier the RP was going to persist (proposed to be called openid.rpuserid on http://www.lifewiki.net/openid/ConsolidatedDelegationProposal). This boils down to: * If Claimed Identifier = URL, then openid.rpuserid = URL * If Claimed Identifier = XRI i-name (reassignable), then openid.rpuserid = XRI i-number (CanonicalID - persistent). Both are discoverable from the XRDS document once the RP has done discovery. That's cases 2/3/4/5 on http://www.lifewiki.net/openid/ConsolidatedDelegationProposal. Thus the only case where the RP does not have an identifier to persist is the directed identity case (Case 1). In that case, the RP does not send openid.rpuserid, but instead receives it back in the response from IdP. =Drummond -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 2:21 PM To: Drummond Reed Cc: 'Josh Hoyt'; specs@openid.net Subject: Re: Delegation Proposal Amendment Drummond How does the RP get a persistent identifier before it has called the IdP? The user could type anything into the form. -- Dick On 6-Oct-06, at 2:22 PM, Drummond Reed wrote: Josh, This is very cool. Adding openid.rp_user_id would give us an unambigous way to represent what I called the RPI in my earlier message: IPI = IdP-Persistent-Identifier = openid.identity RPI = RP-Persistent-Identifier = openid.rp_user_id It doesn't address the third identifier, which I called UPI (User-Presented-Identifier -- the one the user typed in at the RP), but let's leave that aside for now. So as I understand it, the rules would be: * ON THE RP SIDE * The RP ALWAYS does discovery on UPI. Then it applies these tests: 1) If UPI maps to a directed identity server (Typehttp://openid.net/server/2.0/Type), then: openid.rp_user_id = [empty] openid.identity = http://openid.net/identifier_select/2.0; 2) If UPI is an XRI that maps to a CanonicalID AND there is no openid:delegate element in the XRD, then: openid.rp_user_id = CanonicalID openid.identity = CanonicalID 3) If UPI is an XRI that maps to a CanonicalID AND to an IPI (via the openid:delegate element in the XRD), then: openid.rp_user_id = CanonicalID openid.identity = IPI 4) If UPI is a URL that maps to an IPI (via the openid:delegate element in the XRD), then: openid.rp_user_id = UPI openid.identity = IPI 5) Else: openid.rp_user_id = UPI openid.identity = UPI * ON THE IDP SIDE * 6) IdP ALWAYS keys on the value of openid.identity. 7) IdP ALWAYS returns the same value of openid.identity that the RP sent (so the RP can always key off this value in the response). 8) IdP ALWAYS returns the value of openid.rp_user_id UNLESS it was empty, in which case see rule 9a below. 9) IdP MAY or MAY NOT do discovery. The rules are: a) If openid.identity = http://openid.net/identifier_select/2.0;, then IdP prompts User for UPI (or detects cookie, etc.). If UPI != IPI, then IdP does discovery on UPI to get mapping to IPI. IdP authenticates against IPI, but at that point allows user to select the RPI (or generates for the user). IdP returns: openid.rp_user_id = user-selected or IdP-generated RPI openid.identity = http://openid.net/identifier_select/2.0; b) If openid.identity = UPI that IdP does not recognize, then IdP does discovery on UPI to get mapping to IPI. After authentication against IPI, IdP returns: openid.rp_user_id = UPI openid.identity = UPI c) If openid.identity = IPI, IdP does not need to do discovery, but authenticates against IPI and returns: openid.rp_user_id = [value sent by RP] openid.identity = IPI * This all works wonderfully and covers all the use cases -- congratulations! Now, let me make a case for also making the third identifier -- the UPI -- explicit in the protocol. This addresses a specific usability issue that arises due to the fact that XRIs support i-name/CanonicalID separation, which URLs don't. However I believe it can also improve usability for URLs. The motivation is that in cases 2 and 3 above, the openid.rp_user_id that the RP passes to the IdP is going to be an CanonicalID, which is an i-number. This is a very ugly string like: =!F83.62B1.44F.2813 (that's my actual i-number) However the IdP only has the choice of openid.rp_user_id or openid.identity from which to greet me to ask for my authentication credentials. Since these will both be a CanonicalID, this leads to a greeting like: Hello =!F83.62B1.44F.2813. Please confirm that
RE: Consolidated Delegate Proposal
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
Re: Consolidated Delegate Proposal
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,
PROPOSAL: OpenID Authentication Flow and how delegate fits in
I'll start off with a couple new definitions so that we are not hung up on what terms mean: supplied_identifier := what the user types into the RP's form verified_identifier := the identifier that the IdP says the user is When looking at the OpenID protocol, the openid.identity sent from the RP to the IdP can be thought of as just a hint as to what verified_identifier the user wants to be at the RP. Given that, I would describe the flow as such: 1) User provides a supplied_identifier to the RP. The user may type this into a form which will post the supplied_identifier to the RP's login_url or a software agent may post this to the login_url. The supplied_identifier may be an: OpenID URL iname IdP URL 2) The RP then does the appropriate discovery on supplied_identifier to find the IdP's entry point and functionality supported. The delegate tag is ignored if present. 3) If the RP wants to get a verified_identifier for the user, the RP sends an indirect message to the IdP containing openid.identity=supplied_identifier, otherwise openid.identity=none to indicate it does not want a verified_identifier. 4) if a verified_identifier was requested, the IdP determines which verified_identifier the user would like to be with the RP, and then sends an indirect message with openid.identity=verified_identifier to the RP. Although the user may have typed in one OpenID URL or iname, a different one could be in the response back to the RP. 5) If the RP has not already determined that the IdP is authorative for verified_identifier, then the RP does discovery on the verified_identifier to confirm the IdP is authoritative. + The IdP knows what the user typed into the form at the RP since that is what is sent to the IdP. + The IdP can display a friendly name to the user as to what they are releasing. + The IdP can assist the user in determining which verified_identifier they want to be at a site. Eg. the user may have forgotten which verified_identifier they were in the past, and the IdP can ask the user to confirm they want to use a different verified_identifer then the one they have previously used. + works with OpenID 1.1 as even though a 1.1 RP will send the delegate, a 2.0 IdP will send back the verified_identifier. NOTE: The delegate tag is just a token that the user sticks into their HTML so that the IdP knows the user controls that URL. If the IdP controls the URL, then the delegate tag is not needed. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
