Re: CBOR versus HTTP Message Signature

The HTTP Message Signatures draft is not specific to JSON or any other data encoding format, so I'm not sure what you're trying to say here. Are you saying that cbor/cose would be a replacement for a general purpose HTTP signing mechanism? But: You don't need any JSON processing to implement the specification. That was one of the smaller goals of the spec, the larger aspect being that it should live natively in HTTP space and not be tied to API or data use cases.

Yes, there are lots of other ways to sign things, and they've got different properties that make sense in different environments. I suppose if you're doing something entirely in cbor already, something else might make sense, but that isn't the goal here.

- Justin
________________________________
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Sent: Monday, December 19, 2022 1:12 AM
To: HTTP Working Group <ietf-http-wg@w3.org>
Subject: CBOR versus HTTP Message Signature


Dear List,
I hope you don't mind me elaborating a bit on an alternative to the current IETF WG item.
A decode ago I converted from XML/XSD to JSON.
Now I have converted to CBOR for many reasons including support for a wider set of data items, and last but not least deterministic serialization.

If you put all these things together you can obtain similar results as with HTTP Signatures, but in a package that may better match the rest of a typical system.

https://github.com/cyberphone/cbor-everywhere#signed-http-requests


There are probably not many who are prepared scrapping their huge investments in JSON based systems.  JSON also remains the [currently] only viable alternative for browser based applications.

Cheers,
Anders