W3C home > Mailing lists > Public > public-credentials@w3.org > July 2020

Re: Introducing CBOR-LD...

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Fri, 24 Jul 2020 11:19:11 -0400
To: Leonard Rosenthol <lrosenth@adobe.com>, "public-credentials@w3.org" <public-credentials@w3.org>
Message-ID: <1a64dd66-3c90-1744-552c-f99121246beb@digitalbazaar.com>
On 7/24/20 11:00 AM, Leonard Rosenthol wrote:
> However, the main use case that you present in the presentation is
> QRCodes - which exist as a mechanism to move from digital to analog
> (and back).   The analog world is long lived - even if not
> necessarily archival - and the data needs to be retrievable.  And
> that can't happen w/o knowing the right (version of the) dictionary
> to use.

... which is why we strongly suggest that all production contexts should
be versioned, frozen, and cryptographically hashed. There is a general
mitigation for your concern. :)

To be clear, this issue is well known in the JSON-LD ecosystem and that
ecosystem has thrived (deployed on tens of millions of domains) in spite
of the danger. That community has learned how to manage constantly
evolving vocabularies (schema.org), and how to lock vocabularies down (VCs).

There are solutions to the problem you outline, cryptographically
hashing URLs is one thing we explored, but that bloats the size of the
CBOR-LD bytes. Like any technology, CBOR-LD is a series of difficult
design trade-offs.

Just like we made the conscious decision in JSON-LD to be able to
reference external JSON-LD Context files (which people insisted was
madness and unworkable when we did it... and still do), we make the same
conscious decision now (because it worked out pretty well for JSON-LD,
and it's not clear how doing the same thing in CBOR-LD would be any

If we wanted to eliminate the risk you highlighted, we wouldn't be able
to solve the most pressing use cases.

-- manu

Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
Received on Friday, 24 July 2020 15:19:25 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:01 UTC