That's exactly it. This is why JSON is not my top priority because people will see 'use JSON' and ignore the profile (no whitespace) and will fail.
Those of you who picked JSON, does this change your mind? If we use JSON, I expect many existing libraries that produce JSON objects to fail because of the differences in how they add whitespace. EHL > -----Original Message----- > From: Richard L. Barnes [mailto:[email protected]] > Sent: Thursday, January 28, 2010 11:32 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Request Signing vs. API Signing vs. Message > Signing > > Ah, ok, I misunderstood the context of your reference to XMPP. So the > question at hand here is: How do you construct the thing you're going to > sign? > > Assuming that's the question, then the critical thing is that the format be > canonical (or at least canonicalizable). That always seems easier for simpler > formats, so my inclination would be toward either form-encoding or a > custom format (3 or 4), since these define precise rules for how things fit > together. After that, a tight profile of JSON might be workable (e.g., no > white space); XML is probably too much of a hassle. > > --Richard > > > > On Jan 28, 2010, at 1:06 PM, Eran Hammer-Lahav wrote: > > > This defeats the point of having a unified message format across > > different transports. And since the message itself is not sent on the > > wire, the benefit to XMPP isn't that significant. > > > > Also, we are only talking about construction, not parsing. So > > technically, no lib is really needed in either case (but can be useful > > for data type encoding). > > > > EHL > > > > On Jan 28, 2010, at 7:30, "Richard L. Barnes" <[email protected]> wrote: > > > >> It's not clear that XML is always crazy. If you're integrating this > >> into an XMPP client, it's already used to using XML (i.e., it's > >> already got a parser/generator), and might not have JSON machinery. > >> > >> I would suggest pinning down a data model that gets serialized to > >> different formats depending on the protocol. You're going to have to > >> define how OAuth fits into a different protocol anyway, so if there's > >> a set of defined serializations, you can just add a line to that > >> definition that says "use X serialization". > >> > >> --Richard > >> > >> > >> On Jan 27, 2010, at 9:42 PM, Eran Hammer-Lahav wrote: > >> > >>> I don't think we had enough discussion for a consensus call but I > >>> would like to continue with some combination of A and C. That means, > >>> defining a message format to normalize the request into (which can > >>> be used with XMPP and other transports), but to still process the > >>> HTTP request and not the API request into the message. In other > >>> words, not process parameters but still turn the request into a > >>> message. > >>> > >>> I will try this in my next draft. > >>> > >>> My question: what format should we use for this message? The main > >>> four options are: > >>> > >>> 1. XML > >>> 2. JSON > >>> 3. Form-encoded (key=value&key=value) 4. Text (key-value pair new > >>> line separated, or HTTP-header like key="value" comma, etc.) > >>> > >>> My thinking is: XML is crazy here (complication without benefits), > >>> JSON is interesting but doesn't add much value beyond other options > >>> (unless we foresee the need for lists or richer value types), Form- > >>> encoded is ok but has to be specified due to variations in libraries > >>> (well-known OAuth issue), and Text is easy but requires a custom > >>> parser and we need to choose a style. > >>> > >>> I am inclined to use Text (key=value LF) but can be talked into > >>> Form- > >>> encoded or even JSON. > >>> > >>> Anyone else? > >>> > >>> EHL > >>> > >>>> -----Original Message----- > >>>> From: [email protected] [mailto:[email protected]] On > >>>> Behalf Of Eran Hammer-Lahav > >>>> Sent: Wednesday, January 13, 2010 9:41 PM > >>>> To: OAuth WG > >>>> Subject: [OAUTH-WG] Request Signing vs. API Signing vs. Message > >>>> Signing > >>>> > >>>> Authentication Open Question #1: What to sign? > >>>> > >>>> OAuth Core 1.0 was designed to sign API requests made using common > >>>> form-encoded formats. The main component of the 1.0 signature base > >>>> string are the parameters. The host and HTTP methods are important > >>>> but were never the focus on the signed content. > >>>> > >>>> draft-hammer-oauth does not change the process but does describe > >>>> the process very differently, changing the focus form signing API > >>>> requests and parameters to signing HTTP requests (partially). > >>>> draft-hammer-http-token-auth takes this approach a step further and > >>>> focuses on signing the raw HTTP request components, completely > >>>> ignoring their meaning as used by API calls. The end result is very > >>>> similar but the differences are important. > >>>> > >>>> Brian Eaton proposed [1] an alternative approach to sign messages > >>>> instead of API calls or HTTP request. In his proposal, the HTTP > >>>> request (or API call based on your perspective) in transformed into > >>>> a message (in his case using a JSON- based format) which is then > >>>> signed. This additional layer of abstraction allows the use of the > >>>> method with other transports or use cases in which parameters are > >>>> not sent in the request URI or body. > >>>> > >>>> QUESTION: Do you prefer: > >>>> > >>>> A. Directly processing the HTTP request into a base string for > >>>> signing (draft- hammer-oauth style). > >>>> B. Treating the request as an API call with form-encoded parameters > >>>> (OAuth > >>>> 1.0 style). > >>>> C. Converting the request into a normalized message and signing > >>>> that (Eaton style). > >>>> > >>>> EHL > >>>> > >>>> [1] http://www.ietf.org/mail-archive/web/oauth/current/ > >>>> msg00890.html > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> [email protected] > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>> _______________________________________________ > >>> OAuth mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/oauth > >> _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
