Skip to main content

The ephemeral data model

The Truvity EUDIW Connector uses an ephemeral data model as a security architecture choice that minimizes the attack surface for sensitive identity data. Credential data is processed in memory during verification, delivered to your callback, and then permanently deleted. No user attributes persist in the connector.

Why ephemeral​

Identity verification involves sensitive personal data such as Personal Identification Data (PID). Storing this data creates risk: the longer it persists, the larger the potential impact of a breach. The ephemeral model eliminates this risk by ensuring credential data exists in the connector only for the duration of a single verification flow.

This design also aligns with the ARF's unlinkability requirements. The ARF expects Relying Parties to discard unique fixed elements from attestations—such as hash values, salts, public keys, and signatures—as soon as they are no longer needed, to prevent cross-transaction tracking. The connector's automatic deletion after callback delivery satisfies this expectation by design.

The ephemeral model simplifies your compliance posture. Because the connector does not retain user data, it reduces the scope of GDPR obligations and security audits related to the verification infrastructure.

User approval is not GDPR consent

User approval to present attributes from a Wallet Unit does not constitute lawful grounds for data processing under GDPR. You must independently ensure a lawful basis under GDPR Article 6 for processing the personal data you receive through the connector. See Compliance and regulations for more context.

How the model works​

The ephemeral model relies on single-use cryptographic keys and strict lifecycle management.

Key generation​

When you create a presentation request, the connector generates a unique encryption key pair for that request. The public key is included in the authorization request sent to the wallet. The private key is stored temporarily with the session and used only once to decrypt the wallet's response.

In-memory processing​

When the EUDI Wallet submits a presentation response:

  1. The connector retrieves the session's private key.
  2. The connector decrypts the wallet's response into memory.
  3. Verification (signature checks, trust chain validation, selective disclosure) occurs entirely in memory.

Deletion after delivery​

After the connector delivers the verification result to your callback:

  • The presentation request session is deleted.
  • The ephemeral encryption keys are deleted.
  • All user attributes and credential data is cleared from memory.

Session lifecycle​

The following diagram illustrates the data lifecycle during a verification flow:

Automatic session cleanup​

Sessions that are not completed (for example, the user never responds or the wallet times out) are automatically cleaned up. The connector deletes expired sessions and their associated keys on a regular schedule, ensuring that incomplete flows do not leave data behind.

Connector as a Relying Party Instance​

The ARF distinguishes between a Relying Party Instance and an intermediary. A Relying Party Instance is a combination of hardware and software that a Relying Party uses to interact with Wallet Units—it is the RP's own technical system. An intermediary is a separate party that offers services to Relying Parties, connecting to Wallet Units on their behalf and forwarding the presented attributes.

When you deploy the connector, it operates as your Relying Party Instance. The ephemeral data model is a security architecture choice that minimizes the attack surface for identity data, not a legal obligation imposed by the intermediary data storage restriction in Article 5b(10) of eIDAS 2.0.

An organization qualifies as an intermediary when it (a) offers services to other Relying Parties, (b) connects to Wallet Units on their behalf, (c) requests User attributes that those Relying Parties need, and (d) forwards the presented attributes to the intermediated Relying Party. Article 5b(10) requires that intermediaries are deemed to be Relying Parties and must not store data about the content of the transaction. If you deploy the connector within your own infrastructure and interact with Wallet Units directly, you are operating as a Relying Party—not as an intermediary.

Integration considerations​

Push-only delivery​

Because data is deleted after delivery, you cannot retrieve verification results later from the connector. You must implement a callback endpoint to receive results at the time of verification.

Callback reliability​

Callback delivery is synchronous with the wallet response. The connector delivers the callback and waits for a result before responding to the wallet. The connector retries on network errors and server errors (HTTP 5xx) but does not retry on client errors (HTTP 4xx). If your callback endpoint is unreachable after all retry attempts, the verification data is lost and the wallet receives an error response. Ensure your callback infrastructure is highly available and responds quickly.

GDPR data erasure scope​

The ARF enables Users to request data deletion from Relying Parties through their Wallet Unit dashboard, in accordance with GDPR Article 17. Because the connector does not retain user data after callback delivery, these erasure requests apply only to data stored in your own systems after receiving the callback, not to the connector itself.

Further reading​