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

Re: Thoughts on the LDS WG chartering discussion

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Fri, 11 Jun 2021 09:26:19 -0400
To: Ivan Herman <ivan@w3.org>, David Booth <david@dbooth.org>
Cc: Semantic Web <semantic-web@w3.org>
Message-ID: <c8dfdc51-5e3f-d784-ab37-cbf48e832d57@digitalbazaar.com>
On 6/11/21 2:51 AM, Ivan Herman wrote:
>> The other thing that I still fundamentally do not yet grasp about the 
>> proposed charter is this: Why is it restricted to RDF source documents? 
>> Clearly the canonicalization algorithm is about RDF, so that much I 
>> understand.  But for the digital signature vocabulary, why wouldn't it
>> also be useful to be able to sign, say, a PDF document?

The vocabulary can be used to express signatures on other sorts of documents.
For example, this is happening today in LD cryptosuites:

https://uport-project.github.io/ethereum-eip712-signature-2021-spec/#suite-definition

The specification above uses JCS to canonicalize (not RDF Canonicalization),
Keccak-256 to hash, and EIP712 using ECDSA K-256 to sign... and they
completely and fully use the Linked Data Signatures Vocabulary to express the
signature (which is great).

Why are we not speaking loudly about that work? Well, I think the 170+ emails
related to the charter and the "looseness" of "Linked Data" speaks to that.
It's a bridge too far for some in this community and so we're chucking it out
of scope for now in the name of compromise and getting to a charter we can all
get behind.

We have text in the charter now that says that we shouldn't prevent such use
cases, but the LDS WG isn't going to generate anything normative about those
use cases either.

It's a middle ground that we hope is going to work for everyone.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/
Received on Friday, 11 June 2021 13:26:59 UTC

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