W3C home > Mailing lists > Public > public-credentials@w3.org > December 2022

Re: The "CBOR Everywhere" Project

From: Leonard Rosenthol <lrosenth@adobe.com>
Date: Thu, 15 Dec 2022 14:26:09 +0000
To: Anders Rundgren <anders.rundgren.net@gmail.com>, Christopher Allen <ChristopherA@lifewithalacrity.com>
CC: W3C Credentials Community Group <public-credentials@w3.org>
Message-ID: <DM8PR02MB8181CD34C302102332AF14F4CDE19@DM8PR02MB8181.namprd02.prod.outlook.com>
Anders Ė this COTX proposal is very much in line with that we do in C2PA (http://c2pa.org) with respect to custom extensions to our various CBOR grammars, though we didnít think to fully structure it as you did.  We simply require that each key name be the full URI, since we donít currently have a lot of them.  But Iíll bring yours up as something worth moving to.

Thanks!

And, obviously, we are also fully on the CBOR (and COSE) train for all the reasons that you and Christopher mention.

Leonard

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Thursday, December 15, 2022 at 4:42 AM
To: Christopher Allen <ChristopherA@lifewithalacrity.com>
Cc: W3C Credentials Community Group <public-credentials@w3.org>
Subject: Re: The "CBOR Everywhere" Project
EXTERNAL: Use caution when clicking on links or opening attachments.


On 2022-12-15 10:05, Christopher Allen wrote:
> On Wed, Dec 14, 2022 at 8:20 PM Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     For me it is obvious that developers of new designs should seriously consider CBOR as an alternative to JSON and XML:
>
>     https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcyberphone%2Fcbor-everywhere&amp;data=05%7C01%7Clrosenth%40adobe.com%7Caba8ed5d2b0e49af359708dade80a882%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638066941418904476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=SPJ9QeH6V8eAPBd08YzbWLkdVyGu3A1LK4gtx8C5LOY%3D&amp;reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcyberphone%2Fcbor-everywhere&amp;data=05%7C01%7Clrosenth%40adobe.com%7Caba8ed5d2b0e49af359708dade80a882%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638066941418904476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=SPJ9QeH6V8eAPBd08YzbWLkdVyGu3A1LK4gtx8C5LOY%3D&amp;reserved=0>
>
>
> Here is my own list of answers for "Why CBOR?":

Thanks Christopher,
I have only looked at this topic from a JSON/XML horizon.

The conversion ("upgrade") is simple with one exception; I'm not entirely convinced that adopting the CBOR tag system is sufficient for everybody, which is why I have toyed with a new CBOR construct:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcyberphone%2Fcbor-everywhere%23url-based-object-identifiers&amp;data=05%7C01%7Clrosenth%40adobe.com%7Caba8ed5d2b0e49af359708dade80a882%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638066941418904476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=5%2BBXF6%2FfZxGxemY3jgYIJHHIPUmW5HxoAPaZdEtvC78%3D&amp;reserved=0

Some CBOR folks maintain that URLs are not only big but bad as well.  However, high-level systems like Open Banking are frequently updated as well as defining many object types, both which seem to speak for locally managed namespaces.

Thoughts?

Anders


>
> Why CBOR?
>
> The Concise Binary Object Representation, or CBOR, was chosen as the foundational data structure for Gordian specifications such as Envelope and URs for a variety of reasons. These include:
>
> * IETF Standardization. CBOR is a mature open international IETF standard.
> * IANA Registration. CBOR is further standardized by the registration of common data types through IANA.
> * Fully Extensible. Beyond that, CBOR is entirely extensible with any data types desired, such as our own listing of UR tags.
> * Self-describing Descriptions. Data is self-describing, so there are no requirements for pre-defined schemas nor more complex descriptions such as those found in ASN.1.
> * Streaming Friendly. CBOR works well with streaming without requirements for extra memory; its tagging system allows for data to be skipped if it is irrelevent or unknown.
> * Constraint Friendly. CBOR is built to be frugal with CPU and memory, so it works well in constrained environments such as on cryptographic silicon chips.
> * Unambiguous Encoding. Our use of Deterministic CBOR, combined with our own specification rules, such as the sorting of Envelopes by hash, results in a singular, unambiguous encoding.
> * Multiple Implementations. Implementation are available in a variety of languages.
> Compact Implementations. Compactness of encoding and decoding is one of CBOR's core goals; implementations are built on headers or snippets of code, and do not require any external tools.
>
> See also:
> * a comparison to protobuffers: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBlockchainCommons%2FResearch%2Fblob%2Fmaster%2Fpapers%2Fbcr-2020-005-ur.md%23qa&amp;data=05%7C01%7Clrosenth%40adobe.com%7Caba8ed5d2b0e49af359708dade80a882%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638066941418904476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=xz8dBQ8q6HZsMTzvNX0ml4AMUvA%2FcNBTOEgpf0r2FZk%3D&amp;reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBlockchainCommons%2FResearch%2Fblob%2Fmaster%2Fpapers%2Fbcr-2020-005-ur.md%23qa&amp;data=05%7C01%7Clrosenth%40adobe.com%7Caba8ed5d2b0e49af359708dade80a882%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638066941418904476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=xz8dBQ8q6HZsMTzvNX0ml4AMUvA%2FcNBTOEgpf0r2FZk%3D&amp;reserved=0>
> * a comparison to Flatbuffers
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F47799396%2Fflatbuffers-vs-cbor&amp;data=05%7C01%7Clrosenth%40adobe.com%7Caba8ed5d2b0e49af359708dade80a882%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638066941419060701%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=Toj9QFrBvxwkaLw6aVJah8EBKQfNBq0KT2xZkLA200g%3D&amp;reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F47799396%2Fflatbuffers-vs-cbor&amp;data=05%7C01%7Clrosenth%40adobe.com%7Caba8ed5d2b0e49af359708dade80a882%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638066941419060701%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=Toj9QFrBvxwkaLw6aVJah8EBKQfNBq0KT2xZkLA200g%3D&amp;reserved=0>)
> * a comparison to other binary formats
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8949%23name-comparison-of-other-binary-&amp;data=05%7C01%7Clrosenth%40adobe.com%7Caba8ed5d2b0e49af359708dade80a882%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638066941419060701%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=aLGLRdSlw8iITgxQlkkL8PyRv60wZMgnTc5doejoKvA%3D&amp;reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8949%23name-comparison-of-other-binary-&amp;data=05%7C01%7Clrosenth%40adobe.com%7Caba8ed5d2b0e49af359708dade80a882%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638066941419060701%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=aLGLRdSlw8iITgxQlkkL8PyRv60wZMgnTc5doejoKvA%3D&amp;reserved=0>
>
> -- Christopher Allen
>
Received on Thursday, 15 December 2022 14:26:24 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 15 December 2022 14:26:25 UTC