Use IPLD as a JSON syntax for claim

[jonnycrunch]

I'd like y'all to have a serious look at IPLD for VC (as well as the DID document). He is my draft document from the recent Rebooting Web of Trust arguing my point.

https://github.com/WebOfTrustInfo/rwot7/blob/master/draft-documents/ipld_did_documents.md

While I do like JSON-LD, having cryptographic resolution of the payload is important in this application.

Only change here that is necessary is to reserve the key "/" for a CID and resolution over IPLD.

"@context" : 
    { "/" : "zdpuAmoZixxJjvosviGeYcqduzDhSwGV2bL6ZTTXo1hbEJHfq" }, 
   ... 
 "creator" : 
    { "/" : "zdpuAvqt1YTeAdcyyncBDdJLVgKyZNbHm17rBEJNqFzVbg24B" }

This also binds the entire claim as a self-describing content addressed hash. Much more secure to DNS poisoning attack.

I don't like to argument that we have settled on JSON-LD as the only solution for a VC.

Also, see my PR for the DID-spec:

w3c-ccg/did-spec#110 (comment)

---

Preview | Diff

[burnburn]

Hi @jonnycrunch have you joined the Working Group? I don't see you in the participants list (https://www.w3.org/2000/09/dbwg/details?group=98922&public=1&order=org). You can check here (https://www.w3.org/2004/01/pp-impl/98922/join) to see if your org is a member.

[BigBlueHat]

While I do like JSON-LD, having cryptographic resolution of the payload is important in this application.

@jonnycrunch fwiw, solving for these scenarios is something we're exploring more broadly in the JSON-LD WG. We have a broad issue for content addressable @context files. That might be a better layer to explore this at--since it would effect the "document loading" options available to JSON-LD syntax processors. See also the Remote Document and Context Retrieval section of the JSON-LD API.

Short version, though, is that the exact JSON structure above won't work because you'd be defining a "term" of /--which isn't your intent. A URI-based structure for IPLD is probably a more generally usable thing that would avoid collision with existing identifier and term spaces.

But let's continue the chat over at w3c/json-ld-syntax#9 😄

[jonnycrunch]

@burnburn I was an invited expert to the group in the past before it became a working group.

@BigBlueHat BigBlueHat I think the syntax should apply for VC/DID syntax more broadly first and take on the argument as an enhancement to JSON-LD @context in particular later.

@msporny the reason I don't like the URI format i.e. ipfs://<hash> is that it allows for cycles in the graph and therefore NOT a true DAG, which opens it up for attack. Allowing {"/" : "<cid"} syntax for VC/DID truly binds the meaning of the data. As I suggested in the PR, the "/" SHOULD be reserved keyword for IPLD syntax for cryptographic validation. The proof of its success would be in its adoption and implementation.

[msporny]

@burnburn I was an invited expert to the group in the past before it became a working group.

@jonnycrunch -- I think that @burnburn is pointing out the fact that you're attempting to contribute something that isn't covered under a W3C Intellectual Property Release... and we need that sorted before we can accept substantive changes from you. So, either 1) your company needs to join W3C, or 2) the Chairs need to add you as an Invited Expert to the Working Group. Both processes take multiple weeks to perform and are there to protect the Web from patent trolls (which you are not, but the W3C Membership takes this sort of thing very seriously and does not make exceptions).

@BigBlueHat BigBlueHat I think the syntax should apply for VC/DID syntax more broadly first and take on the argument as an enhancement to JSON-LD @context in particular later.

The VCWG's Charter does not allow us to make the sort of changes that you are proposing to how the JSON-LD Context would be interpreted. Only the JSON-LD WG is cleared to make those sorts of changes, of which @BigBlueHat is the co-Chair of that group. I'd take him up on his offer to help out.

@msporny the reason I don't like the URI format i.e. ipfs://<hash> is that it allows for cycles in the graph and therefore NOT a true DAG, which opens it up for attack.

I don't understand how using a different format for the identifier opens us up to attack? What's the attack?

Allowing {"/" : "<cid"} syntax for VC/DID truly binds the meaning of the data. As I suggested in the PR, the "/" SHOULD be reserved keyword for IPLD syntax for cryptographic validation.

I don't understand how doing this is any different than doing ipfs: - it feels like if one of them is susceptible to attack, the other approach would be as well.

The proof of its success would be in its adoption and implementation.

Standards typically happen in the opposite way... you prove a successful approach first via demonstrating adoption/implementation and THEN you standardize on that. Standardizing on something that's theoretical first often leads to failed standards (and is why there are so many failed "standards" these days).

[msporny]

@jonnycrunch how would you like us to proceed on this PR? There are a number of people above that are attempting to engage w/ you on alternatives. I don't think this PR is going to make it through, can we close it?

[jonnycrunch]

I am requesting to reopen this PR to consider IPLD as a valid JSON type.

[joeltg]

the reason I don't like the URI format i.e. ipfs:// is that it allows for cycles in the graph and therefore NOT a true DAG, which opens it up for attack.

Can you elaborate on this? How do ipfs:// or dweb:/ permit cycles? What is the attack? The IPFS folks have a nice writeup about recommended IPFS URIs for different contexts, and it seems like that's a much better conceptual fit for use in JSON-LD.

[jonnycrunch]

so this isn't a format for JSON-LD but a JSON format that is on par with JSON-LD. in this case, I am using Interplanetary Linked Data ( IPLD ) https://ipld.io not ipfs. IPFS uses IPLD under the covers. IPLD is a serialized dag CBOR (among others ). While ipfs:// is on track for ietf schema name, ipld:// is not. IPLD and JSON-LD are both a type of JSON. This PR is for IPLD to be considered under the JSON heading, NOT as a valid JSON-LD. IPLD is like JSON-LD but with cryptographic hash linking to the content via the "/" path syntax.

[burnburn]

@jonnycrunch this is a new feature that we can't consider until the IPR issues are worked out, and feature freeze was last November anywy. Leaving open but marking as deferred so it can be considered for a future version.