+1 to JSON. Custom parser is difficult and JSON adds very little overhead to the data.
On 1/28/10 7:15 AM, "Justin Hart" <[email protected]> wrote: I'm inclined to say #1 to JSON because its rules are well defined (especially escaping and delimiters) and the parsers are widely available and relatively standard. It really has little more complication than other key-value forms. I say #2 to form-encoded because though there have been issues, again, the form is defined. Picking an already defined format should avoid most parser trouble. On Wed, Jan 27, 2010 at 7:42 PM, Eran Hammer-Lahav <[email protected]> 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
