They’re similar in that they both take elements from the HTTP message and create a signature on them, and they use the same “list the order of the elements” trick to avoid normalization to a large extent. The main difference is that my draft uses JWS as the signature (and ultimately transport) mechanism and the Cavage draft (and the AWS method it is born from, as I understand it) uses a new HTTP auth header format, much like OAuth 1.0 and the (old, dusty, abandoned, can-we-stop-bringing-it-up) MAC draft. My original (unpublished) version of the draft didn’t actually specify or care how you got the key, as I think that HTTP signing is a general mechanism.
That said, there seems to be a lot of interest in solving this case that OAuth 1.0 managed to get somewhat right-ish. — Justin On May 12, 2014, at 1:59 PM, Hannes Tschofenig <[email protected]> wrote: > Conceptually, draft-cavage-http-signatures-02 is the same as OAuth 1.0. > Therefore, the symmetric key part of the document is the same as the MAC > token. > > Not quite sure why the authors have not read the OAuth work. > > On 05/09/2014 01:22 AM, Phil Hunt wrote: >> How does this compare with justin's draft? >> >> Phil >> >> Begin forwarded message: >> >>> *From:* Manu Sporny <[email protected] >>> <mailto:[email protected]>> >>> *Date:* May 8, 2014 at 14:41:55 PDT >>> *To:* IETF HTTP Auth <[email protected] <mailto:[email protected]>> >>> *Cc:* Julian Reschke <[email protected] >>> <mailto:[email protected]>>, Mark Nottingham <[email protected] >>> <mailto:[email protected]>>, Web Payments CG <[email protected] >>> <mailto:[email protected]>> >>> *Subject:* *[http-auth] Review Request for third draft of "Signing >>> HTTP Messages"* >>> >>> After feedback from Mark Nottingham[1], Julian Reschke[2], folks in the >>> HTTP Auth WG, and people in the Web Payments CG, we've modified the HTTP >>> Signatures specification in the following ways: >>> >>> 1. The specification has been renamed to "Signing HTTP Messages". >>> 2. The specification now covers both a signature-based Authorization >>> mechanism (client-to-server) as well as a general mechanism to sign >>> HTTP messages (client-to-server and server-to-client). >>> 3. A new "Signature" header has been introduced. >>> 4. The layout has been modified heavily to streamline the information >>> conveyed in the spec. >>> 5. New registries have been created for the algorithms referred to in >>> the specification. >>> 6. We're now more specific in the way certain canonicalizations are >>> performed. >>> 7. More examples have been added, including how to digitally sign >>> the body of an HTTP message. >>> >>> The basic mechanism of generating the signatures has not changed (and >>> has been stable for over a year). >>> >>> The newest spec can be found here: >>> >>> http://tools.ietf.org/html/draft-cavage-http-signatures-02 >>> >>> The diff is here: >>> >>> http://tools.ietf.org/rfcdiff?url2=draft-cavage-http-signatures-02.txt >>> >>> Matt, Yoav, Kathleen, if there are no show stopping review comments, I'd >>> like to push this spec onto the RFC track in the HTTP Auth WG, or >>> HTTPbis/2 WG. It'll be ready for a LC in a month or two. I realize that >>> HTTP Auth may be shutting down next month, so what's the next step to >>> get the HTTP Signatures spec further down the IETF RFC track? >>> >>> -- manu >>> >>> [1] >>> http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0038.html >>> [2] >>> http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0036.html >>> >>> -- >>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) >>> Founder/CEO - Digital Bazaar, Inc. >>> blog: The Marathonic Dawn of Web Payments >>> http://manu.sporny.org/2014/dawn-of-web-payments/ >>> >>> _______________________________________________ >>> http-auth mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/http-auth >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
