On Sun, Aug 7, 2016 at 8:29 PM, Martin Thomson <[email protected]> wrote:
> On 8 August 2016 at 12:39, Richard Barnes <[email protected]> wrote: > > So I'm honestly not that convinced that we need versioning at all here. > > Maybe we could get away with just versioning the directory? (As I think > the > > original issue proposed :) ) > > > I believe that it was PHB who requested this originally, the rationale > being that you might create a new version of the same resource/request > that looked similar, but had different semantics. Rather than rely on > having us (in all our possible future incarnations) not doing that, a > version indicator would make signatures invalid. > > If that is a requirement that you accept, then a much simpler scheme > than the one you wrote up is possible. Versioning the directory isn't > sufficient to achieve that goal though. The first part of your PR > would work though: include a version, and require that it be checked. > Looking at the minutes from Berlin... "RLB: do we need both server and client versions? MT: sure" :) I'm not sure we can get away without any server versioning. The server needs some way to signal support, even if it's only in an error message. Again, I'm not totally convinced that semantic mismatches are that big a deal. The "url" parameter already scopes the signed object to a specific resource, so the only risk would be if that specific resource accepts different object formats that are confusable with one another. You need some signal to disambiguate, but it's not clear to me that having one big version is the best solution. --Richard
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
