Vault deletion?

[DRK3]

Hi,

Is there a plan to add a method to the REST API to delete a vault? Currently it's missing from the spec.

[dmitrizagidulin]

Hi @DRK3, great question.

I suspect part of the reason that the spec hasn't tackled the subject of deleting a vault is the complexity of - so what should the semantics of that be?

If you're deleting a vault that currently has resources in it, does it mean that those resources are also deleted? If not.. is the implication that only "empty" vaults (ones that have no resources in them currently) are able to be deleted?

[dmitrizagidulin]

Part of what complicates vault deletion, incidentally, is the Replication aspect of vaults. If the semantics of deleting a vault is decided to be "delete all resources contained in the vault", the moment you add replication, should the semantics become "turn all of the resources in the to-be-deleted vault into Tombstone objects, and then propagate those tombstone objects to the replicas"?
Or do you say - it's the EDV Client's responsibility to issue delete commands to each vault that is being replicated to? (Which sort of makes sense for bi-directional replication, but what about one-way? For one-way, you're back to Tombstone objects.)
etc.

[DRK3]

Thanks for replying @dmitrizagidulin! A couple of questions:

I see that replication is a topic under Identity Hubs. Is the EDV REST API going to rely on Identity Hubs? So far in https://github.com/trustbloc/edv we've been implementing an EDV REST server without the concept of Identity Hubs (as the implementation started before Identity Hubs were added to the spec). I'm wondering if the delete vault endpoint needs to be dependent on the replication consideration, or if this is just an implementation detail for another layer.

On a related note, there's currently a delete document endpoint. Would the same questions you have regarding replication apply there too?

[dmitrizagidulin]

@DRK3

I see that replication is a topic under Identity Hubs. Is the EDV REST API going to rely on Identity Hubs?

Ah, good question -- no. The EDV is a lower layer (Hubs may want to depend on it, but EDV does not depend on or know about Hubs). So, EDVs have the replication feature, it's just not really documented in the spec yet.

But back to the original question of vault deletion -- it might be a useful feature!
We just need to agree on the semantics of it, and how it interacts with replication.

[dmitrizagidulin]

On a related note, there's currently a delete document endpoint. Would the same questions you have regarding replication apply there too?

Yes, that's right - same question applies (though in the case of a single document, it's fairly straightforward -- it gets turned into a Tombstone object, to be replicated if applicable).

[agropper]

For an encrypted data vault, deletion could be done by discarding the key regardless of replication. Deletion is needed when the storage is not encrypted or when the controller wants to stop paying for the service. My suggestion would be to document deletion and how we handle replicated vaults. I still think we should avoid using the term encrypted data vault unless we also intend to specify an unencrypted data vault as well that has all of the same access control, replication, and deletion features as the encrypted vaults. Is it our plan to specify both kinds of vaults?

…

On Tue, Nov 10, 2020 at 7:45 PM Dmitri Zagidulin ***@***.***> wrote: On a related note, there's currently a delete document endpoint. Would the same questions you have regarding replication apply there too? Yes, that's right - same question applies (though in the case of a single document, it's fairly straightforward -- it gets turned into a Tombstone object, to be replicated if applicable). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/decentralized-identity/secure-data-store/issues/114#issuecomment-725074821>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YPM5MELQFIKDPMRIELSPHUFBANCNFSM4SKOWLIQ> .

[dmitrizagidulin]

@agropper

deletion could be done by discarding the key regardless of replication. Deletion is needed when the storage is not encrypted or when the controller wants to stop paying for the service.

Strong -1 to this. One of the central tenets of the EDV spec is that encryption alone IS NOT sufficient, and requires authorization controls (and actually deleting the data from disk and replicating that deletion) in addition to encryption.

[agropper]

I agree with you! This is EXACTLY my point that the E in EDV is a problem. We need to deal with authorization, replication, and deletion as the foundation of Confidential Storage. The encryption is an ADD-ON that we all recognize is hugely important but it is not the foundation.

…

On Wed, Nov 11, 2020 at 12:24 PM Dmitri Zagidulin ***@***.***> wrote: @agropper <https://github.com/agropper> deletion could be done by discarding the key regardless of replication. Deletion is needed when the storage is not encrypted or when the controller wants to stop paying for the service. Strong -1 to this. One of the *central* tenets of the EDV spec is that encryption alone IS NOT sufficient, and requires authorization controls (and actually deleting the data from disk and replicating that deletion) *in addition* to encryption. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/decentralized-identity/secure-data-store/issues/114#issuecomment-725584994>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YNBMLSLBJXSA2YI2R3SPLJF3ANCNFSM4SKOWLIQ> .

[dmitrizagidulin]

@agropper

encryption is an ADD-ON that we all recognize is hugely important but it is not the foundation.

See, whereas I think it's exactly the opposite. Encryption is the foundation, and it has huge effect on what kind of authorization and replication is possible. Basically, we start with the fact that everything must be encrypted. And all the other standards align around that.

[agropper]

@dmitrizagidulin It's a 'chicken-and-egg' problem. Everything was plaintext at some point when it was created or processed. In a zero-trust architecture, that plaintext has to be protected and access-controlled. I think we all want Confidential Storage to have a clear relationship to ZTA. I'm suggesting that the "layering" we like to consider should be designed according to ZTA rather than protocol assumptions.

…

On Wed, Nov 11, 2020 at 3:46 PM Dmitri Zagidulin ***@***.***> wrote: @agropper <https://github.com/agropper> encryption is an ADD-ON that we all recognize is hugely important but it is not the foundation. See, whereas I think it's *exactly the opposite*. Encryption is the foundation, and it has huge effect on what kind of authorization and replication is possible. Basically, we start with the fact that everything must be encrypted. And all the other standards align around that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/decentralized-identity/secure-data-store/issues/114#issuecomment-725678756>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YOPCO56BXRYQHBZ3PTSPMA3TANCNFSM4SKOWLIQ> .

[dmitrizagidulin]

Discussed on the May 27, 2021 call.

• Seems like there is demand for vault deletion.
• Question: How should this interact with replication? Specifically, if you delete one vault, AND replication is set up, does the deletion operation propagate to other vaults?
• Question: Can you re-create a deleted vault with the same identifier? (In other words: which party is responsible for picking the vault ID, on creation? It should be server.)

[dmitrizagidulin]

Revisited on Jun 10, 2021 call.

• Replication wise: If replication is server-side, then yes, we'd need a section of Vault Config document specifying replication specifics (and whether vault deletion propagates). Waiting for server-side repl implementations, to discuss further.