Add CBOR a valid type of DID document syntax similar to JSON and on par with JSON-LD

[msporny]

@jonnycrunch wrote:

This was initially raised in the W3C CCG via this PR: w3c-ccg/did-spec#110

[I'd like the group to] review the related work items for Multihash, Multicodec and Multibase, etc. Afterwards y'all may have a better understanding of where I am coming from. In particular, IPLD is not the same as IPFS. IPLD (Interplanetary Linked Data) is a self-describing abstracted data model relating a cryptographic identifier to the content and does not necessarily depend on resolving it over a particular protocol, although this is often how it is used in IPLD. It is important to emphasize that the CID (content Identifier) stands on its own without relying on a platform. It is basically the application of multihash, multicodec and multibase which equals the CID. In context of DID, the CID could be used with pairwise identifiers and NOT be stored on IPLD/IPFS and thus may not necessarily resolve. see the draft of the paper here: https://github.com/WebOfTrustInfo/rwot7-toronto/blob/master/draft-documents/ipld_did_documents.md If we go down the path of MUST include the URI schema name (IPLD:) then it implies that it must be a resource resolvable on IPLD, which may not be the case. What I am asking for is a reservation of "/" to describe a CID NOT an IPLD or IPFS resource.

The second part of my PR relates to the list of public keys should be by object and thus becomes a deterministic outcome when serialized in to CBOR. just a simpler approach in my mind than the iterating over an array, which could change and thus NOT be deterministic changing the hash (and therefore CID) of the content. Perhaps my title of this pull request should be "make DID document deterministic" and relates to the @context which can change and the array of public keys which if you don't keep track of the order will change the hash of the content ( CID ).

so, the real lift here is to make IPLD a valid type of JSON on par with JSON-LD. similar to my PR from VC data model: w3c/vc-data-model#261.

[jonnycrunch]

@jonnycrunch adding myself to the conversation.

[burnburn]

@jonnycrunch on our 17 Dec 2019 call you said that this issue had been closed. I think it is just stale. If discussion does not start organically, there will come a point when the chairs and editors revisit stale issues in order to get them moving.

[msporny]

What is the next step here... if this issue doesn't start moving soon, we should close it. It's been open for 14 months w/o going anywhere. When can we expect a PR to address this issue, @jonnycrunch?

[jonnycrunch]

I am working on adding the section for CBOR as the underlying data serialization format for IPLD.

[OR13]

since CBOR is now a valid representation, this is now only blocked by updates to the registry, for all 3 representation types... https://github.com/w3c/did-core-registry

I suggest closing this issue, and getting anything CBOR related into the did core registry.

[jonnycrunch]

@OR13 Mmm, I'm not in favor of closing. I'm actively working on this. Perhaps rename this issue to Add CBOR a valid type of DID document syntax similar to JSON and on par with JSON-LD. I though the registry was about the content, not how it is represented or serialized.

[msporny]

Perhaps rename this issue to Add CBOR a valid type of DID document syntax similar to JSON and on par with JSON-LD.

Done.

I though the registry was about the content, not how it is represented or serialized.

Correct.

[burnburn]

@jonnycrunch ping for update

[jricher]

There is now a section in the document for this: https://w3c.github.io/did-core/#cbor

And it should follow the structure of the other representation sections.

[kdenhartog]

curious where you are with this as well @jonnycrunch if you haven't started, I'll pull it off my backburner todo list and take a stab at it.

[jonnycrunch]

see: #282 Thanks! @kdenhartog