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

Re: CBOR-LD for VC

From: Joel Thorstensson <oed@3box.io>
Date: Mon, 14 Feb 2022 10:16:12 +0000
Message-ID: <CA+Dbgnn50_quXLT1Y8N3n5T1r2=tzupi5abPOO_RvVrqZrNxpw@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: W3C Credentials CG <public-credentials@w3.org>
Would be interesting to explore what the intersection of CBOR-LD, VCs, and
IPLD would be. IPLD is a dataformat for hash linked data. It specifies a
DAG-CBOR encoding which uses tag 42 to represent a hash link (which imo is
pretty much the only way you can responsibly do linked data).

regards,

*Joel Thorstensson *
Co-founder / CTO
[image: 3Box Labs] <https://3boxlabs.com>


On Mon, Feb 14, 2022 at 05:48:52, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> Continuing the CBOR thread but now with dedicated subject line.
>
> I'm not much into "LD" but obviously you should be able to create a
> CBOR-LD.
>
> The only real stumbling block I have found is that the "Guardians of CBOR"
> consider URLs as type identifiers a bad thing because:
> - The intention was (and is) that you register application-specific nnn()
> tags with IANA
> - URLs open the possibility reading CBOR schemas in run-time which is a
> known XML foot-gun
>
> Decentralized URLs as type identifiers are (IMO) a necessity for a lot of
> systems. Regarding reading schemas in run-time: there will always be people
> who do not understand how to write secure software but will do it anyway.
>
> As I wrote in another thread, using COSE signatures (or encryption) is
> something I wouldn't do. Using COSE public key and algorithm identifiers is
> though perfectly workable.
>
> Regarding possible COSE-LD signatures I would consider a solution where
> signatures only protect the actual bytes transferred, and feature the LD
> part as a hash. That is, validation of LD canonicalization would be an
> optional step.
>
> Thanx,
> Anders
>
Received on Monday, 14 February 2022 10:16:26 UTC

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