RE: Delegation discussion summary

2006-10-12 Thread Drummond Reed
+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

RE: [PROPOSAL] request nonce and name

2006-10-12 Thread Recordon, David
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

Re: [PROPOSAL] request nonce and name

2006-10-12 Thread Martin Atkins
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 a

off topic: IETF ID on extending protocols

2006-10-12 Thread Dick Hardt
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

Re: [PROPOSAL] request nonce and name

2006-10-12 Thread Marius Scurtescu
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

Re: [PROPOSAL] request nonce and name

2006-10-12 Thread Josh Hoyt
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 to

RE: Delegation discussion summary

2006-10-12 Thread Graves, Michael
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.

RE: Delegation discussion summary

2006-10-12 Thread Gabe Wachob
*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 with

Re: Delegation discussion summary

2006-10-12 Thread Marius Scurtescu
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 =

Re: [PROPOSAL] request nonce and name

2006-10-12 Thread Marius Scurtescu
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.pass.

Re: Delegation discussion summary

2006-10-12 Thread Josh Hoyt
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 will

RE: Delegation discussion summary

2006-10-12 Thread Recordon, David
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 Subject: RE:

Re: Consolidated Delegate Proposal

2006-10-12 Thread Dick Hardt
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

RE: Delegation discussion summary

2006-10-12 Thread Drummond Reed
+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: Marius

RE: Delegation discussion summary

2006-10-12 Thread Drummond Reed
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