Re: Introducing CBOR-LD...

On 7/24/20 11:00 AM, Leonard Rosenthol wrote:
> I agree that there are indeed use cases where it would be useful.  though in that case, I'd rename it to be specific about the use cases and technology.  (eg.  CBOR-SC, to use your terminology).
> 
> 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.

We should strongly recommend that any context registered in a CBOR-LD
global registry be a static document and include a content hash along
with it. A registered context should not change. This is similar to the
fact that the VC context is a versioned and static context -- and VC
issuers that create their own contexts should follow the same advice.

> 
> Leonard
> 
> On 7/24/20, 10:43 AM, "Manu Sporny" <msporny@digitalbazaar.com> wrote:
> 
>     On 7/24/20 9:57 AM, Leonard Rosenthol wrote:
>     > In our world where (standard) schemas are being created & edited
>     > daily, let alone the existence of custom ones - I just don't see how
>     > this will work for the types of data being considered here (eg.
>     > VC's)
>     > 
>     > Accordingly, I don’t see this as a viable option.
> 
>     You are correct, if the schema changes out from under you, you're in
>     trouble. There is one mitigation for this that you may not be aware of:
> 
>     Every W3C global standard JSON-LD Context that I know of is frozen in
>     time. We go as far as publishing cryptographic hashes for the JSON-LD
>     Contexts in the specifications themselves.
> 
>     Example for Verifiable Credentials here:
> 
>     https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fvc-data-model%2F%23base-context&amp;data=02%7C01%7Clrosenth%40adobe.com%7C87e433fae0e04f49944a08d82fdfdcc4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637311985813780797&amp;sdata=B%2BBpxqMIZdULrUx3bf7d0JGAONm5yEv%2FucEescfTd2U%3D&amp;reserved=0
> 
>     We should point this out in the CBOR-LD specification as I'm sure some
>     poor soul will step on that particular landmine.
> 
>     The other protection that we have in place is that things like
>     Verifiable Credentials are digitally signed, so if you deserialize and
>     check the signature on the receiving end, a context change will be
>     detected (digital signature verification failure).
> 
>     That doesn't mean that this stuff isn't useful even while developing...
>     if you only go to CBOR-LD for vanishingly small periods of time
>     (transmission via QRCode and then immediately back to JSON-LD), it is
>     highly unlikely that you're going to be the unlucky person that received
>     a message right as someone pressed "Save" a context.
> 
>     So, if you plan to use CBOR-LD as an archival format using unstable
>     JSON-LD Context files, then yes, you shouldn't do that and yes, we
>     should warn about it in the specification. However, that doesn't mean
>     that the solution isn't viable for a subset of use cases. :)
> 
>     -- manu
> 
>     -- 
>     Manu Sporny - https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&amp;data=02%7C01%7Clrosenth%40adobe.com%7C87e433fae0e04f49944a08d82fdfdcc4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637311985813780797&amp;sdata=phePhC1%2BdJ356sk2P%2F89M7nNlQVWh2j%2FqJCeRSfpAZ4%3D&amp;reserved=0
>     Founder/CEO - Digital Bazaar, Inc.
>     blog: Veres One Decentralized Identifier Blockchain Launches
>     https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.com%2Fveres-one-launches&amp;data=02%7C01%7Clrosenth%40adobe.com%7C87e433fae0e04f49944a08d82fdfdcc4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637311985813780797&amp;sdata=hSh3WlxVbMCUvUkglL1bVP22kwqnvGSUjunXi4tMOSo%3D&amp;reserved=0
> 
> 


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Friday, 24 July 2020 15:26:51 UTC