SCAMPER WP4 - Secure Data Vault Architecture

The architecture is driven by the specific constraints of the SCAMPER Work Package 4 (WP4).

The Quality Goals for the Secure Data Vault focus on the resilience, security and privacy of the storage mechanism itself.

These constraints concern the hardware, software, and cryptographic primitives we must use.

These constraints involve the project team, stakeholders, and development process.

The Business Context describes the information flow between the SDV and its stakeholders. The core principle is User-Centric Control with Privacy by Design.

The SDV is exposed as a web-accessible storage service (similar to a Solid Pod or S3 Bucket) but secured via UCAN (User Controlled Authorization Networks) instead of traditional OAuth/Accounts.

It differentiates technical interfaces based on the sensitivity of the data zone.

TODO: in development…​

The following table maps the project’s key goals to the specific architectural strategies chosen to achieve them.

The following technology stack was selected to implement these strategies, prioritizing open standards and browser/mobile compatibility.

We follow the "Smart Client, Dumb Server" architectural pattern. The SDV Acts as a high-availability "Digital Locker." It enforces who can open a locker (via UCAN check) but has no visibility into what is inside. It has mechanisms to facilitate finding data. The Client (Wallet) handles all business logic, data validation, encryption, and key management. Additionally, some of the more heavy compute could be offloaded to the SDV by using TEE on the server. Through attestation of the SVD TEE, a user wallet could delegate some heavy computation to the server. We will only rely on this for rare cases as this does put more trust in the SDV provider.

At the highest level, the Secure Data Vault (SDV) is a standalone server application that exposes HTTP interfaces to the outside world. It interacts with three primary external actors: the Data Owner (Wallet), the Verifier, and Public Entities.

Here we zoom into the Secure Data Vault to see its internal software architecture.

The SDV follows a Layered Architecture:
1. Interface Layer: Handles HTTP and Routing.
2. Security Layer: Validates Authorization (UCAN).
3. Domain Layer: Logic for Linked Data and Blob management.
4. Persistence Layer: Translates domain objects to database calls.

This flow describes "Cryptographic Signup." Unlike traditional web apps, there is no central admin to approve an account. The user asserts their existence by generating keys and claiming a namespace/pod.

The SDV does not check a database table for users. It mathematically validates that the UCAN signature matches the DID for which the pod is created. If successful the SDV generates the basic necessities bootstrap a user pod, such as storage identifiers, or table entries in the graph database.

The Root UCAN is self-signed. It is the genesis delegation token that proves the user controls the private keys associated with the pod. The root delegation will look like this:

For every actual request to the SDV the User Wallet creates a per-request invocation token. The invocation token is the JSON-RPC call body and references the root delegation in its prf array:

The primary security concern for the SDV is a DoS attach in which many new, fake pods are requested for non real users. While not fully avoiding this attack vector, it is possible to mitigate the impact with classical IP-based rate limiting and routine cleanup of empty vaults.

This scenario details how the Vault stores data it cannot read. We use Envelope Encryption (Hybrid Encryption): data is encrypted with a symmetric key (DEK), and that key is encrypted for the user with the public key related to their DID.

A symmetric key (e.g., ChaCha20) should be used for the actual file content. Encrypted data is wrapped into a meta structure that contains info about the encryption and about the wrapping of the decryption key. This meta structure looks like this:

The invocation token sent as the JSON-RPC body places this encrypted structure in args.payload:

To share data without revealing the user’s master key, the User Wallet performs a "Key Rewrapping" operation. It adds a new header entry encrypted for the Service Provider with whom they wish to share data. It is triggered if the user agrees to share or data with the service provider

To improve privacy, each data sharing relation between a Data Owner and a Service Provider should work with Peer DIDs. When a Data Owner and a Service Provider first initialize their 'relation', they generate new Peer DIDs derived from their Root DID. Each party generates one new DID and shares the public DID documents with the other party via other channels then the SDV (For examples through QR codes on the Service Provider onboarding website).

To avoid a range of attacks, it is important that the sharing of Peer DID documents happens through secure out-of-band channels. For example it is important to use a secure TLS communication channel to avoid well known attacks when sharing public keys (such as man-in-the-middle attacks).

For recovery purposes, we recommend a deterministic scheme to derive Peer DIDs from a Root DID, although this cannot be enforced by the SDV. A user needs to share it’s peer DIDs with the SDV such that the SDV can build aliases of a vault. Put simply, without this step, the user would leak it’s actual Root DID through the URI used for the vault. The SDV needs to be able to route JSON-RPC invocations for both the Root DID and the Peer DID as vault subjects, resolving through the Alias Registry.

The large data blob is not touched. Only the small key (DEK) is re-encrypted. The /doc/share call atomically registers the SP’s Peer DID as an alias in the vault’s Alias Registry and appends the new wrapped DEK entry to the document header. The file now has two valid headers: both the User and the Service Provider can open the envelope. Note that from the Service Provider’s point of view, they directly interact with the newly generated user’s Peer DID. This ensures they cannot link the DID they see with DIDs that another Service Provider sees when interacting with the same user. If we reflect on how this could work in practice, a Service Provider would generate a QR code on their onboarding page that contains their Peer DID and the access they request. The user wallet performs a lot of actions in the background, but in the end only one more interaction needs to happen with the Service Provider. At the end of the flow, the User Wallet calls the Service Provider back with a UCAN token that contains all the info for them to access the data on the SDV.

The Service Provider uses the UCAN and their own Private Key to read the data.

The SDV validates the UCAN chain to ensure the Service Provider is authorized. The SDV also selects the wrapped key that matches the Peer DID of the requesting Service Provider in order not to expose additional encrypted data. Decryption happens entirely on the Service Provider’s side.

The User Wallet issues a delegation token to the Service Provider. The pol field restricts which endpoints the SP may access:

The Service Provider then creates a per-request invocation token (the JSON-RPC call body) referencing this delegation in prf:

The Service Provider can also get access to a User’s data vault to write data. Writing of data can be both editing existing data items as well as creating data items. This is useful for use cases where a Service Provider produces data that actually belongs to an end user, such as a medical file of a patient. In the case of editing existing data, the encrypted data blob is fully replaced, but the DEK and it’s wrapped keys are not touched. In the case of putting new data items, the same procedure is followed with as a User creating data but immediately with two wrapped keys of the DEK.

Important to note is that the Secure Data Vault stores old versions of the same data item as well where possible. This prevents Service Providers from being able to "destroy" existing User Data. Secure Data Vault providers can themselves configure how many versions are stored or how old versions can be before getting clean up. This can be the SLA that Secure Data Vault providers can use to commercialize.

The primary difference between the Service Provider creating data on behalf of the user versus a user creating their own data is the amount of DEK wrappings. In this case the Service Provider puts the data with already two wrapped keys. It is important that the SDV validates that these two wrapped keys make sense, one of the two should be linked to the DID of the requestor and one of the two should be a known Peer DID alias of the User. Additionally, more then two wrapped keys should be forbidden, as the Service Provider is not allowed to already select certain parties to share data with. The user always needs to be involved on deciding with whom they want to share their data.

Revocation in a cryptographic system requires Key Rotation. Revoking the issued UCAN is always the first step in revocation and will already provide enough protection in almost all cases. However, to become robust against hacks or bugs on the SDV, the architecture also proposes to do a full key rotation and re-encryption to make sure the revoked Service Provider can not gain access anymore through falsely leaked ciphertexts.

A big distinction between a typical write update and a access revocation is that not only the data blob is replaced but all the wrapped key headers as well. At the same time, old versions are not kept (or should not be kept long) as this would defeat the purpose of the mitigation against accidental leaks. Even if the Service Provider kept a copy of the old encrypted blob, they cannot decrypt the new updates. If they try to access the current file on the SDV, they will fail because their key no longer works (in the rare case their UCAN would still be accepted).

For simple data items, like an address or bank account number, the re-encryption is not a performance issue and can easily happen on the device of the end user. However, when the shared data that needs to be revoked is big, like large video files, this full download, decryption, re-encryption, and upload can become expensive operations or in some cases maybe even impossible due to the constraints of the end user’s device. To solve this issue, the SDV can use Trusted Execution Environments perform the bulk of the rotation on the Secure Data Vault. In essence, the end user delegates their work to the SDV. The flow would then look like the diagram below.

The scenario discards UCAN validation for every interaction of with the SDV for brevity.

A critical part of this process is the validation of the Secure Data Vault TEE key when the user gives the decrypted DEK. The user’s device needs to validate the full chain of trust of the TEE attestation to make sure that it is not giving the decryption keys of their data to an unauthorized third party or a system administrator of the SDV provider. Different technologies exist for the Trusted Execution Environments, such as Intel SGX, Intel TDX, AMD SEV, ARM CCA, AWS Nitro Enclaves, …​ Each attestation document for these technologies is different but follows a similar approach. There is a known root of trust, such as the Intel well known public keys or AWS’s Nitro Hypervisor public keys, enclave measurements, and attested data. The root of trust is well known across any user of TEE, but in this case the enclave measurements should also be known beforehand to the End User Wallet. The enclave measurements essentially prove the code that is running in the enclave. The End User can only trust code that is open-source, validated by independent researchers, and with known enclave measurements. This avoids a SDV Provider putting backdoors in the enclaves they run on behalf of users.

This scenario occurs during the Authentication & Presentation flow. Before presenting credentials to a verifier, the Wallet must ensure its local cache is up to date with the Cloud Vault ("Source of Truth"). This is important because the user is offline or has multiple devices. An Issuer with write access might have updated a VC in the background.

The /vault/sync call is bidirectional: the Wallet uploads any pending local mutations in the same request it fetches server-side changes, using since_hash as the common reference point. The Wallet always syncs before generating a proof to ensure it isn’t using revoked credentials. If the Vault is unreachable, the Wallet defaults to the local cache, accepting the risk of staleness.

In the different scenarios, different types of UCAN permissions need to be validated. This section summarizes the full validation chain for UCAN 1.0 invocation tokens and puts extra attention on what each command entails. Each request to the SDV is a JSON-RPC call whose body is a signed invocation token. Validation proceeds as follows:

The SCAMPER Secure Data Vault (SDV) is built upon a W3C Solid implementation (e.g., Community Solid Server). It is deployed as a cloud-agnostic, containerized architecture that strictly separates metadata (LDP-RS) from raw binary files (LDP-NR). To support unlinkable identities, a custom DID resolution and UCAN authorization pipeline sits in front of the native Solid routing.

To ensure the Graph Database remains lightning-fast for blind-index queries and relation traversals, the Solid backend strictly routes data based on its mathematical footprint:

Standard web server logging (e.g., Nginx default access logs) is highly dangerous in a zero-trust architecture, as it routinely captures URIs, IPs, and identifiers. To maintain the Unlinkability requirement of the SDV, all logging must be strictly sanitized.

To ensure absolute digital sovereignty, the cryptographic boundary is strictly enforced between the Edge Wallet and the SDV.

Error responses from the Vault must be carefully designed to prevent malicious actors from mapping the Vault’s internal structure or discovering Alias routes.

The system enforces a strict bifurcation of data storage to maintain performance and privacy.

Because the Edge Wallet operates on a mobile device, network connectivity is assumed to be intermittent.

The quality tree provides a high-level overview of the system’s driving quality attributes:

These concrete scenarios translate the abstract quality attributes into highly specific, testable conditions for the engineering and QA teams.

These are systemic risks introduced by the core design choices (documented in Chapter 9: Architecture Decisions).

These are engineering compromises made to accelerate development or integrate with existing standards.