- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Fri, 4 Jun 2021 15:57:37 -0400
- To: semantic-web@w3.org
On 6/4/21 11:57 AM, Dan Brickley wrote: > Ralph Swick was very clear about this in the 1997 RDF Model and Syntax WG. A lot of things have evolved since 1997... :) > That an RDF document (given a base URI) should unambiguously determine the > triples/graph, without the content of the resulting graph depending on > pulling in code from other parties over potentially unreliable connections. > RDF/XML, Turtle, N3, RDFa etc meet that criteria... So does JSON-LD if you load your contexts from a known source (from disk, known hash, etc.), which again, is a common best practice. > “Multi-stakeholder” is new terminology intended to capture the idea that > the RDF your document maps to is a result of your collaboration with the > parties controlling any remote contexts it references. You could have just said "The Web". :) > And that this is recursive and dynamic; parsers without the right context > data won’t know what to emit. Which parsers won't know what to emit? It feels like you're inventing a new class of parser to make your point. > Correct - it is multi-stakeholder because the meaningful graph that others > will extract from parsing your document is out of your sole control, if > you reference external contexts. No, even if there are external contexts, you can control which ones you use. This is provably true with JSON-LD. > Changes to those contexts can radically reshape the triples that some > json-ld parses to. This is different to merely referencing external IDs and > vocabulary; the exposure goes much deeper, and is under appreciated. It's not under-appreciated. There are well known mitigations to the concern you are raising, those mitigations have been used for years, and that happened after many years of discussing and appreciating the problem. This may be the first time you're realizing the concern, but I can assure you that others have appreciated the problem for a long time and that there are mitigations to this concern (that I've highlighted in multiple emails). Once again, some of the mitigations include: 1. Only load external references from disk that you have vetted and control. 2. Only load external references that have associated cryptographic hyperlinks (using the hashlink spec, for example). 3. Fully embed all of your external references when signing. 4. Throw an error when someone uses an external reference. > That is interesting, and progress, but these discussions seem still to > presuppose JSON-LD is the best and focal foundation for signed Linked > Data; No. Who has presupposed that JSON-LD is the best and focal foundation for signed Linked Data? What has been asserted is that JSON-LD should be taken into account when developing the solution because there is a significant implementation and deployment base there. > Manu’s warning suggests instead it may be amongst the least appropriate. It's only the "least appropriate" when you ignore the vigorous "don't do that!" hand waving regarding loading remote data when signing or verifying. > I don’t say this lightly. I am responsible for a JSON-LD context document > referenced by many millions of sites. I fear that the most security > literate reviewers of the charter we’re discussing may not be aware of this > aspect of how JSON-LD works. JSON-LD is a good thing for the web, great > even, but as the primary focus for an RDF data signature ecosystem it has > *massive* downsides too. Who said it would be the primary focus? It is one serialization considered in the charter and is given no special standing related to the other RDF Dataset serializations. -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. blog: Veres One Decentralized Identifier Blockchain Launches https://tinyurl.com/veres-one-launches
Received on Friday, 4 June 2021 19:58:07 UTC