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
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://o
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 wil
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
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 R
+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 cl
On 6-Oct-06, at 8:41 PM, Chris Drake wrote:
> KT> On Fri, 2006-10-06 at 16:34 -0700, Drummond Reed wrote:
>>> Let me play the dumb customer here and say:
>>>
>>> * A whole lot of real-world users would love OpenID-enabled
>>> bookmarks.
>>> * A whole lot of websites would love to offer them.
>>
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 = UR
On 9-Oct-06, at 1:12 AM, Josh Hoyt wrote:
> On 10/8/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
>> [...] I would want the site to prompt for a password if I was
>> doing something
>> important. The only way for the IdP to know that is for the RP to
>> tell it somehow -> auth_age request.
>
> This
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
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 Re
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 le
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.
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 -- t
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, phishin
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 tag whose text cont
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 st
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.
On 10/8/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> [...] I would want the site to prompt for a password if I was doing something
> important. The only way for the IdP to know that is for the RP to
> tell it somehow -> auth_age request.
This is only useful in conjunction with signed requests. A ma
19 matches
Mail list logo
