From the perspective of encrypted-at-rest, there are are only three possible keystores corresponding to an EDV document: (i) a wallet user-agent of the live EDV customer, (ii) a semi-autonomous agent of the EDV customer, and (iii) a client as user agent of someone else.
Focusing on EDV as a multi-user service... Some of the corresponding keystores will also be multi-user services. (i) custodial wallet services, (ii) cloud agents hosted as fiduciary services, and (iii) delegated clients such as enterprise IT. We should design for the case where the multi-user EDV and the multi-user keystore are controlled by different legal entities.
In designing the EDV access security protocols, we must consider the interests of the EDV service (RS), the keystore service (AS), and the data subject (RO) that is the customer to both RS and AS. How does the RO keep the other parties accountable? How is security audited?
An AS keystore service is a honeypot for all of their customer’s data whether the RS is an EDV or plaintext vault. Does that mean we can’t have semi-autonomous agents-as-a-service?
A zero-trust architecture would help keep the AS accountable and auditable to whatever extent the RO demanded by reducing the confidentiality of EDV. For example, clients presenting to the EDV (RS) would be required to provide non-repudiable credentials, not for access in the capabilities sense, but for submission to an independent auditor. How else might we do this?
