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 18:12:31 +0100
Message-ID: <CAFfrAFoNXiF7jOZ4LDEWD9Wns5QbU4dQ2-u7o6hDMctxaRFXNg@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: semantic-web@w3.org
On Fri, 4 Jun 2021 at 17:08, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 6/4/21 10:16 AM, Dan Brickley wrote:
> > That does sound really really bad.
> What, specifically, sounds really really bad? Please define "that".
> What the response above sounds like is this:
> """
> It sounds really, really bad that the software Manu wrote for Peter
> implements
> a known best practice to not, by default, load JSON-LD Contexts from the
> network, and instead load known good values from disk, when performing a
> digital signature.
> """

It may be a “known best practice” in VC-circles, but it goes counter to the
way people seem to be actively using json-ld in plenty of other developer
environments.  Maybe they’re wrong; maybe they should read the new draft
work-in-progress manual? Maybe they’re not the kinds of folk who should be
worrying about signing anyway?

How are you operationally defining “known good value” for a json-ld context

Is “good” related to freshness, trust in its provenance, lack of bugs in
its definitions? If multiple contexts reference multiple contexts,
presumably any non-good value pollutes the whole computation? Or is
goodness relative to which bits of the context are needed for parsing some
specific document, or other aspects of the way they are combined. E.g. does
it take into account that the order in which a good context references
other good contexts can still affect (intentionally or not) how the
contexts combine to determine parser output?

Do the publishers of the contexts get a say? How does it work in practice
(e.g. in your tool as discussed with Peter).

> It sounds like you're making an argument against a best practice. What
> part of
> what I said sounded bad to you?
> > Perhaps the WG charter should cover only use of self-contained Linked
> Data
> > / RDF format, eg Turtle/TRiG?
> If you are loading a JSON-LD Context from disk, it is self-contained Linked
> Data. If you are using embedded JSON-LD Contexts, it is self-contained
> Linked
> Data.

How about “For the application of its work to json-ld, this WG is only
required to define a Signature mechanism for self-contained Json-ld, in the
sense that all required context definitions are locally available, either
inline or from trusted application environments.”?

> A significant number of use cases exist in the Verifiable Credentials
> ecosystem, which is JSON-LD that refers to JSON-LD Contexts using HTTP
> Links
> and loads them from disk. We shouldn't be talking about putting those use
> cases out of scope since that is a significant amount of the implementer
> community for this work.

I think the scope text above or something like it could cover this. But
you’re getting really close to packaging format integrity here, w3c specs
don’t generally talk about “disks” as such.

> > And then try to secure hypertext / multi-stakeholder RDF syntaxes
> (json-ld,
> > grddl, ...) as a stretch goal rather than core business?
> As Ivan mentioned, this is already covered by previous changes that were
> made
> to the Charter based on your input. This "don't load remote contexts when
> doing a digital signature" falls under "additional Linked Data Integrity
> techniques" in "Other Deliverables". It's not mentioned in the core LDP
> algorithms because it's an "additional Linked Data Integrity technique"...
> we
> will probably want to speak to it in the Security Considerations.
> I will note that we put this stuff out of the critical path because it was
> requested to not be a focus of the group and now people are simultaneously
> frustrated that it's not mentioned in the LDP algorithm (Peter) and not
> completely out of scope (you).

It is not my role in life to make Peter happy.

I would like users of the hypothetical w3c signed RDF/LD specs to be have
it be made very very clear to them the additional and avoidable nuanced
complexities they’re bringing into their security workflows if they choose
json-ld with external contexts over the likes of Turtle/TrIG.  So that when
the inevitable shooting-themselves-in-the-foot happens, W3C itself doesn’t
get quite so splattered with reputational damage.

Is the nature of that concern at least clear, even if you think I am making
an excessive fuss because “best practices” cover this already?


> -- 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 17:17:14 UTC

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