Service Access

When uploading a document, the users client will store a file key to the encrypted file index, chunk the file (explained below) and encrypt the chunks with the file key:

Client data request from services

1. The service transmits a request to the client, indicating a context, desired data type, and it’s did:key (for the services public key).

2. Assuming the client accepts the request, it queries the document index for the list of required chunks (in correct order), and responds with a delegated ZCap authorization for each of the specific chunks, bundled with the file key.

Sequence Diagram illustrating service access:

The general protocol sequence is described in this sequence diagram. It has the specialty that to authorize the service for an particular EDV, no contact with the EDV has to be established, the authorization may happen entirely offline [from the client-side point-of-view] (given there is another [offline] way to exchange the authorization with the EDV, e.g. via QR codes).

Data exchange between service and EDV

1. The service contacts the EDV with a object retrieval request for each of the required file chunks. The requests are accompanied with the ZCap capability invocation the client delegated to the service.

2. The EDV encrypts the requested objects with the public key of the delegated did:key in the ZCap capability invocation and answers them back to the service.

Note that, both of steps may happen in parallel.

Service data decryption

1. The service decrypts each of the individually EDV-encrypted chunks with their private key.

2. The service decrypts each of the individually client-encrypted chunks using the file key provided by the client.

3. The service puts the chunks in the order specified by the client response.

Revocation

The client may revoke the data access of a previously shared(/trusted) service at any time using one of two possible methods:

• The client indicates a caveat in the initial ZCap capability delegation to the service, e.g. using SimpleCredentialStatus2022, which accesses a trusted revocation service. Multiple of such may be defined.

• The client uses the inbuilt did:key revocation feature of the EDV, which works like a blacklist, indicating otherwise valid ZCap authorizations for specific did:key ids no longer valid.