> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Paul C. Bryan > Sent: Thursday, January 28, 2010 3:12 PM
> 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. These two statements are contradictory because whatever issues there are, it is unlikely that the in-browser support will be able to work around it, leading to more errors and confusion than being helpful. EHL > > 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: [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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
