12E/ Some problems with JSON-LD and Content Based Addressing
Some problems with JSON-LD and Content Based Addressing
Convener: Burak Serdar
Tags for the session - technology discussed/ideas considered:
JSON-LD, RDF, JSON, digests
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
JSON-LD is not namespaces for json
@context does not enforce structure. It is a key mapping
@context does not define the semantics, it defines mapping to a terminology
JSON-LD is extremely difficult to understand and debug.
Readability ≠ Clarity
JSON data is usually self-explanatory without processing.
Go Motto: Clear is better than clever (https://dave.cheney.net/2019/07/09/clear-is-better-than-clever)
Expanded JSON-LD might be more workable in the VC domain, but then, it is JSON
Content based addressing (digesting)
Self-contained (i.e. digested object should not have external links)
Is normalization really necessary? I believe it is not. Treat JSON as a BLOB, no normalization
Hashing self-contained objects is the key (e.g. no external @context)
There are ways of doing that even with external references
Manifests: JSON file pointing to all references
Other discussion points:
SAIDs: A SAID is equivalent to an envelope containing hash and payload.
Layered schemas example: weak-references to schemas (IRIs), strong references to schemas (digest)
Link to the document shared during the presentation: https://docs.google.com/document/d/1IS8tOcrVvL2PcvzPk0JAYnZIVtcHsaXmyObk0bYA5TY/edit?usp=sharing
Link to the slides:
12:20:43 From Timothy Ruff : The problems with JSON-LD for VCs are many, both for security and semantics, and are detailed in Dr. Sam Smith's paper here:
12:23:07 From Timothy Ruff : For these reasons, GLEIF is not compatible with 1.0 of the W3C spec, but is compatible with 0.9. Here is their position paper about why:
12:23:28 From Brian Richter : @Timothy the vc spec ya?
12:23:45 From Timothy Ruff : Yes! Label Proper Graphs are the way forward.
12:23:59 From Timothy Ruff : @Brian - Yes, I meant the VC spec
12:25:22 From Timothy Ruff : If you guys read Sam's paper linked above, you'll have all the reason you need to avoid JSON-LD completely. The presenter is 100% correct: you only need JSON, JSON schema, and LPGs (label property graphs).
12:25:36 From Dmitri Zagidulin : Timothy: that paper is full of FUD, though..
12:25:58 From Timothy Ruff : That sounds like FUD. Need to be specific, refute Sam's points.
12:26:29 From Timothy Ruff : Sam backs up every point with references. FUD doesn't provide references.
12:27:51 From Timothy Ruff : This presenter is independently coming to the same conclusions, for the same reasons.
12:28:41 From Brian Richter : I have also started to come to these conclusions on my own
12:29:41 From Brian Richter : I believe there’s some parts of jsonld that can be saved though
12:30:02 From Timothy Ruff : Gotta run to another session. When I saw what this was about, I wanted to share these docs and head back. Done. Have fun debating the "FUD"! :)
12:37:37 From Dmitri Zagidulin : have hashlinks (the IETF draft) been considered for SAIDs?
12:37:55 From Kyle Den Hartog : https://github.com/kdenhartog/context-integrity
12:38:05 From Kyle Den Hartog : That’s the path I started working down
12:39:02 From Dmitri Zagidulin : nice, thanks Kyle
12:50:24 From Dmitri Zagidulin : I think I'd argue with the "JSON is self-explanatory" :)
12:53:43 From Brian Richter : I’ve seen a lot of “name” properties meaning a lot of different things
12:54:07 From Kyle Den Hartog : https://www.iana.org/assignments/jwt/jwt.xhtml
13:16:47 From Nuttawut (Finema) : Question: Does Sam Smith’s paper propose an alternative to JSON-LD?
13:20:32 From Dan Yamamoto : I agree with too-much complexity of JSON-LD/RDF ... but at the same time prefer its ability to combine heterogeneous documents issued by multiple issuers. Hope there might be kind of lightweight format with LD functionality in simpler way
13:24:04 From Burak Serdar : https://dave.cheney.net/2019/07/09/clear-is-better-than-clever