Project stance on signatures incorporating external data

[liamdennehy]

In the project's proposed principle "What You See is What You Sign":

signatures should be verifiable given the information available at that time. Signatures should not rely on information not present in a given message except for the secrets used

In order to reconstruct the Signing String, a verifier needs access to all the data that process depends on. Some of this information may be contextual:

• The :method and :path components of (request-target) are not transmitted in a response, but depend on the context contained in the associated request https://github.com/w3c-dvcg/http-signatures/issues/82
• :authority may or may not be reliably known in a context depending on whether the message has been transformed between HTTP/1.1 and http2 by intermediaries https://github.com/w3c-dvcg/http-signatures/commit/1589b3fb68d030ca72a4dbbf134335ac324586ca

Should this specification permit a Signing String to be constructed using contextual sources and not exclusively on information present in the message itself?

[liamdennehy]

As stated in README.md all verification information must be provided in-band, and not rely on context or external sources. Closing as accepted after two months.

[ioggstream]

@liamdennehy question: certificate chains/transparency logs/ocsp are considered out-of-band informations?

[liamdennehy]

Indeed, the spec simply refers to keys, as does the principle above. It's also agnostic to certificates themselves, as this is just metadata about a key.

How a particular key is trusted to sign a message (e.g. certificate chains from a CA/B Forum root, membership in an private trust scheme), and why (e.g. specified in law), is entirely up to the implementation.