Re: proofs for fragments of JSON-LD documents

Hi Markus,

that's a very interesting approach. But I couldn't figure out how to do
to make a graph connecting the elelmnts to be signed ... could you
provide an example?

Thanks in advance,

Andreas 
> Guiseppe,
>
> Others probably know this better, but I think this could potentially be
> done with graph containers:
> https://w3c.github.io/json-ld-syntax/#graph-containers
>
> I.e. in a single JSON-LD document, you could have multiple named graphs
> that can each have proofs which are independent from each other.
>
> Markus
>
> On 05.11.20 16:35, Giuseppe Tropea 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
>> —
>>
>>
>>
>>
>

-- 
Andreas Kühne 

Chair of OASIS DSS-X
 
phone: +49 177 293 24 97 
mailto: kuehne@trustable.de


Trustable solutions UG (haftungsbeschränkt), Gartenheimstr. 39C, 30659 Hannover, Amtsgericht Hannover HRB 219338

Trustable Ltd. Niederlassung Deutschland, Gartenheimstr. 39C, 30659 Hannover, Amtsgericht Hannover HRB 212612

Company UK Company No: 5218868 Registered in England and Wales

Received on Friday, 6 November 2020 11:37:45 UTC