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

Re: Introducing CBOR-LD...

From: Leonard Rosenthol <lrosenth@adobe.com>
Date: Fri, 24 Jul 2020 15:00:49 +0000
To: Manu Sporny <msporny@digitalbazaar.com>, "public-credentials@w3.org" <public-credentials@w3.org>
Message-ID: <DD1D2AE8-363A-46F7-9872-0DF0F7CE578D@adobe.com>
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.

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


Received on Friday, 24 July 2020 15:01:06 UTC

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