Support expected authority changes

[richanna]

In some cases, the authority of the effective request URI may be expected to change, for example from "public-service-name.example.com" to "service-host-1.public-service-name.example.com". This is commonly the case for services that are hosted behind a load-balancing gateway, where the client sends requests to a publicly known domain name for the service, and these requests are transformed by the gateway into requests to specific hosts in the service fleet.

One possible way to handle this would be to special-case the Host header field to allow verifier to substitute a known expected value, or a value provided in another header field (e.g., Via) when generating the Signature Input, provided that the verifier also recognizes the real value in the Host header. Alternatively, this logic could apply to an (audience) content identifier.

[ioggstream]

I'd add the following tasks:

• add an example of request-response
• add paragraph in Security Considerations

An (audience) can be reasonable as that decouples the verifier identity from the target.

[jricher]

The authority is now a separate field from the host header, which should help this case. The draft does not yet contain language that special cases as described here.

[jricher]

It seems that for cases like this, the use of the @authority derived component is the right approach, and either have the reverse-proxy do the verification and add its own signature, the latter of which is checked downstream, or the context is passed downstream allowing the derivation of the @authority value using some application-specific ruleset.

Suggest we close this without changes.

[richanna]

I agree that @authority is the right tool to address this, however the current language for it and @target-uri seem to not leave a lot of leeway for the verifier to substitute values as appropriate. I will put some draft text together.