Re: CBOR-LD for VC

A generic problem with CBOR is that the authors assumed that everybody is happy with the centralized IANA registry holding integer tags.

For my own CBOR work, I'm considering decentralized URLs: https://github.com/ietf-rats-wg/eat/issues/165

Anders

On 2022-02-14 19:47, Christopher Allen wrote:
> On Mon, Feb 14, 2022 at 2:18 AM Joel Thorstensson <oed@3box.io <mailto:oed@3box.io>> wrote:
> 
>     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). 
> 
> 
> We decided not using the old version of CBOR-LD as it was a mishmash of JSON-LD & IPLD, plus a little CBOR. Could be a newer version is better, but we are very uncomfortable in supporting IPLD in the mashup.
> 
> We don’t have a replacement but are investigating a number of more CBOR centric approaches, COSE, CSF (
> https://test.webpki.org/csf-lab/home <https://test.webpki.org/csf-lab/home>), or maybe one of our own tentatively called crypto-envelope that supports both signatures & encryption, and allows for partial signatures, multisig, transcryption, smart signatures predicates, etc.
> 
> We also have some cryptographic objects defined in CBOR that this group might find useful at
> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-006-urtypes.md <https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-006-urtypes.md> starting at 300.
> 
> These are largely for airgap QR wallet oriented scenarios: request a seed, Shamir shard a seed, derive an hd-key, key, or address, join in a multisig account and sign your part of one (though the later two are Bitcoin-centric now they are designed to be adaptable in future), and animated QR for larger transfers.
> 
> — Christopher Allen
>

Received on Tuesday, 15 February 2022 05:14:32 UTC