Support a versioning scheme

[ioggstream]

I expect

HTTP Signatures supports a versioning scheme, so I can evolve the spec and be backward compatible during upgrades.

About protocol evolution, see https://tools.ietf.org/id/draft-thomson-postel-was-wrong-03.html

Instead

There's no version field

Proposal

1- Add a mandatory v field to Signature, eg:

Signature: v="1.2.3", ...

2- The Signature is always added as a meta-header as the first element of the signed string

(v): 1.2.3
(request-target): get /foo
...

3- The (v) meta-header is not mentioned in the headers component of the Signature header

4- The value of v must be validated before processing the Signature

5- (obviously) if v and (v) don't match, the hash of the signature won't match, thus making proper versioning mandatory.

@msporny

[liamdennehy]

I vote no.

This project aims to publish a specification as an IETF RFC, and ideally should present a single, coherent protocol. That we have had some iterations and even breaking changes over the course of its development is unfortunate, but I think the aim here is to get to that single protocol.

Capturing and forcing compatibility with every legacy step - some of which we acknowledge have negative security implications such as algorithm - would simply make this a beast to implement in its entirety, and so hinder adoption.

Yes there has already been quite an investment by some parties to implement various versions of the draft, but the risk was always there as this is a draft.

I'm not proposing breaking things intentionally or pulling the plug without consideration, but we need to think about what goal we are trying to achieve and whether these choices support that goal.

[liamdennehy]

While (v) would clearly show which version a signature was generated under - and should be verified against - this would start by creating a compatibility break point, and add complexity to the scheme's final version not least of which is coming up with version semantics.
#88

[ioggstream]

this would start by creating a compatibility break

That's fine as long as the backward-compatibility won't hinder the adoption of this I-D: it would be reasonable to ask for a quick review from the http-wg.

Note that this consideration is non necessarily related to (v) as the version could be passed in many ways.