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

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

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Wed, 19 May 2021 11:10:29 -0400
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
Cc: semantic-web <semantic-web@w3.org>
Message-ID: <264593c4-502d-d614-def1-9ae02daf4931@digitalbazaar.com>
On 5/13/21 10:15 AM, Peter F. Patel-Schneider wrote:
> My understanding is that each and every aspect of a proposal involving 
> security is important, down to the smallest details.

Yes, correct.

> So it isn't just that parts of the methods described in
> https://w3c-ccg.github.io/ld-proofs/ are considered to be secure, each and
> every part of the methods have to have been shown to be secure.

Yes, correct.

> It is the case that the entirely of the methods in 
> https://w3c-ccg.github.io/ld-proofs/ have been shown to be secure?

Keep in mind that everyone will have a different definition of "shown to be
secure" -- mathematicians and cryptographers require a set of assumptions to
provide any sort of answer and the answer is usually in the form of "given
assumptions A-G, with parameters Q-Z applied, the solution is expected to
require H compute-years on J hardware to have a K probability of a
collision/solution being successfully found." ... and you'll note that the
statement doesn't say anything about "shown to be secure".

All that to say, people that don't spend years in cryptography and mathematics
think that there are clear answers to questions around security when there are
typically an array of assumptions and parameters that go along with questions
and answers related to the notion of "secure".

All that to say -- a growing number of people that have been working on this
stuff for many years now thinks it's "secure", we're using "secure"
cryptographic primitives and parameters, we're bundling the messages in ways
that we believe are "secure" and doesn't reduce the levels of security
provided by the cryptographic primitives, and we have independent mathematical
proofs on the generalized solveability of the RDF Dataset Canonicalization
problem.

Has it been shown to be secure? The proposers of the LDS WG Charter think so,
and there are papers written on the topic, otherwise we wouldn't be proposing
a LDS WG Charter. While that's true, we also want the sort of broad review
that a W3C WG can provide... we've done as much as we can outside a WG, we now
want more eyes on it to increase the probability of finding issues if there
are any.

> Where are the implementations of the methods in 
> https://w3c-ccg.github.io/ld-proofs/?  I'm willing to test them out.

Spec is here:

https://json-ld.github.io/rdf-dataset-canonicalization/

Test suite is here:

https://json-ld.github.io/rdf-dataset-canonicalization/tests/index.html

There are several independent implementations that run against the test suite
here:

JS - https://github.com/digitalbazaar/rdf-canonize
C++ - https://github.com/digitalbazaar/rdf-canonize-native
Java - https://github.com/setl/rdf-urdna
Go - https://github.com/piprate/json-gold
Python - https://github.com/digitalbazaar/pyld
Rust - https://github.com/digitalbazaar/rdf-canonize-rs
Ruby - https://github.com/ruby-rdf/rdf-normalize

> In particular I'm looking for implementations that take a document encoding
> an RDF dataset and produce a document signing the dataset and
> implementations that take a document encoding a signed RDF dataset and
> verify the signing.

There are libraries that do this at a higher layer (for Verifiable
Credentials) here:

https://github.com/digitalbazaar/vc-js
https://github.com/spruceid/didkit
https://github.com/danubetech/verifiable-credentials-java

... and so on.

Hopefully that's enough to get you started.

-- 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 Wednesday, 19 May 2021 15:10:45 UTC

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