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
