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.

This is analogous to the way the JSON-LD API specification was written. For a
complete example, see the "Value Compaction" algorithm:

https://www.w3.org/TR/json-ld11-api/#value-compaction

You will note that the algorithm operates on things like INFRA maps, which
might be realized as different things in different programming languages. In
other words, the algorithms leave specific implementation details to
implementers while providing guidance on one way (typically easy to understand
but lacking in performance) to implement the algorithm. Take note of:

https://www.w3.org/TR/json-ld11-api/#conformance

That says:

> The algorithms in this specification are generally written with more
> concern
for clarity than efficiency. Thus, JSON-LD Processors may implement the
algorithms given in this specification in any way desired, so long as the end
result is indistinguishable from the result that would be obtained by the
specification's algorithms.

So, if you're trying to find a one-to-one mapping, you're going to be
disappointed... implementers typically put nice interfaces on their libraries
to avoid exposing their developers to unnecessary complexity in the underlying
algorithms.

> 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.

The document loader you're using is this one:

https://github.com/digitalbazaar/security-document-loader#background

and as you can see, it only loads security contexts that it knows about and
are vetted to be the right thing. This is the answer to one of the previous
questions you had -- how can you protect against remote context attacks. This
is the answer -- you don't load remote contexts and your software enforces
that rule.

> 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

-- 
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 Thursday, 3 June 2021 17:44:50 UTC