- 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>
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 different). 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 https://tinyurl.com/veres-one-launches
Received on Friday, 24 July 2020 15:19:25 UTC