W3C home > Mailing lists > Public > semantic-web@w3.org > June 2021

Re: Chartering work has started for a Linked Data Signature Working Group @W3C

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Fri, 4 Jun 2021 15:57:37 -0400
To: semantic-web@w3.org
Message-ID: <4a852ba7-761e-846b-baff-29928f238ff2@digitalbazaar.com>
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

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

-- manu

Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
Received on Friday, 4 June 2021 19:58:07 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:46:08 UTC