Support for @path components

[ddworken]

I'm wondering: How hard would it be to support @path components to provide a basic form of resource binding? Similar concerns were previously discussed in #5 and #11, though I think with the switch to a RFC9421-style format, this becomes a bit simpler. It seems to me like a minimal implementation would just support including a path in the signature base and having the browser validate that this matches the resource path.

I'd expect this to be an opt-in feature (since this doesn't make sense for all deployment scenarios) but it does seem potentially quiet useful to allow resource binding without having to have per-resource keys.

[mikewest]

Sure. There's a note in the spec to this effect, but the initial restriction to identity-digest is basically there to make the initial phases of prototyping simple. I think it's quite reasonable to end up with more flexibility for developers to choose the headers and derived components they want to sign. There's a little implementation complexity, since derived components require examining the request as well as the response headers, which requires a little more ductwork to get data into the right place, but that work seems worth doing.

I am marginally worried about the developer-facing complexity of headers, since the serialization is critical to verifying the signature. For Identity-Digest, we know it's a structured field, and we force strict serialization, which means things like whitespace can be normalized consistently on both the signing and verification sides. It seems likely to me that that will be more difficult to guarantee as we broaden the set of response/request headers that could be signed, as headers might be produced by different parts of a pipeline, with different aesthetics for spacing and etc. 🤷 We'll have to work out the balance between predicable consistency and flexibility.

[mikewest]

Added derived components (with a req parameter) to the spec. Adding them to the prototype will follow at some point. :)