European Digital Identity Wallet — Records of Processing Activities template

Tenant-facing template for the GDPR Article 30 RoPA covering the Aloaha WebPhone European Digital Identity Wallet verifier and issuer flows. Template version 1.0, dated 2026-07-26.

LEGAL DISCLAIMER — READ FIRST. This is a template for the tenant operator’s RoPA. Aloaha does NOT provide legal advice. The tenant operator (the controller) is responsible for adapting the template to their specific processing operations, consulting their Data Protection Officer or legal counsel, keeping the RoPA current (RoPA is a living document; every material change in processing MUST be reflected), and making the RoPA available to the supervisory authority on request under GDPR Article 30(4).

Aloaha describes what the platform SHIPS and what CONTROLS it provides. Aloaha does NOT certify GDPR compliance of any tenant deployment.

Part A applies when the tenant is the controller (typically self-hosted tenants, and hosted-SaaS tenants that determine the purpose and means of identity-verification processing).

Part A — Article 30(1) Controller RoPA

A.1 Name and contact of the controller

Legal name of controller	[fill in]
Registered address	[fill in]
Company / commercial registry number	[fill in]
Contact for data-protection queries	[fill in — email + postal address]
DPO name	[fill in — or “Not appointed, Article 37 assessment on file”]
DPO contact	[fill in]
Representative in EU (if controller outside EU/EEA — Article 27)	[fill in]

A.2 Purposes of processing

The tenant operator MUST list only the purposes it actually pursues. Suggested purposes for a European Digital Identity Wallet deployment on Aloaha WebPhone:

P1 — verify a natural person’s identity via the European Digital Identity Wallet for the purpose of granting access to the tenant service (log-in)
P2 — verify a person’s age (e.g. age_over_18) via the European Digital Identity Wallet where the tenant is subject to a legal age gate
P3 — issue tenant-specific verifiable credentials to a person’s European Digital Identity Wallet (e.g. employee credential, membership credential)
P4 — record audit-trail evidence of verification / issuance events for compliance, dispute resolution, and legal-obligation retention
P5 — record billable-metric increments (per the tenant’s contract with Aloaha) to support licensing and invoicing
P6 — session security (nonce, DPoP jti replay cache, IP + UA binding) for the duration of the transaction

A.3 Categories of data subjects

End users presenting a European Digital Identity Wallet to the tenant service
Tenant operators and administrators authenticating to the Aloaha WebPhone admin panel
Relying-party administrators registered with the tenant

A.4 Categories of personal data

Purpose	Categories of personal data
P1 (log-in)	Wallet PID subset requested via DCQL — typically `given_name`, `family_name`, wallet subject identifier (`sub`), optional `email` and `birthdate`; wallet-attestation issuer reference; transaction timestamp
P2 (age gate)	Selective-disclosure boolean `age_over_NN` (preferred), or `birthdate` where boolean not available; transaction timestamp
P3 (credential issuance)	End user’s wallet public key, wallet-attestation issuer reference, claim values chosen by tenant to be attested
P4 (audit)	Timestamp, purpose, wallet type, verification result (success / fail + failure reason), wallet-attestation issuer reference, session hash
P5 (billing)	Aggregate counters keyed by metric name; no personal identifier persisted
P6 (session security)	Session ID (opaque), DPoP `jti`, nonce, IP address, User-Agent, HTTP-cookie value, transaction timestamps

NOT collected by default: wallet-holder photograph, biometric templates, special-category data, national identifier (unless the tenant explicitly requests it via DCQL).

A.5 Categories of recipients

The tenant’s own downstream relying-party application — receives the minimum claim subset the wallet released, forwarded via the tenant’s own session or API mechanism
Aloaha Limited (as processor) — where the tenant contracts Aloaha to host the deployment; scope defined in the Data Processing Agreement (DPA)
Hosting provider (Azure / MITA-Azure / self-hosted infrastructure) — as a sub-processor when applicable
Competent supervisory authority — on legally-compelled disclosure only
No advertising, marketing, or analytics recipients on wallet-flow endpoints (see logineu.html, age-verify.html — zero third-party tracking pixels)

A.6 Third-country transfers

Scenario	Transfer destination	Safeguard
Tenant self-hosts inside EU/EEA	None	N/A
Tenant self-hosts outside EU/EEA	[fill in country]	Article 46 SCCs OR Article 45 adequacy decision required
Aloaha SaaS hosted on MITA-Azure	Malta (EU)	None required (intra-EU)
Aloaha SaaS hosted on Azure region outside EU	[fill in region]	Article 46 SCCs required
External API for optional AI voice transcription (only if enabled per tenant)	Vendor infrastructure (regional)	Depends on tenant configuration; disable if not required

A.7 Retention

Aloaha WebPhone default retention windows. Tenant DPO MUST review and set per-purpose retention that satisfies the “necessary” test.

Data category	Default retention	Configurable?
Session state (`App_Data/<tenant>/sessions/`)	Session lifetime (typically minutes to a browser session)	Session lifetime, minimum
Audit logs (`App_Data/<tenant>/audit/`)	12 months rolling	Yes per tenant
Billable-metric counters (`App_Data/<tenant>/metrics/`)	24 months rolling (invoice-cycle retention)	Yes per tenant
Transaction records (verifier success / fail per session)	12 months rolling	Yes per tenant
Verified PID persisted to user record	30 days (`Oidc:PidRetentionSeconds=2592000`)	Yes per tenant; production profile refuses indefinite
IP + UA binding within session	Session lifetime	Session lifetime, minimum
DPoP `jti` replay cache	5 minutes (short-lived)	Cache TTL configurable
Server-side backup files (`.backup-*`)	5 days rolling	Yes per tenant

A.8 Technical and organisational security measures

Reference measures shipped by the Aloaha WebPhone platform. Tenant MUST verify these are enabled in the tenant’s specific configuration.

Transport security

TLS 1.2 minimum enforced; TLS 1.3 preferred
HSTS on all tenant hostnames
HttpOnly + SameSite=Lax + Secure session cookies

Cryptographic protection of wallet flows

JWE encryption of VP responses (A256GCM, ECDH-ES+A256KW) when haipStrictMode = TRUE (platform default)
HAIP-strict enforcement rejects unencrypted direct_post by default
ES256 verifier signing keys per tenant
LOTL-anchored RP-certificate chain validation (Oidc:LotlRequireChain = TRUE on production profile)
OAuth Status List draft-13 credential revocation checking (Oidc:StatusListCheckMode = enforce by default)
DPoP proof at VCI ?token and ?credential endpoints
attest_jwt_client_auth at VCI ?par and ?token

Session integrity

Same-device redirect_uri binding via signed cookie
Nonce enforcement on every OpenID4VP request
DPoP jti replay cache (5-minute TTL)

Data isolation

Per-tenant filesystem isolation via TenantPaths.*
Cross-tenant reads blocked at path-resolver layer
ACL v3 IP + SIP allow-deny gate on every entry point (IpAllowGate.Allow)
Auto-blacklist of known scanner ranges on startup

Data at rest

All tenant data under App_Data/<tenant>/ on the tenant IIS host
Atomic write with .backup sidecar for every JSON write (File.Replace)
No central Aloaha database

Observability

LOUD [TAG-DIAG] inline logs at every branch, pre-call, and post-call
RASP inline anomaly checks + integrity checks on every handler
Per-tenant /.well-known/security.txt for coordinated disclosure
UTC timestamps in every log

Access control

OIDC provider with per-tenant RS256 keys
Superuser account is a per-machine break-glass operator-only path (never exposed publicly)
Granular RBAC declared at every admin gate

Availability

30-day licensing grace period before service degradation
5-day rolling backup file window on tenant JSON stores

A.9 Records of consent (where applicable)

Where processing relies on Article 6(1)(a) consent:

Consent-capture mechanism	[fill in — e.g. wallet UI, tenant sign-up form]
Records retention for consent evidence	[fill in]
Withdrawal mechanism	[fill in — must be as easy as giving]
Consent version / text hash	[fill in]

Under the wallet flow, the primary user consent is captured inside the end user’s wallet UI, not by Aloaha WebPhone. The verifier records only that a response was accepted, plus the claim subset released.

Part B applies to Aloaha Limited when it acts as processor for a tenant (hosted-SaaS deployments where the tenant contracts Aloaha to host).

Part B — Article 30(2) Processor RoPA

B.1 Name and contact of processor and of each controller

Processor legal name	Aloaha Limited [or applicable Aloaha entity]
Registered address	[fill in]
Contact for data-protection queries	Per Aloaha’s published DPA channel
Controller	See Part A.1 above; each tenant is a separate controller
Representative in EU (if processor outside EU/EEA — Article 27)	Not applicable while Aloaha is EU-established

B.2 Categories of processing carried out on behalf of each controller

Hosting of the tenant’s Aloaha WebPhone instance (compute, storage, network)
Operation of the OID4VP verifier and OID4VCI issuer flows on the tenant’s behalf
Retention and rotation of tenant JSON state files under App_Data/<tenant>/ per the DPA
Aggregate metric emission for licensing / invoicing
Coordinated-disclosure handling via /.well-known/security.txt
Certificate acquisition and renewal (ACME / Let’s Encrypt) on the tenant’s behalf
Application of platform-wide security patches

B.3 Transfers of personal data to a third country or international organisation

MITA-Azure hosted tenants — no transfer outside EU/EEA
Azure region outside EU/EEA (only where the tenant contracts this explicitly) — Article 46 SCCs in the DPA
Sub-processors — hosting provider only; declared in the DPA; no advertising / analytics sub-processors

B.4 General description of the technical and organisational security measures

Refer to Part A.8 above. Aloaha applies the same measures across all tenants; per-tenant configuration knobs are documented in the DPA.

B.5 Data Processing Agreement (DPA)

The DPA between the controller (tenant) and Aloaha (processor) documents the specific processing, sub-processors, deletion / return of data on termination, and audit rights.
The DPA is a separate legal instrument. This RoPA references but does not reproduce the DPA.
Template placeholder: the tenant should reference the executed DPA version and date here — [fill in DPA version + date].

Part C — Change log

Date	Change	Signed
2026-07-26	Template v1.0 issued for the Aloaha WebPhone European Digital Identity Wallet product surface	Aloaha engineering

Companion documents

This template supports tenant compliance with GDPR Article 30 for the Aloaha WebPhone European Digital Identity Wallet product surface. It is not a substitute for the tenant’s own RoPA and does not create any warranty of compliance.

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