>> 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
>> i-name, because the i-number is forever while
>Marius wrote:
>
>I was suggesting that portability can be resolved between the user and
>the IdP. I cannot see how the protocol can help this by passing two
>identifiers. And if only the portable identifier is passed then there is
>no need to mention the IdP-specific identifier.
Marius, see the a
+1 sacred.
On Thu, 12 Oct 2006, Drummond Reed wrote:
> +1 to Josh's point. IMHO identifier portability is "sacred". If anyone
> disagrees, please post, can we assume we have consensus on this?
>
> =Drummond
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Beh
On Thu, 2006-12-10 at 22:47 -0700, Drummond Reed wrote:
> +1 to Josh's point. IMHO identifier portability is "sacred". If anyone
> disagrees, please post, can we assume we have consensus on this?
Yes, portability is sacred.
I was suggesting that portability can be resolved between the user and
th
Title: RE: Delegation discussion summary
+1 to getting it done. This area of
terminology is more a usability/marketing issue at this point. I agree we need to
converge on good, simple user-facing terms for describing OpenID in ways ordinary
Web users can easily understand. Although I have g
+1 to Josh's point. IMHO identifier portability is "sacred". If anyone
disagrees, please post, can we assume we have consensus on this?
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Josh Hoyt
Sent: Thursday, October 12, 2006 8:56 PM
To: Mariu
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 us
Title: RE: Delegation discussion summary
I'd have to agree with Gabe about this, let's get it done! :)
-Original Message-
From: Gabe Wachob [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 12, 2006 05:43 PM Pacific Standard Time
To: Graves, Michael; specs@openid.net
Subje
On 10/12/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
> The protocol does not need to touch on IdP-specific identifiers (aka
> delegated identifiers) at all IMO.
If there is a specified mechanism that must be supported for using a
portable identifier, all IdPs will support it, so identifiers wi
On 12-Oct-06, at 5:07 PM, Josh Hoyt wrote:
> On 10/12/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
>> If passing through all unrecognized parameters can cause problems
>> then there could be a special namespace for this purpose. For
>> example, all parameters with names starting with openid.pas
On 12-Oct-06, at 10:29 AM, Josh Hoyt wrote:
> Both portable and IdP-specific identifiers
> --
>
> Include both the portable identifier and the IdP-specific identifier
> in the request and response ([4]_ and
> [5]_)::
>
> openid.identity = http://my.idp.spe
*If* we are going to open up the terminology discussion, for me the terms
"authenticating party" (formerly the "IDP") and "accepting party" (formerly
the "relying party") seem more descriptive. The authenticating party issues
authentication assertions in the form of special HTTP request/responses
On 10/12/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> I am ok with this as long as the return_to parameter continues to be
> signed, otherwise it is open to reuse attacks.
Yes, I agree with this analysis (for stateless RPs). It is important
that the return_to URL remain signed.
> I think that Hans
Josh, et al,
I believe the first of your options -- "Both portable and IdP-specific
identifiers" -- is the superior choice here. It preserves OpenID 1
semantics, and unambiguously makes room for portable identifiers. I
don't see the added burden carried by relying party code for this option
viz.
I am ok with this as long as the return_to parameter continues to be
signed, otherwise it is open to reuse attacks. (An RP can take a
response it got, change the return_to parameter and use it at another
site. The return_to allows the RP to know that the response was
intended for it)
I thi
On 10/12/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
> If passing through all unrecognized parameters can cause problems
> then there could be a special namespace for this purpose. For
> example, all parameters with names starting with openid.pass. should
> be ignored by the IdP and passed back
On 12-Oct-06, at 12:10 PM, Recordon, David wrote:
> We thus believe that any state tracking needed by a stateless RP
> must be maintained as GET parameters within the return_to
> argument. In the case of a stateful RP, it can either do the same
> thing, or store state via other means such as
This draft has good discussion about what a good protocol is and the
issues in extending protocols:
http://www.ietf.org/internet-drafts/draft-carpenter-extension-
recs-00.txt
-- Dick
___
specs mailing list
specs@openid.net
http://openid.net/mailman/l
Recordon, David wrote:
>
> We thus believe that any state tracking needed by a stateless RP must be
> maintained as GET parameters within the return_to argument. In the case
> of a stateful RP, it can either do the same thing, or store state via
> other means such as using a session id within
Title: RE: [PROPOSAL] request nonce and name
Josh and I chatted a good deal about this and don't believe a request nonce is actually needed. The main motivation for a request nonce is allowing a RP to retain state within the transaction.
A stateful RP however already has the means to store
+1. Josh, you did a great job of not just distilling it down to the essence,
but also nailing the right semantics for the underlying feature, which is
identifier portability.
Nice work.
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Josh Hoyt
Hello, list,
I'm sure that another message in your inbox with "delegation" in the
title makes most of you cringe, so I'm sorry for that.I hope that this
one gets us closer to resolving this issue.
I have attempted to summarize the proposed delegation mechanisms, as
well as the currently-specified
22 matches
Mail list logo
