>Chris Drake [mailto:[EMAIL PROTECTED]
>
>The only thing I want to see, which can then be used to accommodate
>privacy protection, is for RP's to accept an IdP-initiated login.
>It's none of the RPs business how my user selected their
>openid.identity for presentation to the RP.
+1. I've become a
>> 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 suppo
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
>>> 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
> 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.id
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
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. :-)
>>
>>
>> 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 separate post.
Better still, if
Thanks David, but I don't think it is needed. In the flow that I
proposed, I don't see that I need it, as I see that the delegate is
only used by the IdP. What am I missing if anything?
-- Dick
On 10-Oct-06, at 4:47 AM, Recordon, David wrote:
> Dick,
> It is needed in the case where there is
You got it. The irony is that as simple are compared to i-names, i-numbers
are the real anchor of persistent identity and identifier portability.
It's like IP addresses and DNS names: the former do all the work, and the
latter get all the visibility.
=Drummond
-Original Message-
From: D
On 10-Oct-06, at 12:10 PM, Drummond Reed wrote:
>>> Josh Hoyt wrote:
>>>
>>> If I understand it correctly, this is identical to my original
>>> proposal[1]. I added rp_user_id because it prevents the IdP from
>>> having to do discovery when the RP has already done it. It is also a
>>> smaller cha
>> Josh Hoyt wrote:
>>
>> If I understand it correctly, this is identical to my original
>> proposal[1]. I added rp_user_id because it prevents the IdP from
>> having to do discovery when the RP has already done it. It is also a
>> smaller change in the way that things work.
>
>The IdP cannot trust
Ok, I think I get the justification now:
i-numbers are in unlimited supply and have no inherent value except
as a handle, so they don't need to be managed the same way
i-names are a namespace and hence are limited, and have value to
humans, so there is value in separating the handle from the
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
>>
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
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 en
>> On 10-Oct-06, at 11:00 AM, Drummond Reed wrote:
>>
>> Again, this is why I recommend RPs don't even store the i-name, but
>> instead
>> store their own display name for the user. The display name and the
>> i-number
>> (CanonicalID) never need to change, whereas an i-name may be
>> reassi
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 chos
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
> p
Drummond Reed wrote:
>>
>> I was supportive of keeping the delegate from the IdP until I
>> realized that the delegation was public knowledge and could not be
>> hidden from the IdP.
>
> The same argument convinced me, too. If public XRDS documents are what we're
> using to provide user contro
oops. Forgot footnote:
1. http://openid.net/pipermail/specs/2006-September/02.html
On 10/10/06, Josh Hoyt <[EMAIL PROTECTED]> 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/
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
proposal[1]. I added rp_user_id because it prevents the
> 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
On 10-Oct-06, at 11:29 AM, Martin Atkins wrote:
> Dick Hardt wrote:
>>
>> Given that a Google of the delegate tag will yield all URLs
>> containing it,
>> there is no value in hiding delegation anymore.
>>
>
> If I considered it important enough, I could restrict access to my
> Yadis
> document
>> Drummond Reed wrote:
>>
>> Right on the money. I would go further and recommend that an RP not even
>> store the i-name, just the i-number and a user's preferred display name.
>> That way the i-name becomes really just a convenient way for the user to
>> give the RP their i-number (CanonicalID)
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,
Dick Hardt wrote:
>
> Given that a Google of the delegate tag will yield all URLs
> containing it,
> there is no value in hiding delegation anymore.
>
If I considered it important enough, I could restrict access to my Yadis
document to only one party using various techniques, thus preventing
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 a
>> stateful RP to hide the real identifie
On 10-Oct-06, at 11:00 AM, Drummond Reed wrote:
> Again, this is why I recommend RPs don't even store the i-name, but
> instead
> store their own display name for the user. The display name and the
> i-number
> (CanonicalID) never need to change, whereas an i-name may be
> reassigned.
why
On 10-Oct-06, at 10:23 AM, Josh Hoyt wrote:
> On 10/10/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
>> I am really unclear on why do we need both openid.identity and
>> openid.rpuserid?
>
> RP user id is the identifier by which the relying party knows the
> user.
This is the one that the user gave
On 10-Oct-06, at 10:18 AM, Martin Atkins wrote:
> 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.
Drummond Reed wrote:
>
> Right on the money. I would go further and recommend that an RP not even
> store the i-name, just the i-number and a user's preferred display name.
> That way the i-name becomes really just a convenient way for the user to
> give the RP their i-number (CanonicalID).
>
I
Ah! Great answer !! ;-)
On Oct 10, 2006, at 11:00, Drummond Reed wrote:
Johannes Ernst wrote:
Drummond:
The current auth draft says in section 11.4:
If the Verified Identifier is an XRI, the discovered CanonicalID
field from the XRD SHOULD be used as a key for local storage of
information
>Johannes Ernst wrote:
>> Drummond:
>>
>> The current auth draft says in section 11.4:
>> If the Verified Identifier is an XRI, the discovered CanonicalID
>> field from the XRD SHOULD be used as a key for local storage of
>> information about the End User.
>>
>> Is there ever a scenario whe
On 10/10/06, Martin Atkins <[EMAIL PROTECTED]> 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 a
> stateful RP to hide the real identifier be
>Johannes Ernst wrote:
>
>Drummond:
>
>The current auth draft says in section 11.4:
> If the Verified Identifier is an XRI, the discovered CanonicalID
>field from the XRD SHOULD be used as a key for local storage of
>information about the End User.
>
>Is there ever a scenario where the iden
Johannes Ernst wrote:
> Drummond:
>
> The current auth draft says in section 11.4:
> If the Verified Identifier is an XRI, the discovered CanonicalID
> field from the XRD SHOULD be used as a key for local storage of
> information about the End User.
>
> Is there ever a scenario where the id
On 10/10/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> I am really unclear on why do we need both openid.identity and
> openid.rpuserid?
RP user id is the identifier by which the relying party knows the
user. "openid.identity" is the IdP user id. The IdP user id is the
"delegate" if one is present,
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 deleg
Drummond:
The current auth draft says in section 11.4:
If the Verified Identifier is an XRI, the discovered CanonicalID
field from the XRD SHOULD be used as a key for local storage of
information about the End User.
Is there ever a scenario where the identifier is disassociated from
t
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 delegation.
--David
-Original M
I am really unclear on why do we need both openid.identity and
openid.rpuserid?
-- Dick
On 10-Oct-06, at 12:47 AM, Drummond Reed wrote:
> David,
>
> Based on feedback, I've backed openid.display out of the consolidated
> proposal at http://www.lifewiki.net/openid/
> ConsolidatedDelegationProp
No, I am just pointing out that the openid.delegate is not needed by
the RP.
I think documenting the flow this way is simpler, and fulfills the
requirements that I have been seeing on the list.
-- Dick
On 10-Oct-06, at 12:47 AM, Drummond Reed wrote:
> Dick,
>
> While I think I followed most
Dick,
While I think I followed most of what you say here, I'm not sure what the
exact proposal is. Are you proposing to remove the openid:delegate element
in 2.0? And replace it with an indirect identifier request protocol (your
step 3 below)?
=Drummond
-Original Message-
From: [EMAIL P
David,
Based on feedback, I've backed openid.display out of the consolidated
proposal at http://www.lifewiki.net/openid/ConsolidatedDelegationProposal.
This simplifies it to just two parameters, openid.identity and
openid.rpuserid, which I believe now meet both Josh's and Martin's use
cases.
=D
45 matches
Mail list logo
