RE: Request for comments: Sorting fields in signature generation-Call for votes
Behavior needs to be specified before it can be recommended. So the spec MUST specify how to deal with the multiple parameters before it can set the use thereof as NOT RECOMMENDED. Hans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Wednesday, September 27, 2006 1:13 PM To: Josh Hoyt; Marius Scurtescu; Brad Fitzpatrick Cc: specs@openid.net Subject: RE: Request for comments: Sorting fields in signature generation-Call for votes I don't think multiple parameters with the same name should be completely disallowed, rather that section 7.1 should strongly discourage their use. I agree that from the core authentication standpoint they aren't needed today, though do understand that in the future there may be a compelling use case for them. I believe the simplicity that is offered from not supporting them out weighs the benefit of form handling with existing forms. So +1 to tightening up section 7.1, but -1 to it specifically allowing multiple parameters with the same name. I believe the wording should be such that it is strongly NOT RECOMMENDED that extensions to OpenID Authentication utilize GET or POST parameters with the same name. Brad, thoughts? --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Wednesday, September 27, 2006 12:20 PM To: Marius Scurtescu Cc: specs@openid.net Subject: Re: Request for comments: Sorting fields in signature generation -Call for votes On 9/27/06, Marius Scurtescu [EMAIL PROTECTED] wrote: please keep in mind that we are not asking for some fancy new technology or feature, just conformance with a very basic an wide spread convention of handling parameters in HTTP/HTML. As Kevin pointed out, we are not working on the HTTP/HTML form processing specification. We are working on an authentication protocol. Restricting the protocol to forbid multiple parameters with the same name does not break conformance with anything. I think that we have discussed the majority of the technical issues regarding multiple parameters with the same name. I could respond to your individual points, but I don't think that would get us any closer to agreement. Can we get +1/-1 on multiple parameters with the same name from people without @sxip.com or @janrain.com e-mail addresses? Clearly, we (JanRain) are -1. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Request for comments: Sorting fields in signature generation
I think the real topic of this discussion is whether or not multiple parameters with the same name should be allowed by the specification. I'd support the motion of not doing that. Johannes, just to clarify, are you against allowing multiple same-name params? Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Request for comments: Sorting fields in signature generation - Call for votes
On 9/27/06, Marius Scurtescu [EMAIL PROTECTED] wrote: please keep in mind that we are not asking for some fancy new technology or feature, just conformance with a very basic an wide spread convention of handling parameters in HTTP/HTML. As Kevin pointed out, we are not working on the HTTP/HTML form processing specification. We are working on an authentication protocol. Restricting the protocol to forbid multiple parameters with the same name does not break conformance with anything. I think that we have discussed the majority of the technical issues regarding multiple parameters with the same name. I could respond to your individual points, but I don't think that would get us any closer to agreement. Can we get +1/-1 on multiple parameters with the same name from people without @sxip.com or @janrain.com e-mail addresses? Clearly, we (JanRain) are -1. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Request for comments: Sorting fields in signature generation
On 9/27/06, Johnny Bufu [EMAIL PROTECTED] wrote: Huh? I don't see anything in that section about a requirement to echo back parameters. Not a requirement, but I read the second paragraph as implying they can/could be used. An IdP is not forbidden from echoing back any unknown parameters it got, but no OpenID implementation has ever done this, to my knowledge. I expect that unless the specification said otherwise, applications would ignore unexpected parameters. As far as I can tell, this is standard behavior on the Web. If that weren't so, then why is there the openid. prefix to the parameters in some of the messages? The reason that the parameters have openid. at the beginning is so that it is clear that they are part of the OpenID protocol message and not intended to be operated on by the application that is processing the OpenID request. Basically, to reduce the likelihood of name collisions with parameters that the application uses. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Request for comments: Sorting fields in signature generation
On 9/26/06, Barry Ferg [EMAIL PROTECTED] wrote: The signature generation algorithm specifies that the fields to be signed be ordered in byte order form. It seems to be implied that the ordering is based on using the field names as sorting keys I think the real topic of this discussion is whether or not multiple parameters with the same name should be allowed by the specification. I *strongly* prefer tightening the specification by *disallowing* duplicate parameter names. PHP is one environment in which the implementation will be problematic, but other common environments (e.g. Rails) do not easily support this idiom. There is *no deployed code* that depends on duplicated parameter names, and I'd like to keep it that way. Keep it simple if possible. I agree that the language in the specification should be clarified so that the sort order is fully explicit. I would resolve this issue by stating that the pairs must be sorted by key. On another note: Pass-through (or echo) parameters and potentially some OpenID extension parameters may include fields with multiple values in order to communicate arrays of data, etc. Attribute exchange and other extensions can *easily* be designed not to require multiple parameters with the same name. Pass-through parameters are *not part of any OpenID specification.* Even if they were, I don't think it would be too great of a restriction to disallow duplicate parameter names. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Request for comments: Sorting fields in signature generation
Well, then +1 to disallowing such multiplicity! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Tuesday, September 26, 2006 4:15 PM To: Granqvist, Hans Cc: Barry Ferg; specs@openid.net Subject: Re: Request for comments: Sorting fields in signature generation On 9/26/06, Granqvist, Hans [EMAIL PROTECTED] wrote: Does this problem exist if SIGNALL goes away? If there are multiple parameters with the same name, the problem is there, with or without SIGNALL, unfortunately. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Request for comments: Sorting fields in signature generation
On 9/26/06, Marius Scurtescu [EMAIL PROTECTED] wrote: Pass-through parameters are *not part of any OpenID specification.* They are not, but in order to be able to pass them through you have to be able to deal with them. Also, you may have to sign them as well. No one has written a proposal for pass-through arguments and it's not in any specification, so it's hard to answer your objection. If someone were to propose adding pass-through parameters to the specification, I would argue that: a) Including the pass-through arguments in the OpenID signature is not necessary (or constructive!) b) It is quite reasonable to restrict them to only one value per parameter name. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
