Re: Signature [protocol element] identifiers

After some feedback, I pushed an update to this PR that puts “@request-target” back in place of “@request-origin” because that was a bad name. The “@request-target” now has a value that aligns better with HTTP Semantics than the old constructed string value that included the method. I also added in a “@target-uri” identifier that would let the signer throw the entire URI in as a single value, which might be easier for some applications of this spec. As always, the goal is to have robustness through multiple parts that fit different circumstances. 

And finally, we’ve added in a blurb, roughly based on the other thread, that allows most of the request-focused identifiers to also be used in a response by referring to the value that was in the request that triggered the response. I couldn’t find an accepted term for this construct, is there one? So let’s say:

REQUEST (A) is received by an HTTP server that generates RESPONSE(B) and sends it back. What do we call the relationship between A and B? If I’m signing B with some of A’s content, which we’re looking at  allowing now, how do we describe that link? If the server then gets REQUEST(C), we don’t want the response to include anything from A, but instead only reference C specifically.

Even if we do continue to allow this type of connection between individual components like this, I still want to allow an explicit signing of a request signature (so we sign A’s signature as part of creating the signature for B).

 — Justin

> On Jun 29, 2021, at 3:41 PM, Justin Richer <jricher@mit.edu> wrote:
> 
> I just pushed a strawman proposal for new identifiers for elements covered by the signature, and the editors would like feedback on this. I tried to base the language on the draft semantics and messaging drafts, but I’m sure I mixed a few things up — please help us make sure these things are right!
> 
> https://github.com/httpwg/http-extensions/pull/1565 <https://github.com/httpwg/http-extensions/pull/1565>
> 
> This also removes the “@request-target” identifier, which was problematic for a number of reasons. In its stead you can now use “@method” and “@request-origin” (or some combination of “@path” and “@query”) to cover the same elements of a request.
> 
> As a side note, we know that terms like “covered content” are problematic and will be fixing that language in a different PR in the future. So that wires don’t get crossed with that related conversation, please limit feedback to the definitions of these items, both in terms of the identifier used and the value generation and canonicalization method.
> 
> Thank you!
>  — Justin