+1 to JSON. Rationale: 1. Allows for structured data with relatively low overhead (unlike flat name-value pairs). 2. Marshalls/unmarshalls nearly unambiguously to/from native data structures (dictionaries, arrays, integers, strings, etc.) in multiple programming languages (unlike XML). 3. In-browser capabilities (e.g. JavaScript) for manipulating JSON-structured data.
That said, there would probably need to be some restrictions on JSON encoding in order to support normalization. See http://wiki.apache.org/couchdb/SignedDocuments for issues they've had to deal with on this front. Paul On Wed, 2010-01-27 at 19:42 -0700, 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
