Possibly, although I haven't yet come to the conclusion that these are incompatible.
Moves to build proper JSON JavaScript libraries rather than rely on the built-in parser are already tackling some other JSON-related issues, and could possibly serve to address this issue as well. Paul On Thu, 2010-01-28 at 16:20 -0700, Eran Hammer-Lahav wrote: > > > -----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
