European Digital Identity Wallet — Data Protection Impact Assessment template

Tenant-facing DPIA template covering the Aloaha WebPhone European Digital Identity Wallet product surface — OpenID4VP verifier, OpenID4VCI issuer, SIOPv2, HAIP 1.0 profile. Template version 1.0, dated 2026-07-26.

1. Overview

1.1 What processing does this DPIA cover?

Presentation and verification of European Digital Identity Wallet credentials to authenticate a natural person and, where applicable, issuance of verifiable credentials to the same person. Specifically:

• OID4VP verifier flow. The tenant Aloaha WebPhone deployment acts as an OpenID4VP verifier / relying party. It requests one or more claims from the end-user’s European Digital Identity Wallet under the HAIP 1.0 profile (SD-JWT VC + KB-JWT, optional mDoc where the tenant has enabled the ISO 18013-7 pipeline).
• OID4VCI issuer flow. The tenant deployment acts as a credential issuer under OpenID4VCI, issuing tenant-specific attestations (e.g. employee-authorisation credentials, membership credentials) to a user’s European Digital Identity Wallet.
• Session state. The verifier / issuer stores short-lived state to bind the OpenID4VP request to the presented response and to prevent replay (nonce, redirect_uri, DPoP jti, wallet-attestation iat).
• Audit and billing metrics. Success / failure counters, timestamps, wallet type, and licensable-metric increments are logged to per-tenant files under App_Data/<tenant>/.

1.2 Why is a DPIA required?

DPIA is mandatory under GDPR Article 35(1) when the processing is likely to result in a high risk to the rights and freedoms of natural persons. The European Data Protection Board’s WP248 rev.01 lists nine criteria; wallet identity flows meet at least four:

• Evaluation or scoring of data subjects (age, eligibility, entitlement)
• Systematic monitoring in some tenant configurations (audit trail)
• Data processed on a large scale for public-facing tenants
• Innovative use of technology (European Digital Identity Wallet, ARF-conformant flows are new market entrants as of 2026)

Regardless of scale, several Member State supervisory authorities have listed “processing of official identifiers” and “biometric or unique identification” on their Article 35(4) mandatory-DPIA lists. Wallet PID falls under both.

1.3 Assessment date and DPO consultation

2. Data flows (textual diagram)

+----------------+     openid4vp:// authz request      +-------------------+
|   End user +   | -----------------------------------> |  Aloaha WebPhone  |
|  European      |                                      |    (Verifier)     |
|  Digital       | <----------- direct_post JWE ------- |  logineu.ashx     |
|  Identity      |                                      |  age-verify.ashx  |
|  Wallet        |                                      +-------------------+
+----------------+                                                |
       ^                                                          v
       |                                                +-------------------+
       |  OID4VCI credential offer (optional issuance)  |  Downstream RP    |
       +----------------------------------------------- |  (tenant's own    |
                                                        |   application)    |
                                                        +-------------------+

Local persistence:
    App_Data/<tenant>/sessions/<sid>.json    (short-lived — session only)
    App_Data/<tenant>/audit/<yyyy-mm>.log    (retention per tenant policy)
    App_Data/<tenant>/metrics/<meter>.jsonl  (licensable metrics)

Key properties:

• Wallet-first control. The end user’s European Digital Identity Wallet releases claims only after explicit consent inside the wallet UI. The verifier cannot pull data without a user-approved OpenID4VP response.
• Encrypted VP responses. With haipStrictMode = true (platform default), the verifier rejects unencrypted direct_post and accepts only JWE-encrypted VP responses (A256GCM, ECDH-ES+A256KW).
• No shadow copy. All tenant data lives under App_Data/<tenant>/ on the tenant’s own IIS host filesystem. There is no central Aloaha database; if the tenant self-hosts, no data leaves the tenant infrastructure.
• Per-tenant isolation. Cross-tenant reads are blocked at the tenant path resolver (TenantPaths.*), enforced at every entry point.

3. Necessity and proportionality

3.1 Legal basis (GDPR Article 6)

The tenant operator selects the basis appropriate to the processing:

3.2 Legal basis for special categories (GDPR Article 9)

Wallet PID typically contains: given_name, family_name, birthdate, issuing-authority reference, wallet trust framework, and — where the tenant requests — nationality, place of birth, or address. These are not special-category data. HOWEVER:

• If the tenant requests a health credential, disability status, religious affiliation, or trade-union membership, Article 9(2) applies. Under HAIP and OID4VP the user releases only requested claims (dcql_query), so the tenant MUST minimise its request to what is strictly necessary.
• Biometric data (e.g. remote face-matching against a wallet portrait) is Article 9 unless a Member State exemption applies.

3.3 Purpose limitation

Claims received via OID4VP MUST NOT be reused for a different purpose than the one the user consented to in the wallet UI. The wallet-side consent screen states the purpose; the tenant deployment MUST NOT log or ingest claims beyond that purpose.

3.4 Data minimisation

The tenant deployment SHOULD:

• request the smallest possible claim set (SD-JWT selective disclosure — ask for over_18 rather than birthdate where available),
• use age_over_NN boolean claims where possible for age gates,
• avoid persisting the raw VP response — extract only the required disclosure and drop the rest,
• avoid logging the full JWS / JWE payload; log only claim names and outcome flags.

3.5 Necessity of the wallet flow itself

Compared to alternatives (bank ID, national eID, self-declared birthdate, photo of a physical ID document), the European Digital Identity Wallet provides: (a) cryptographic proof of issuer, (b) user consent per transaction, (c) selective disclosure, (d) revocation checking via OAuth Status List draft-13. The wallet flow is generally MORE data-minimising than its alternatives and is therefore the preferred mechanism where available.

4. Risks to data subjects

5. Mitigations shipped by the Aloaha WebPhone platform

The following are ENABLED in the current build (post-2026-07-26 HAIP-closure sprint). Tenants inherit them by default.

6. Residual risk

After the mitigations in §5, the following risks are NOT fully addressed and the tenant MUST decide whether to accept, transfer, or add compensating controls:

7. DPO consultation record

8. Sign-off

9. Change log

10. Companion documents

• Records of Processing Activities (RoPA) template — GDPR Article 30
• CodeB privacy manifesto
• HAIP verifier operator setup runbook
• HAIP 1.0 OID4VP Verifier conformance self-test
• EU Wallet Verifier API reference

Last updated 2026-07-26. Related pages: Privacy manifesto · RoPA template · HAIP operator setup · Deutsch