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: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Fri, 4 Jun 2021 13:53:18 -0400
To: semantic-web@w3.org
Message-ID: <5ef5f12f-2826-9d98-4315-a7f260ffe20d@gmail.com>
As far as I can tell, what is signed is indeed a JSON-LD document.  This gives 
rise to the easy attack of modifying the document by introducing the use of a 
remote context.  The remote context is carefully constructed and manipulated 
so that the verification function sees the RDF dataset that the producer 
signed but that when the RDF dataset is actually extracted by the consumer a 
completely different RDF dataset results.  The verification and extraction can 
be separated by an arbitrary amount of time and performed in completely 
different contexts.


On 6/4/21 12:32 PM, Henry Story 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.
> Henry
Received on Friday, 4 June 2021 17:54:49 UTC

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