Feature Request: Selectively Add/Remove Recipients for a Document

[evanlally]

Application-Level Action	Feature Needed from EDV API(s)
Add recipients for an existing document in an EDV, without re-encrypting the document.	Ability to create new wrapped encryption keys for a document that already exists in an EDV
Selectively remove a subset of recipient(s) of a document without re-encrypting the document and re-issuing keys	Ability to delete some wrapped encryption keys without deleting or re-issuing others

[tolson4]

@aljones15 Here's an example scenario for reference:

• User A uploads a file to an EDV, providing User B as a recipient during initial upload.
• User A adds User C as a recipient. This is done without having to reupload the stream of data associated with the file.
• User A remove User B as a recipient. This done without having to reupload the stream of data associated with the file.

[dlongley]

We're going to leave this issue open -- but for now, using WebKMS is a better mechanism for managing recipients.

[aljones15]

Just so future implementers have a little more context:

The solution we decided on for this issue was that an EDV can have a single KeyAgreementKey (recipientKaK) managed by a WebKMS system such as bedrock-kms. Each document in the EDV is a JWE with a single JOSE recipient that is created using the recipientKAK. When a profile wants to delegate access of a document in their EDV to another profile, they delegate the other profile a zcap for a specific document and a zcap for the document's recipient KaK. This ensures that no EDV document has more than 1 recipient. This removes the need for managing multiple recipients in a JWE and the need for multiple KaKs. It also means that when a zcap for a document is revoked, there is no corresponding recipient in the EDV document's recipients property that needs to be cleaned up. The later can be quite costly. When an Edv Document has a corresponding stream, that document has multiple chunks with duplicate recipient properties. If you have multiple recipients then you will need to clean up multiple edvChunks' recipients in addition to the edvDocument's recipients property. For larger files this can mean mutating thousands of records in the database.

[dlongley]

Closing this issue as we do not recommend managing recipients this way (but rather, through a WebKMS or WebKMS-like API for accessing key agreement / hmac keys).