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

> Peter F. Patel-Schneider wrote:
> > But the code you provide doesn't implement either sign or verify in
a way 
> > consistent with the algorithms in 
> > https://w3c-ccg.github.io/ld-proofs/#algorithms. Instead there is a
> > single command that uses internal data to simulate an external
document and
> > produces some logging output.
> 
> Ah, I see.
> 
> You are probably under the mistaken impression that there is a 1-to-1
mapping
> between the core algorithms specified in LDP and implementations. The
LDP spec
> is not a "library interfaces" specification, like what you'd expect
in a
> WebIDL specification. Instead, the LDP spec highlights the core
algorithms
> that one can implement to achieve a certain set of outputs given a
certain set
> of inputs. Implementers can implement these algorithms in any way
they choose
> as long as the outputs match other implementation outputs given the
same inputs.

Oh no, I very much understand this point.  Implementers are free to
implement the algorithms in any way that they want so long as they
conform to the description of the algorithms.  But the provided code
doesn't do that.  It may be that what the code does do internally
corresponds to the pieces of the algorithm, but there needs to be a
full implementation of the algorithm.

[...]

> > But the data in the code doesn't correspond to the document in
Example 1.
> > I modified the data accordingly and ran the code again, with the
following
> > result:
> > 
> > idefix pfps-ldp-example> node index.js -------------- UNSIGNED DATA
> > --------------- { "@context": "https://w3id.org/identity/v1",
"title":
> > "Hello world!" }
> 
> That example is ancient... I've updated the specification with more
modern
> examples.
> 
> > (node:36723) UnhandledPromiseRejectionWarning: jsonld.InvalidUrl: 
> > Dereferencing a URL did not result in a valid JSON-LD object.
Possible
> > causes are an inaccessible URL perhaps due to a same-origin policy
(ensure
> > the server uses CORS if you are using client-side JavaScript), too
many
> > redirects, a non-JSON response, or more than one HTTP Link Header
was
> > provided for a remote context.
> 
> Yes, this is because the code I wrote for you refuses to go out to
the
> Internet and fetch random JSON-LD Contexts. This is a security
feature. If the
> software doesn't have a local vetted copy of the JSON-LD Context, it
throws an
> error.

So the code doesn't implement that algorithm.  The code might be more
secure, it might be less secure, but what is needed is a implementation
of the algorithm.

[...]

> > So it looks as if there is problem.  The provided code can't even
sign
> > Example 1.  This looks very bad.
> 
> You tried to do something that is dangerous. The software prevented
you from
> doing that dangerous thing, which is the correct behaviour.
> 
> -- manu

I tried to run the code that is supposed to implement the algorithm (or
at least the closest code that I was provided).   It throws an
exception on valid inputs.  That's bad.  It doesn't matter whether
these inputs are dangerous.  Reference code should implement the
algorithm, i.e., produce a signed version of the document for any valid
JSON-LD document.

peter

Received on Thursday, 3 June 2021 19:45:53 UTC