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, 5 May 2021 23:02:04 -0400
To: Peter Patel-Schneider <pfpschneider@gmail.com>, Dan Brickley <danbri@google.com>, Phil Archer <phil.archer@gs1.org>
Cc: Ivan Herman <ivan@w3.org>, Dan Brickley <danbri@danbri.org>, Aidan Hogan <aidhog@gmail.com>, Pierre-Antoine Champin <pierre-antoine@w3.org>, Ramanathan Guha <guha@google.com>, semantic-web <semantic-web@w3.org>
Message-ID: <57eca887-6cb8-653f-8909-6f143c6eb551@digitalbazaar.com>
On 5/4/21 10:59 AM, Peter Patel-Schneider wrote:
>> [1]https://tools.ietf.org/html/rfc8785
> Is using JCS viable?  Is there a unique canonicalization of an RDF 
> dataset (or RDF graph) expressed in JSON-LD?  If not, then I don't
> see how this could work.

For some use cases, yes, it's viable.

If you're signing JSON-LD, but don't want to do RDF Dataset
Canonicalization, then you can JCS and sign the payload... and then do
RDF Dataset Canonicalization much later when you really need to do it. A
very small minority of developers do this because they think RDF
Canonicalization is going to be too expensive (even though runtime for
most payloads is in the 1-4 milliseconds range... and blindingly fast if
you use canonicalization templates).

However, most of the folks that want to use Linked Data Signatures with
JCS never want to go to RDF... they just want to canonicalize the JSON
payload and sign it without base64 obfuscating the payload like JOSE
JWTs do.

I'm not saying that these are main stream uses of Linked Data
Signatures, but the design does allow for it, and there are some use
cases where it is a viable solution... and the companies using those
solutions (e.g., Workday) are not easily ignored.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
Received on Thursday, 6 May 2021 03:02:34 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 6 May 2021 03:02:36 UTC