@openid.net
Subject: Re: Consolidated Delegate Proposal
I don't see there being general consensus.
I think Chris Drake was supportive of there being less disclosure as
well.
Josh said it could be any of the three, but preferred two parameters.
Brad did not really care.
I do care and would like
On 13-Oct-06, at 3:43 PM, Josh Hoyt wrote:
On 10/13/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
The IdP is issuing a signed assertion about these identifiers, I
would assume the IdP to check the link between these identifiers.
Sending two identifiers does not *prevent* the IdP from
Subject: Re: Consolidated Delegate Proposal
On 10/17/06, Dick Hardt [EMAIL PROTECTED] wrote:
2. It is explicit what is going on from an implementation and
specification perspective
And I see the opposite. What the RP sends the IdP is just a hint.
What the IdP sends the RP is authoritative.
I
Dick Hardt wrote:
Won't the IdP will still have to resolve the i-name? The IdP can't
trust the RP, or know that the i-name and i-number are really linked
unless it checks itself.
The IdP is only authenticating the i-number. The i-name is for display
to the user and possibly to allow
Martin wrote:
I think this is the intention, though it does show an interesting
inconsistency between the use of XRIs and the use of i-numbers. I
currently have three URL-based identifiers all pointing at the same
server and the same Yadis document, yet those identifiers are distinct.
On 12-Oct-06, at 11:40 PM, Drummond Reed wrote:
Drummond wrote:
Since the RP has to do discovery on the i-name, the RP already
has the
i-number (CanonicalID). Further, as explained in previous
threads, the
CanonicalID is the primary key the RP wants to store for the user,
not the
On 10/13/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
The IdP is issuing a signed assertion about these identifiers, I
would assume the IdP to check the link between these identifiers.
Sending two identifiers does not *prevent* the IdP from checking to
make sure they match.
What if a bad RP
On 10-Oct-06, at 2:08 PM, Drummond Reed wrote:
On 10/10/06, Dick Hardt wrote:
[openid.rpuserid is the identifier] that the user gave the RP?
Josh Hoyt wrote:
For URL identifiers, it is the supplied identifer, normalized, after
following redirects. In essence, it's the user's chosen
Martin wrote:
I'm surprised that our resident privacy advocates aren't making a
bigger
deal out of this. (If the privacy advocates have no problem then I'll
let this go, since this isn't a use case I feel particularly strongly
about myself.)
Dick wrote:
I was supportive of keeping the
+1
Well said Chris.
On 10-Oct-06, at 11:22 PM, Chris Drake wrote:
This is backwards: Users have already chosen the IdP whom they trust
to look after their identity and privacy: and except for the unlikely
double-blind scenarios, no user will want to hide RP info and usage
from their own
.
=Drummond
-Original Message-
From: Recordon, David [mailto:[EMAIL PROTECTED]
Sent: Monday, October 09, 2006 9:38 AM
To: Drummond Reed; specs@openid.net
Subject: RE: Consolidated Delegate Proposal
In terms of openid.display, shouldn't the IdP greet the user in whatever
manner it uses
; specs@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
Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 10, 2006 4:51 AM
To: Drummond Reed
Cc: Recordon, David; specs@openid.net
Subject: Re: Consolidated Delegate Proposal
I am really unclear on why do we need both openid.identity and
openid.rpuserid?
-- Dick
On 10-Oct-06
Recordon, David wrote:
Dick,
It is needed in the case where there is delegation with a URL,
openid.identity is the actual URL on the IdP and then openid.rpuserid is
the URL that the user entered which delegates to openid.identity. This
is then also used in the similar case with XRI
On 10-Oct-06, at 11:26 AM, Martin Atkins wrote:
Josh Hoyt wrote:
On 10/10/06, Martin Atkins wrote:
Does the IdP really need to know what URL I gave to the RP?
Earlier versions handled this adequately by the library including
implementer-defined variables in the return_to URL, which allows
Martin wrote:
I'm surprised that our resident privacy advocates aren't making a
bigger
deal out of this. (If the privacy advocates have no problem then I'll
let this go, since this isn't a use case I feel particularly strongly
about myself.)
Dick wrote:
I was supportive of keeping the
On 10-Oct-06, at 11:44 AM, Josh Hoyt wrote:
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote:
I don't think the delegate needs to be moved. Please see
http://openid.net/pipermail/specs/2006-October/000310.html
If I understand it correctly, this is identical to my original
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote:
RP user id is the identifier by which the relying party knows the
user.
This is the one that the user gave the RP?
For URL identifiers, it is the supplied identifer, normalized, after
following redirects. In essence, it's the user's chosen
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote:
My proposal was pretty much your proposal with a couple tweaks
(sorry, I should have listed these to make it clearer)
- the IdP can return a different identity then the one the RP sent over
I question whether this is something we want to
On 10-Oct-06, at 11:54 AM, Josh Hoyt wrote:
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote:
RP user id is the identifier by which the relying party knows the
user.
This is the one that the user gave the RP?
For URL identifiers, it is the supplied identifer, normalized, after
following
On 10-Oct-06, at 11:58 AM, Josh Hoyt wrote:
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote:
My proposal was pretty much your proposal with a couple tweaks
(sorry, I should have listed these to make it clearer)
- the IdP can return a different identity then the one the RP sent
over
I
On 10-Oct-06, at 12:48 PM, Drummond Reed wrote:
Drummond wrote:
If we've got it wrong there, and there is a way to do all of this
with one
parameter, by all means do explain and we can finally close this
issue.
Dick wrote:
I thought I did explain it. :-)
I will explain it again in a
On 10-Oct-06, at 11:54 AM, Josh Hoyt wrote:
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote:
RP user id is the identifier by which the relying party knows the
user.
This is the one that the user gave the RP?
For URL identifiers, it is the supplied identifer, normalized, after
following
Drummond wrote:
Better still, if you could add it to the end of
http://www.lifewiki.net/openid/ConsolidatedDelegationProposal and
explain
how the same motivations and use cases currently covered there
(using two
identifier parameters) can be satisfied just using openid.identity,
On 10/10/06, Dick Hardt wrote:
[openid.rpuserid is the identifier] that the user gave the RP?
Josh Hoyt wrote:
For URL identifiers, it is the supplied identifer, normalized, after
following redirects. In essence, it's the user's chosen identifier.
For XRI identifers, it's the canonical ID
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote:
The IdP cannot trust the RP's discovery. The IdP will have to make
sure that the IdP is authoritative for the identifier regardless.
The IdP doesn't have to trust the relying party's discovery. The IdP
*can* make sure that it is authoritative for
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
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,
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
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
'; '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
At David's suggestion, to make it easier to follow, I've posted what I
believe is a consolidated delegate proposal at:
http://www.lifewiki.net/openid/ConsolidatedDelegationProposal
This incorporates Josh's original, Martin's, Josh's amendment, and my
amendment to Josh's.
Josh
32 matches
Mail list logo
