Project stance on multiple header instances

[liamdennehy]

https://github.com/w3c-dvcg/http-signatures/issues/85 and https://github.com/w3c-dvcg/http-signatures/issues/50 both depend on answering a single question: Do we interpret RFC7230 Section 3.2.2 as

• being permissive of multiple instances of a single header name, both since an exception is made for a named header (Set-Cookie) and the door is left open for other "well-known" headers (whatever that means)
• prohibiting multiple header instances - perhaps with the exception of the named case, meaning this protocol will refuse to sign multiple-instance headers, or generate a Signature or Authorization header if one is already present in a message?

I don't think different answers for each issue would be appropriate, so I hope to get consensus on this principle as proposed in https://github.com/w3c-dvcg/http-signatures/pull/87 in a dedicated discussion here.

[liamdennehy]

To open with my position, I have proposed the principle:

If HTTP does or permits something, this protocol should allow it to be signed.

This protocol has the most utility if it simply allows security to be added to a message, without carving out exceptions based on our own concerns. Principally the choice to accept multiple header instances should be made by the application itself - regardless of whether they accept signatures. I don't feel this is a constraint we should be making on an application's behalf, especially if this is what they already permit.

[liamdennehy]

Two months seems a good time to close this.