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: Dan Brickley <danbri@danbri.org>
Date: Fri, 4 Jun 2021 17:44:08 +0100
Message-ID: <CAFfrAFrH6iHfw6X=K5U7jEp+MC2WJ0TRUdHaAChxrFisvYr_6g@mail.gmail.com>
To: Henry Story <henry.story@gmail.com>
Cc: Ivan Herman <ivan@w3.org>, Manu Sporny <msporny@digitalbazaar.com>, semantic-web@w3.org
On Fri, 4 Jun 2021 at 17:32, Henry Story <henry.story@gmail.com> wrote:

>
>
> > On 4. Jun 2021, at 17:57, Dan Brickley <danbri@danbri.org> wrote:
> >
> > Ivan Herman wrote:
> >> I suspect you are referring to the problems that arise with the context
> file, although I am not sure why that is a "multi stakeholder syntax"
> >
> > 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. 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.
>
> As I understand: it is not the JSON-LD document as such that is signed but
> the RDF graph or dataset that is produced by parsing the JSON-LD and the
> namespace document that comes with it.
>
> If  names used in a JSON-LD are mapped to a different ontology due to some
> change in the namespace document, this will result in a different RDF
> graph,
> and so the signature verification will fail.
>
> So I don’t see what the problem here is.


Most signing humans are unlikely to actually inspect parser-emitted triples
by hand, but might glance over the surface syntax for obvious anomalies or
mischief, especially for small documents. If an attacker switched the
context for just the right second or two, there may be gullible workflows
in which they could get nasty triples parsed and signed, without other care
being taken. It seems an avoidable class of cornercases to have to work
around.


>
> Henry
>
Received on Friday, 4 June 2021 16:46:56 UTC

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