European Digital Identity Wallet — Verzeichnis der Verarbeitungstätigkeiten (Vorlage)

Mandantenseitige Vorlage für das VVT nach DSGVO Art. 30 für die European-Digital-Identity-Wallet-Verifier- und Issuer-Flüsse in Aloaha WebPhone. Vorlagenversion 1.0, Datum 2026-07-26.

RECHTLICHER HINWEIS — ZUERST LESEN. Dies ist eine Vorlage für das VVT des Tenant-Betreibers. Aloaha erbringt KEINE Rechtsberatung. Der Tenant-Betreiber (der Verantwortliche) ist verantwortlich für die Anpassung der Vorlage an die spezifischen Verarbeitungstätigkeiten, die Konsultation seines Datenschutzbeauftragten oder Rechtsberaters, die Pflege der Aktualität (VVT ist ein Living Document; jede wesentliche Änderung der Verarbeitung MUSS abgebildet werden) und die Bereitstellung des VVT gegenüber der Aufsichtsbehörde auf Anfrage nach DSGVO Art. 30 Abs. 4.

Aloaha beschreibt, was die Plattform LIEFERT und welche KONTROLLEN sie bereitstellt. Aloaha ZERTIFIZIERT keine DSGVO-Konformität einer Tenant-Deployment.

Teil A gilt, wenn der Tenant der Verantwortliche ist (typisch für Self-Hosting-Tenants und für Hosted-SaaS-Tenants, die Zwecke und Mittel der Identitätsverifikation bestimmen).

Teil A — Art. 30 Abs. 1 VVT des Verantwortlichen

A.1 Name und Kontakt des Verantwortlichen

Firmenname des Verantwortlichen	[eintragen]
Sitzadresse	[eintragen]
Handelsregister-Nummer	[eintragen]
Ansprechpartner für Datenschutzanfragen	[eintragen — E-Mail + Postanschrift]
DSB-Name	[eintragen — oder „Nicht bestellt, Art.-37-Bewertung in Akte“]
DSB-Kontakt	[eintragen]
Vertreter in der EU (falls Verantwortlicher außerhalb EU/EWR — Art. 27)	[eintragen]

A.2 Zwecke der Verarbeitung

Der Tenant-Betreiber MUSS ausschliesslich Zwecke listen, die er tatsächlich verfolgt. Vorschläge für eine European-Digital-Identity-Wallet-Deployment auf Aloaha WebPhone:

P1 — Identität einer natürlichen Person via European Digital Identity Wallet zwecks Gewährung des Zugangs zum Tenant-Dienst (Login) verifizieren
P2 — Alter einer Person (z. B. age_over_18) via European Digital Identity Wallet verifizieren, wenn der Tenant einem gesetzlichen Altersgate unterliegt
P3 — tenantspezifische verifizierbare Credentials an die European Digital Identity Wallet einer Person ausstellen (z. B. Mitarbeiter-, Mitglieds-Credential)
P4 — Audit-Trail-Nachweise für Verifikations-/Ausstellungsereignisse für Compliance, Streitbeilegung und gesetzliche Aufbewahrungsfristen
P5 — abrechnungsrelevante Metrik-Inkremente (gemäss Vertrag Tenant/Aloaha) zur Unterstützung von Lizenzierung und Rechnungsstellung
P6 — Session-Security (Nonce, DPoP-jti-Replay-Cache, IP + UA-Bindung) für die Dauer der Transaktion

A.3 Kategorien betroffener Personen

Endnutzer, die eine European Digital Identity Wallet dem Tenant-Dienst präsentieren
Tenant-Betreiber und Administratoren, die sich am Aloaha-WebPhone-Admin-Panel authentifizieren
Relying-Party-Administratoren, die beim Tenant registriert sind

A.4 Kategorien personenbezogener Daten

Zweck	Kategorien personenbezogener Daten
P1 (Login)	Via DCQL angefragte Wallet-PID-Teilmenge — typischerweise `given_name`, `family_name`, Wallet-Subject-Identifier (`sub`), optional `email` und `birthdate`; Wallet-Attestation-Issuer-Referenz; Transaktionszeitstempel
P2 (Alters-Gate)	Selective-Disclosure-Boolean `age_over_NN` (bevorzugt) oder `birthdate`, wo Boolean nicht verfügbar; Transaktionszeitstempel
P3 (Credential-Ausstellung)	Öffentlicher Wallet-Schlüssel des Endnutzers, Wallet-Attestation-Issuer-Referenz, vom Tenant gewählte Claim-Werte zur Attestierung
P4 (Audit)	Zeitstempel, Zweck, Wallet-Typ, Verifikationsergebnis (Erfolg / Fehler + Fehlergrund), Wallet-Attestation-Issuer-Referenz, Session-Hash
P5 (Abrechnung)	Aggregierte Zähler pro Metrik-Name; keine personenbezogene Kennung persistiert
P6 (Session-Security)	Session-ID (opak), DPoP-`jti`, Nonce, IP-Adresse, User-Agent, HTTP-Cookie-Wert, Transaktionszeitstempel

Standardmässig NICHT erhoben: Wallet-Halter-Porträt, biometrische Templates, Daten besonderer Kategorien, nationale Kennnummer (sofern nicht ausdrücklich vom Tenant per DCQL angefragt).

A.5 Empfängerkategorien

Die tenant-eigene nachgelagerte Relying-Party-Anwendung — erhält die vom Wallet freigegebene Minimal-Claim-Teilmenge, weitergereicht über den tenant-eigenen Session- oder API-Mechanismus
Aloaha Limited (als Auftragsverarbeiter) — wenn der Tenant Aloaha mit Hosting beauftragt; Umfang in der Auftragsverarbeitungsvereinbarung (AVV/DPA)
Hosting-Anbieter (Azure / MITA-Azure / Self-Hosting) — als Sub-Auftragsverarbeiter, wo einschlägig
Zuständige Aufsichtsbehörde — nur bei rechtlich erzwungener Offenlegung
Keine Werbe-, Marketing- oder Analytik-Empfänger auf Wallet-Flow-Endpoints (siehe logineu.html, age-verify.html — keine Drittanbieter-Tracking-Pixel)

A.6 Drittland-Übermittlungen

Szenario	Zielort	Schutzmaßnahme
Tenant Self-Hosting innerhalb EU/EWR	Keine	Entfällt
Tenant Self-Hosting außerhalb EU/EWR	[Land eintragen]	Art. 46 SCCs ODER Art. 45 Angemessenheitsentscheidung erforderlich
Aloaha SaaS gehostet auf MITA-Azure	Malta (EU)	Nicht erforderlich (innereuropäisch)
Aloaha SaaS gehostet in Azure-Region ausserhalb EU	[Region eintragen]	Art. 46 SCCs erforderlich
Externe API für optionale KI-Sprachtranskription (nur wenn pro Tenant aktiviert)	Anbieter-Infrastruktur (regional)	Hängt von der Tenant-Konfiguration ab; deaktivieren, wenn nicht benötigt

A.7 Aufbewahrung

Standard-Aufbewahrungsfenster von Aloaha WebPhone. Der Tenant-DSB MUSS prüfen und zweckbezogen so setzen, dass der Erforderlichkeitstest erfüllt ist.

Datenkategorie	Standard-Aufbewahrung	Konfigurierbar?
Session-Zustand (`App_Data/<tenant>/sessions/`)	Sitzungsdauer (typisch Minuten bis Browser-Session)	Sitzungsdauer, mindestens
Audit-Logs (`App_Data/<tenant>/audit/`)	12 Monate rollierend	Ja pro Tenant
Abrechnungsmetrik-Zähler (`App_Data/<tenant>/metrics/`)	24 Monate rollierend (Rechnungszyklus-Aufbewahrung)	Ja pro Tenant
Transaktions-Records (Verifier-Erfolg/Fehler pro Session)	12 Monate rollierend	Ja pro Tenant
Verifizierte PID persistiert im Nutzer-Datensatz	30 Tage (`Oidc:PidRetentionSeconds=2592000`)	Ja pro Tenant; Produktionsprofil verweigert unbegrenzt
IP + UA-Bindung in Session	Sitzungsdauer	Sitzungsdauer, mindestens
DPoP-`jti`-Replay-Cache	5 Minuten (kurzlebig)	Cache-TTL konfigurierbar
Server-seitige Backup-Dateien (`.backup-*`)	5 Tage rollierend	Ja pro Tenant

A.8 Technische und organisatorische Maßnahmen

Referenz-Maßnahmen der Aloaha-WebPhone-Plattform. Der Tenant MUSS prüfen, dass sie in seiner Konfiguration aktiviert sind.

Transportsicherheit

TLS 1.2 Minimum erzwungen; TLS 1.3 bevorzugt
HSTS auf allen Tenant-Hostnames
HttpOnly + SameSite=Lax + Secure Session-Cookies

Kryptographischer Schutz der Wallet-Flüsse

JWE-Verschlüsselung der VP-Antworten (A256GCM, ECDH-ES+A256KW), wenn haipStrictMode = TRUE (Plattform-Default)
HAIP-Strict-Durchsetzung lehnt unverschlüsseltes direct_post standardmässig ab
ES256-Verifier-Signaturschlüssel pro Tenant
LOTL-verankerte RP-Zertifikatsketten-Validierung (Oidc:LotlRequireChain = TRUE im Produktionsprofil)
OAuth Status List draft-13 Credential-Widerrufsprüfung (Oidc:StatusListCheckMode = enforce als Default)
DPoP-Proof an VCI ?token und ?credential
attest_jwt_client_auth an VCI ?par und ?token

Session-Integrität

Same-Device-redirect_uri-Bindung via signiertem Cookie
Nonce-Erzwingung bei jeder OpenID4VP-Anfrage
DPoP-jti-Replay-Cache (5 Minuten TTL)

Datenisolation

Mandantenlokale Dateisystem-Isolation via TenantPaths.*
Cross-Tenant-Reads werden auf Pfad-Resolver-Ebene blockiert
ACL v3 IP + SIP-Allow/Deny-Gate an jedem Einstiegspunkt (IpAllowGate.Allow)
Auto-Blacklist bekannter Scanner-Bereiche beim Start

Daten in Ruhe

Alle Tenant-Daten unter App_Data/<tenant>/ auf dem Tenant-IIS-Host
Atomic write mit .backup-Sidecar bei jedem JSON-Schreibvorgang (File.Replace)
Keine zentrale Aloaha-Datenbank

Beobachtbarkeit

LOUD [TAG-DIAG]-Inline-Logs an jedem Branch, Pre-Call und Post-Call
RASP-Inline-Anomalie-Checks + Integritätsprüfungen auf jedem Handler
Per-Tenant-/.well-known/security.txt für Coordinated Disclosure
UTC-Zeitstempel in jedem Log

Zugriffskontrolle

OIDC-Provider mit Per-Tenant-RS256-Schlüsseln
Superuser-Konto ist ein Per-Machine-Break-Glass-Pfad für Betreiber (nie öffentlich exponiert)
Granulare RBAC an jedem Admin-Gate deklariert

Verfügbarkeit

30-Tage-Lizenz-Grace-Period vor Service-Degradation
5-Tage rollierendes Backup-Datei-Fenster auf Tenant-JSON-Stores

A.9 Einwilligungsnachweise (wo einschlägig)

Wo die Verarbeitung auf Art. 6 Abs. 1 lit. a Einwilligung beruht:

Einwilligungsmechanismus	[eintragen — z. B. Wallet-UI, Tenant-Anmeldeformular]
Aufbewahrungsdauer für Einwilligungsnachweise	[eintragen]
Widerrufsmechanismus	[eintragen — muss so einfach sein wie die Erteilung]
Einwilligungsversion / Text-Hash	[eintragen]

Im Wallet-Fluss wird die primäre Nutzereinwilligung in der Wallet-UI des Endnutzers erfasst, nicht durch Aloaha WebPhone. Der Verifier vermerkt lediglich, dass eine Antwort akzeptiert wurde, sowie die freigegebene Claim-Teilmenge.

Teil B gilt für Aloaha Limited, wenn sie für einen Tenant als Auftragsverarbeiter tätig wird (Hosted-SaaS-Deployments, in denen der Tenant Aloaha mit Hosting beauftragt).

Teil B — Art. 30 Abs. 2 VVT des Auftragsverarbeiters

B.1 Name und Kontakt des Auftragsverarbeiters und jedes Verantwortlichen

Firmenname Auftragsverarbeiter	Aloaha Limited [oder anwendbare Aloaha-Entität]
Sitzadresse	[eintragen]
Ansprechpartner für Datenschutzanfragen	Über den veröffentlichten DPA-Kanal von Aloaha
Verantwortlicher	Siehe Teil A.1 oben; jeder Tenant ist ein eigener Verantwortlicher
Vertreter in der EU (falls Auftragsverarbeiter ausserhalb EU/EWR — Art. 27)	Entfällt, solange Aloaha in der EU niedergelassen ist

B.2 Kategorien der Verarbeitung im Auftrag jedes Verantwortlichen

Hosting der Tenant-Aloaha-WebPhone-Instanz (Rechenleistung, Speicher, Netzwerk)
Betrieb der OID4VP-Verifier- und OID4VCI-Issuer-Flüsse im Namen des Tenants
Aufbewahrung und Rotation der Tenant-JSON-Zustandsdateien unter App_Data/<tenant>/ gemäss DPA
Aggregierte Metrik-Emission zwecks Lizenzierung / Rechnungsstellung
Coordinated-Disclosure-Bearbeitung via /.well-known/security.txt
Zertifikatserwerb und -verlängerung (ACME / Let’s Encrypt) im Namen des Tenants
Ausrollen plattformweiter Sicherheits-Patches

B.3 Uebermittlungen personenbezogener Daten an Drittland oder internationale Organisation

MITA-Azure-gehostete Tenants — keine Uebermittlung ausserhalb EU/EWR
Azure-Region ausserhalb EU/EWR (nur wenn vom Tenant explizit kontrahiert) — Art. 46 SCCs im DPA
Sub-Auftragsverarbeiter — nur Hosting-Provider; im DPA deklariert; keine Werbe-/Analytik-Sub-Auftragsverarbeiter

B.4 Allgemeine Beschreibung der TOMs

Siehe Teil A.8 oben. Aloaha wendet dieselben Maßnahmen über alle Tenants an; per-Tenant-Konfigurationsschrauben sind im DPA dokumentiert.

B.5 Auftragsverarbeitungsvereinbarung (DPA/AVV)

Die AVV zwischen Verantwortlichem (Tenant) und Aloaha (Auftragsverarbeiter) dokumentiert die konkrete Verarbeitung, Sub-Auftragsverarbeiter, Löschung/Rückgabe von Daten bei Beendigung und Audit-Rechte.
Die AVV ist ein eigenständiges Rechtsinstrument. Dieses VVT verweist, reproduziert die AVV jedoch nicht.
Vorlagen-Platzhalter: der Tenant sollte hier die ausgeführte AVV-Version und Datum referenzieren — [eintragen AVV-Version + Datum].

Teil C — Änderungshistorie

Datum	Änderung	Freigegeben
2026-07-26	Vorlage v1.0 ausgestellt für die Aloaha-WebPhone-European-Digital-Identity-Wallet-Produktfläche	Aloaha Engineering

Begleitdokumente

Diese Vorlage unterstützt die Tenant-Compliance zu DSGVO Art. 30 für die European-Digital-Identity-Wallet-Fläche von Aloaha WebPhone. Sie ersetzt nicht das eigene VVT des Tenants und begründet keinerlei Gewährleistung der Konformität.

Letzte Aktualisierung 2026-07-26. Zugehörige Seiten: Datenschutz-Manifest · DSFA-Vorlage · HAIP-Betreiber-Setup · English