Updates

iherman · Mar 5, 2024 · 8cccbe6 · 8cccbe6
1 parent 8fbcdb9
commit 8cccbe6
Show file tree

Hide file tree

Showing 6 changed files with 35 additions and 23 deletions.
diff --git a/.gitignore b/.gitignore
@@ -52,3 +52,5 @@ local/*
 .prettierrc.yaml
 .Attic
 pr.ts
+testing/run/l.json
+
diff --git a/README.md b/README.md
@@ -1,15 +1,16 @@
-# rdfjs-di
-Data Integrity algorithms for RDF Datasets — Proof of concepts implementation
+# Data Integrity algorithms for RDF Datasets — Proof of concepts implementation
 
 This is a proof-of-concept implementation (in Typescript) of the [Verifiable Credentials Data Integrity (DI)](https://www.w3.org/TR/vc-data-integrity/) specification of the W3C. The DI specification is primarily aimed at [Verifiable Credentials](https://www.w3.org/TR/vc-data-model-2.0/) (i.e., JSON-LD based data structures to express credentials) but the approach is such that it can be used for any kind of RDF Datasets. This implementation does that.
 
-It is proof-of-concepts, because, primarily at validation time it lacks the rigorous checking of the proofs to be validating that is necessary for a security related tool. What it proves, however, that the DI specification may indeed be used to provide a proof for an RDF Dataset in the form of a separate "Proof Graph", i.e., an RDF Graph containing a signature that can be separated by a verifier.
+It is proof-of-concepts, because, primarily at validation time it doesn't do all the checks that the DI specification describes, and have not (yet) been cross-checked with other DI implementations. What it proves, however, is that the DI specification may indeed be used to provide a proof for an RDF Dataset in the form of a separate "Proof Graph", i.e., an RDF Graph containing a signature that can be separated by a verifier.
+
+## Some details
 
 The steps for signature follow the "usual" approach for signing data, namely:
 
 1. The input RDF Dataset is canonicalized, using the [RDF Dataset Canonicalization](https://www.w3.org/TR/rdf-canon/), as defined by the W3C.
-2. The resulting canonical N-Quads are sorted, and hashed to yield a canonical hash of the Dataset (the W3C specification relies on SHA-256 for hashing).
-3. The hash is signed using a secret key for ECDSA. The signature value is stored as a bas64url following the [Multibase](https://datatracker.ietf.org/doc/draft-multiformats-multibase) format.
+2. The resulting canonical N-Quads are sorted, and hashed to yield a canonical hash of the Dataset (the W3C specification relies on SHA-256 for hashing by default, which is used here).
+3. The hash is signed using a secret key for ECDSA. The signature value is stored as a base64url value following the [Multibase](https://datatracker.ietf.org/doc/draft-multiformats-multibase) format.
 4. A separate "proof graph" is generated, that includes the signature value, some basic metadata, and the public key of for the signature, stored in [JWK format](https://www.rfc-editor.org/rfc/rfc7517).
 
 The package has separate API entries to generate, and validate, such proof graphs. It is also possible, following the DI spec, to provide "embedded" proofs, i.e., a new dataset, containing the original data, as well as the proof graph(s), each as a separate graph within the dataset. If a separate "anchor" resource is provided, then this new dataset will also contain additional RDF triples connecting the anchor to the proof graphs.

diff --git a/index.ts b/index.ts
@@ -1,3 +1,4 @@
+// deno-lint-ignore-file no-inferrable-types
 /// <reference types="node" />
 import * as rdf          from '@rdfjs/types';
 import * as n3           from 'n3';

diff --git a/deno.json → misc/deno.json b/deno.json → misc/deno.json
diff --git a/package-lock.json b/package-lock.json
diff --git a/package.json b/package.json
@@ -24,7 +24,6 @@
   ],
   "dependencies": {
     "@rdfjs/types": "^1.1.0",
-    "base64url": "^3.0.1",
     "n3": "^1.17.2",
     "rdfjs-c14n": "file:../../RCH/rdfjs-c14n",
     "uuid": "^9.0.1"