Re: proofs for fragments of JSON-LD documents

Giuseppe,

You may be interested in checking out https://github.com/w3c-ccg/ldp-bbs2020

The LD signatures described there can be used to reveal any subset of
signed attributes.

On Thu, Nov 5, 2020, 17:17 Leonard Rosenthol <lrosenth@adobe.com> wrote:

> In order to sign portions of a JSON-LD document, you are going to need to
> perform JSON-LD canonicalization, such as described in
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-17.
>
>
> Leonard
>
> On 11/5/20, 1:09 PM, "Giuseppe Tropea" <giutropea@gmail.com on behalf of
> giuseppe.tropea@cnit.it> wrote:
>
>     dear CCG Linked Data Proofs,
>
>     we have a use case where multiple JSON-LD “fragments” are to be
> digitally signed by different producers, and then aggregated in order to
> give a unified JSON-LD entity back to a consumer.
>
>     Specifically:
>     Producer1 produces Fragment1 = {ID, A1, B1, P1}. The document has an
> ID, two properties A1 and B1, and a linked data proof P1.
>     Producer2 produces Fragment2 = {ID, A2, B2, P2}. Please notice the two
> fragments have the same ID. The distributed information they carry refers
> to the same object.
>
>     The goal is for the consumer, upon receiving {ID, A1, A2, B1, B2, P1,
> P2, X3, Z4, …}, to be able to:
>     - prove that A1 and B1 have been signed by P1 for the specific ID
>     - similarly for A2 and B2
>
>     Is there a way to explicitly list, within the proof, the subset of the
> top-level properties the proof takes into account? (Defaults to the whole
> document, of course). In other words, would it be desirable to specify a
> way for the algorithms to natively operate on portions of JSON-LD documents
> vs. the whole?
>
>     Otherwise, we have to accomplish this by operating on top of the
> linked data proof libraries, by “manually” reconstructing the two original
> fragments out of the aggregate, provided we can embed inside each “proof”:
> {…} the list of top-level properties the proof actually covers.
>
>     Does a specific vocabulary exist for this purpose? Is is legit to
> inject custom vocabulary inside “proof”: {…}, such as:
>
>     “proof”: {
>       “refersTo”: [ID, A1, B1]
>       …
>       …
>     }
>
>     To give some context, this is emergent because of our attempt to add
> security (provenance, integrity. etc…) to the current version of the
> NGSI-LD standard for IoT and Context Information, in progress at ETSI,
> which takes into account federated and distributed deployments.
>
>     Thank you,
>     giuseppe
>
>
>     —
>     Giuseppe Tropea
>     CNIT - Italy
>     giuseppe.tropea@cnit.it
>     —
>
>
>
>
>
>