Re: [Cbor] Decoding numbers and compliance verification in dCBOR

[Anders Rundgren <[e-mail]>]

On 2023-03-12 13:06, Wolf McNally wrote:
> Anders,
> 
>> I recently flushed 10 years(!) of intense JSON programming [*] into the toilet in favor of deterministic CBOR.
> 
> I know what Blockchain Commons’ goal is for dCBOR: it’s the foundation for Gordian Envelope:
> 
> c7d0bc56-810c-4b42-8f2c-68cf669a8a6e.jpeg
> Gordian/Envelope at master · BlockchainCommons/Gordian <https://github.com/BlockchainCommons/Gordian/tree/master/Envelope>
> github.com <https://github.com/BlockchainCommons/Gordian/tree/master/Envelope>

That's fine, many standardization efforts *begin* their life driven by more or less specific applications.


> <https://github.com/BlockchainCommons/Gordian/tree/master/Envelope>
> 
> As a plus, we think others in the security space will find it useful even without Envelope. But you say you’re all-in on deterministic CBOR (of some flavor.) May I ask, what were you hoping to accomplish with that? What is attractive to you about deterministic CBOR specifically? Why not just use standard CBOR?

What exactly is "standard CBOR"?  AFAIK, dCBOR is compliant with the RFC (=standard) but it is not supported by for example https://cbor.me.  Apparently there is gap here.

My goal (FWIW) would be to create a CBOR counterpart to I-JSON targeting *new* systems like the Gordian envelope.  That some decoders may not be able to fully *validate* I-CBOR does not invalidate such a standard because presumably they are able to *decode* it at least.


> I think if the demand for a unified dCBOR spec is strong enough, and we can articulate our use cases well, then it would definitely help a standard emerge.

IMO, creating a useful CBOR profile could fulfill this goal and much more.  Maybe I-CBOR won't take 100% of the market but 80% is definitely in range.  It could even make it to browsers!

Anders

> 
> ~ Wolf