Personal Data Vault

Personal Data Vault (pdv) stores a user's files and structured data encrypted at rest and shares them with on-site workflows or external API consumers on a case-by-case basis, always under the user's own consent. Encryption keys are managed through the Key module under a three-tier key hierarchy, so a database dump or a stolen disk reveals nothing: bodies, metadata, and even on-disk filenames are encrypted or opaque.

What it does

• Encryption at rest. Envelope encryption: a Master KEK wraps a per-user Subject KEK, which wraps a per-document key. New data is sealed with XChaCha20-Poly1305 (portable to every host); AES-256-GCM is supported as an explicit pinned-fleet choice. The Master KEK can also live in OpenBao or HashiCorp Vault (Transit), so the root key never reaches Drupal.
• Owner consent. A consent ceremony where the owner approves exactly what a consumer may read or write, with per-user and per-kind trust and an optional "require explicit consent" preference. Read and write are independent scopes: holding one never grants the other.
• Owner passphrase. An owner can gate their vault behind a secret the operator does not hold: the Subject KEK is wrapped under the passphrase as well as the Master KEK, so a locked vault is unreadable to the site operator too. The unlock window is configurable and slides with activity.
• Multi-tenancy. Several vault realms on one site, each with its own Master KEK and its own item kinds, with a pluggable resolver deciding which realm a request belongs to.
• Files and structured records. Store uploaded files or typed records described by reusable kinds, with translatable labels shown to each user in their own language.
• Cross-site access. A separate Drupal site can read and write a vault over an OAuth-gated HTTP API, addressing one or several vaults.
• Webform integration. A vault file and record element prefills from and saves back to the vault, whether the vault is local or remote, and can be switched off per user or site-wide.
• Operator and lifecycle tools. A vault subjects report, Master KEK rotation (re-wrap at scale via cron, Batch, or drush), GDPR-aligned crypto-erase purge, owner-driven vault export for data portability, automatic cleanup of dormant vaults that warns before erasing, a bounded cron garbage collector, and per-consumer flood limiting on the cross-site surfaces.

Modules

• pdv: the vault itself (required).
• pdv_vault: hold the Master KEK in OpenBao or HashiCorp Vault (Transit).
• pdv_client_api, pdv_client, pdv_server_api: the cross-site contract, the consumer-side client, and the vault's HTTP surface.
• pdv_webform: the Webform element and handler.
• pdv_audit_trail, pdv_client_audit_trail: optional bridges into Audit Trail.
• pdv_mail, pdv_message, pdv_eca: deliver vault notifications, as fixed email, editable Message templates, or no-code ECA rules respectively.
• pdv_test_console: a development-only consumer simulator for the sharing flows.

Requirements

Drupal 11.3 or Drupal 12; PHP 8.2 or newer with the sodium extension; Key and Consumers. The cross-site API submodule also needs Simple OAuth, and the Webform element needs Webform.

API stability

The supported PHP API is the documented interfaces, value types, events, and SCOPE constants; the concrete service classes are marked internal and final, so depend on the interfaces and the container bindings rather than on those classes. The cross-site HTTP contract is described by the OpenAPI spec shipped with the module. Full documentation (concepts and the key hierarchy, owner and consumer guides, cross-site setup, and an API reference) lives in the module's docs directory and is available here.