Re: CBOR versus HTTP Message Signature

Hi Justin,
I fully support the WG item.

What I did found out though, is that for designs standardizing on CBOR as data interchange format, there are alternatives like the one I provided in the sample.

- In the RATS WG, "objectId" has been defined through the combination of 1) parameterized content-type, 2) CBOR tags 3) profile URI.  However, the XML/XSD world (including the ISO 20022 folks), managed just fine with a single URI which also became a part of the object data itself, effectively decoupling objects from their transport.

- To not leave HTTP headers in the dark, I'm suggesting copying the this part from your excellent draft.

- Finally, by building on CBOR deterministic serialization, bstr/B64 "armoring" of data becomes redundant, enabling enveloped signatures at no additional cost or risk.

Although object serialization is probably a no-issue for most designs, it is a pretty useful feature for systems creating attested (and potentially stateless) tokens. This is the origin of this concept.

Anders

On 2022-12-23 14:37, Justin Richer wrote:
> 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 <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
> 

Received on Friday, 23 December 2022 15:55:02 UTC