On Wed, May 01, 2019 at 11:32:40PM -0700, Paul Querna wrote: > Hi all, > HTTP Request Signing > > o "http_method": The HTTP method for the request to which the JWT is > > attached, in upper case ASCII characters, as defined in [RFC7231] > > (REQUIRED). > > > > o "http_uri": The HTTP URI used for the request, without query and > > fragment parts (REQUIRED). > > HTTP Request signing may be a quagmire that this spec wishes to avoid, > but it seems very hard to avoid "fixing" it for at-scale adoption. > With the Okta-hat on, I think this is one area we would like to see > some iteration on. I think it would be ideal to not require multiple > client sign() and server validate() PKI operations per request, so > this is where combining DPoP-Proof and a Request Signature start > making sense to me. > > Keeping it simple, there are two approaches for DPoP for adding > attesting about the HTTP Request: > > a) Adding parts of the HTTP Request as claims > b) Adding a hash of an HTTP Request as a claim > > For option (b), it seems like part of this could live in a separate spec: > 1) request canonicalization > 2) request hashing > > <https://tools.ietf.org/html/draft-cavage-http-signatures-11> does > cover request canonicalization, but the hashing is part of the > specific signature scheme. From an implementors POV, layering > draft-cavage-http-signatures-11 in addition to DPoP is annoying since > it would take two sign or verify key operations per request.
I haven't had a chance to read the linked draft, but we've also seen some activity recently around https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-05 and linked/related drafts, which are also working in a similar space. -Ben _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
