On Wed, 2010-01-13 at 22:40 -0700, Eran Hammer-Lahav wrote: > 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).
I lean toward having an extensible, normalized structure that can be signed. As pointed-out by Blane, I think Eaton style (C) gives the most amount of flexibility in this regard. > > 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 Paul _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
