European Digital Identity Wallet — Datenschutz-Folgenabschätzung (Vorlage)

Mandantenseitige DSFA-Vorlage für die European-Digital-Identity-Wallet-Fläche von Aloaha WebPhone — OpenID4VP-Verifier, OpenID4VCI-Issuer, SIOPv2, HAIP-1.0-Profil. Vorlagenversion 1.0, Datum 2026-07-26.

RECHTLICHER HINWEIS — ZUERST LESEN. Dies ist eine Vorlage für die DSFA 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 Risikobewertung gegenüber der spezifischen Betroffenengruppe und dem mitgliedstaatlichen Rechtsrahmen, die Freigabe der DSFA und — wo ein hohes Restrisiko verbleibt — die Konsultation der zuständigen Aufsichtsbehörde nach DSGVO Art. 36 Abs. 1, sowie die Aufbewahrung der DSFA zur Vorlage bei der Aufsichtsbehörde.

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

1. Überblick

1.1 Welche Verarbeitung deckt diese DSFA ab?

Vorlage und Verifikation von European-Digital-Identity-Wallet-Credentials zur Authentifizierung einer natürlichen Person sowie — wo anwendbar — Ausstellung verifizierbarer Credentials an dieselbe Person. Konkret:

OID4VP-Verifier-Fluss. Die Tenant-Aloaha-WebPhone-Deployment agiert als OpenID4VP-Verifier / Relying Party. Sie fordert einen oder mehrere Claims aus der European Digital Identity Wallet des Endnutzers unter dem HAIP-1.0-Profil an (SD-JWT VC + KB-JWT, optional mDoc, wenn der Tenant die ISO-18013-7-Pipeline aktiviert hat).
OID4VCI-Issuer-Fluss. Die Tenant-Deployment agiert als Credential-Issuer unter OpenID4VCI und stellt tenantspezifische Attestierungen aus (z. B. Mitarbeiter-Berechtigungs-Credentials, Mitglieds-Credentials).
Sitzungszustand. Der Verifier / Issuer speichert kurzlebige Zustandsdaten zur Bindung der OpenID4VP-Anfrage an die präsentierte Antwort und zur Wiederholungsabwehr (Nonce, redirect_uri, DPoP jti, Wallet-Attestation iat).
Audit- und Abrechnungsmetriken. Erfolgs-/Fehlerzähler, Zeitstempel, Wallet-Typ und lizenzpflichtige Metriken werden in mandantenlokale Dateien unter App_Data/<tenant>/ geschrieben.

1.2 Warum ist eine DSFA erforderlich?

Nach DSGVO Art. 35 Abs. 1 ist eine DSFA verpflichtend, wenn die Verarbeitung wahrscheinlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat. Das EDPB-WP248 rev.01 nennt neun Kriterien; Wallet-Identitätsflüsse erfüllen mindestens vier:

Bewertung oder Einstufung von Betroffenen (Alter, Berechtigung, Anspruch)
Systematische Überwachung in bestimmten Tenant-Konfigurationen (Audit-Trail)
Verarbeitung in großem Umfang bei öffentlich zugänglichen Tenants
Innovative Nutzung von Technologie (European Digital Identity Wallet, ARF-konforme Flüsse sind ab 2026 neue Marktteilnehmer)

Unabhängig vom Umfang haben mehrere mitgliedstaatliche Aufsichtsbehörden „Verarbeitung amtlicher Kennungen“ und „biometrische oder eindeutige Identifikation“ auf ihren DSFA-Pflichtlisten nach Art. 35 Abs. 4. Wallet-PID fällt unter beides.

1.3 Bewertungsdatum und DSB-Konsultation

Tenant-Betreiber	[eintragen]
Bewertungsdatum	[eintragen]
DSB-Name und Kontakt	[eintragen]
DSB konsultiert am	[eintragen]
Prüfer	[eintragen]
Version	1.0
Nächste Prüfung fällig	[eintragen — spätestens 12 Monate, oder bei jeder wesentlichen Änderung der Verarbeitung]

2. Datenflüsse (textuelles Diagramm)

+----------------+     openid4vp:// authz request      +-------------------+
|   Endnutzer +  | -----------------------------------> |  Aloaha WebPhone  |
|  European      |                                      |    (Verifier)     |
|  Digital       | <----------- direct_post JWE ------- |  logineu.ashx     |
|  Identity      |                                      |  age-verify.ashx  |
|  Wallet        |                                      +-------------------+
+----------------+                                                |
       ^                                                          v
       |                                                +-------------------+
       |  OID4VCI Credential-Angebot (opt. Issuance)    |  Nachgelagerte RP |
       +----------------------------------------------- |  (tenant-eigene   |
                                                        |   Anwendung)      |
                                                        +-------------------+

Lokale Persistenz:
    App_Data/<tenant>/sessions/<sid>.json    (kurzlebig — nur Sitzung)
    App_Data/<tenant>/audit/<yyyy-mm>.log    (Aufbewahrung je Tenant-Policy)
    App_Data/<tenant>/metrics/<meter>.jsonl  (lizenzpflichtige Metriken)

Schlüsseleigenschaften:

Wallet-First-Kontrolle. Die European Digital Identity Wallet des Endnutzers gibt Claims nur nach ausdrücklicher Einwilligung in der Wallet-UI frei. Der Verifier kann keine Daten ohne benutzer-genehmigte OpenID4VP-Antwort abrufen.
Verschlüsselte VP-Antworten. Mit haipStrictMode = true (Plattform-Standard) lehnt der Verifier unverschlüsseltes direct_post ab und akzeptiert nur JWE-verschlüsselte VP-Antworten (A256GCM, ECDH-ES+A256KW).
Keine Schatten-Kopie. Alle Tenant-Daten liegen unter App_Data/<tenant>/ auf dem tenant-eigenen IIS-Host-Dateisystem. Es gibt keine zentrale Aloaha-Datenbank; bei Self-Hosting verlassen keine Daten die Tenant-Infrastruktur.
Mandantenisolation. Cross-Tenant-Reads werden am Tenant-Pfad-Resolver (TenantPaths.*) blockiert und an jedem Einstiegspunkt erzwungen.

3. Erforderlichkeit und Verhältnismässigkeit

3.1 Rechtsgrundlage (DSGVO Art. 6)

Der Tenant-Betreiber wählt die zur Verarbeitung passende Grundlage:

Anwendungsfall	Empfohlene Art.-6-Grundlage	Anmerkungen
Login zum Tenant-Dienst mit European Digital Identity Wallet	Art. 6 Abs. 1 lit. b — Vertragserfüllung	Nutzer fordert Dienst an; Login ist zur Bereitstellung erforderlich
Altersprüfung für regulierten Tenant-Dienst	Art. 6 Abs. 1 lit. c — rechtliche Verpflichtung	Wo mitgliedstaatliches Recht Altersgate vorschreibt (z. B. Glücksspiel, Alkohol, Erwachseneninhalte)
Ad-hoc-Credential-Ausstellung (Mitarbeiter-Credential)	Art. 6 Abs. 1 lit. f — berechtigtes Interesse	Abwägungsprüfung erforderlich
Optionale Analytik / Marketing-Attribution	Art. 6 Abs. 1 lit. a — Einwilligung	Muss freiwillig, spezifisch, informiert, unmissverständlich und widerrufbar sein

3.2 Rechtsgrundlage für besondere Kategorien (DSGVO Art. 9)

Wallet-PID enthält typischerweise: given_name, family_name, birthdate, Referenz der ausstellenden Behörde, Wallet-Trust-Rahmen sowie — auf Anforderung des Tenants — Nationalität, Geburtsort oder Adresse. Das sind keine Daten besonderer Kategorien. DENNOCH:

Fordert der Tenant ein Gesundheits-Credential, Behinderungsstatus, religiöse Zugehörigkeit oder Gewerkschaftsmitgliedschaft an, gilt Art. 9 Abs. 2. Unter HAIP und OID4VP gibt der Nutzer nur angeforderte Claims frei (dcql_query); der Tenant MUSS seine Anforderung auf das strikt Notwendige minimieren.
Biometrische Daten (z. B. Remote-Gesichtsvergleich gegen ein Wallet-Porträt) fallen unter Art. 9, sofern keine mitgliedstaatliche Ausnahme greift.

3.3 Zweckbindung

Über OID4VP empfangene Claims DÜRFEN NICHT für einen anderen Zweck als denjenigen wiederverwendet werden, dem der Nutzer in der Wallet-UI zugestimmt hat. Der wallet-seitige Consent-Screen benennt den Zweck; die Tenant-Deployment DARF Claims nicht über diesen Zweck hinaus protokollieren oder aufnehmen.

3.4 Datenminimierung

Die Tenant-Deployment SOLLTE:

die kleinstmögliche Claim-Menge anfragen (SD-JWT-Selective-Disclosure — wo verfügbar over_18 statt birthdate),
Boolean-Claims wie age_over_NN für Alters-Gates nutzen, wo möglich,
die rohe VP-Antwort nicht persistieren — nur die erforderliche Disclosure extrahieren, den Rest verwerfen,
nicht den gesamten JWS-/JWE-Payload loggen; nur Claim-Namen und Ergebnis-Flags.

3.5 Erforderlichkeit des Wallet-Flusses selbst

Verglichen mit Alternativen (Bank-ID, nationaler eID, selbsterklärtes Geburtsdatum, Foto eines physischen Ausweises) liefert die European Digital Identity Wallet: (a) kryptographischen Ausstellerbeweis, (b) benutzergesteuerte Einwilligung pro Transaktion, (c) Selective Disclosure, (d) Widerrufsprüfung über OAuth Status List draft-13. Der Wallet-Fluss ist in der Regel MEHR datenminimierend als seine Alternativen und daher das bevorzugte Verfahren, wo verfügbar.

4. Risiken für Betroffene

#	Risiko	Wahrscheinlichkeit	Schwere	Begründung
R1	Identitätsdiebstahl durch gestohlene oder wiedereingespielte Wallet-Antwort	Niedrig	Hoch	HAIP-Nonce + `same-device`-Bindung + DPoP `jti` reduzieren die Wahrscheinlichkeit
R2	Unnötige Claim-Freigabe („Überanfrage“)	Mittel	Mittel	Abhängig von der Tenant-Anforderung; wallet-seitig durch Consent-UI durchgesetzt
R3	Verknüpfbarkeit über Relying Parties hinweg via Wallet-Identifier	Niedrig-Mittel	Mittel	Hängt vom Wallet-Design ab (Batch-Ausstellung, unverknüpfbare Credentials); außerhalb unserer Kontrolle
R4	Profilbildung aus Audit-Logs	Niedrig	Mittel	Audit-Logs bleiben mandantenlokal; nicht durch Aloaha aggregiert
R5	Unautorisierte RP-Registrierung (Angreifer stellt gefälschte RP auf)	Niedrig	Hoch	LOTL-verankertes RP-Cert-Chain-Walk (`Oidc:LotlRequireChain=true` Default), OAuth-Status-List-Widerruf
R6	Credential-Wiedereinspielung gegen mehrere RPs	Niedrig	Hoch	Pro-Transaktion-Nonce, DPoP-Proof, Same-Device-`redirect_uri`-Bindung
R7	Fehler bei der Widerrufsprüfung (Nutzung eines widerrufenen Credentials)	Niedrig	Mittel	OAuth-Status-List-Client fragt Issuer ab, Cache-TTL
R8	Session-Hijack durch Cookie-Diebstahl	Niedrig	Hoch	HttpOnly + SameSite=Lax + Secure Session-Cookies, Same-Device-Bindung
R9	Cross-Tenant-Datenleck	Sehr niedrig	Hoch	`TenantPaths.*` an jedem Einstiegspunkt durchgesetzt; ACL v3 SIP-Gate
R10	Drittland-Übermittlung außerhalb der EU	Hängt vom Hosting ab	Hoch	Self-Hosted-Tenant → Tenant-Entscheidung; MITA-Azure-gehostet → EU
R11	Barrierefreiheits-Lücke, die Wallet-Login für Menschen mit Behinderung blockiert	Mittel	Hoch	Siehe WCAG-Audit 2026-07-26; verbleibende `<nav>`-Landmark-Lücke + Farbkontrast unbestätigt
R12	Überlange Aufbewahrung (Audit-Logs jenseits der Erforderlichkeit)	Niedrig	Mittel	Pro Tenant konfigurierbar; Default 12 Monate
R13	Vertraulichkeitsverlust in der Übertragung	Sehr niedrig	Hoch	TLS 1.2+ vorgeschrieben, TLS 1.3 bevorzugt; JWE-Verschlüsselung der VP-Antwort
R14	Integritätsverlust des Session-Zustands auf Platte	Niedrig	Mittel	File.Replace atomic write; `.backup`-Sidecars für Rollback
R15	Kognitive Überlastung beim Wallet-Consent (außerhalb Plattformverantwortung)	Hängt vom Wallet ab	Niedrig	Wallet-Verantwortung; Plattform sendet klaren `purpose`

5. Maßnahmen der Aloaha-WebPhone-Plattform

Die folgenden Maßnahmen sind im aktuellen Build (post-2026-07-26 HAIP-Closure-Sprint) AKTIVIERT. Tenants erben sie standardmässig.

Maßnahme	Wo	Standard
JWE-Verschlüsselung der VP-Antworten (A256GCM, ECDH-ES+A256KW)	Verifier	AN wenn HAIP strict = TRUE
HAIP-Strict-Durchsetzung (lehnt plain `direct_post` ab)	Verifier	`haipStrictMode = TRUE` pro Tenant
OAuth Status List (draft-13) Credential-Status-Client	StatusListClient	`Oidc:StatusListCheckMode=enforce`
Same-Device-`redirect_uri`-Bindung via signiertem Session-Cookie	Verifier	Erzwungen
LOTL-verankertes RP-Cert-Chain-Walk	`oidc.ashx`	`Oidc:LotlRequireChain = TRUE` (Produktionsprofil-Lock)
DPoP an VCI `?token` + `?credential`	`vci.ashx`	`Vci:DpopMode`
`attest_jwt_client_auth` an VCI `?par` + `?token`	`vci.ashx`	`Vci:ClientAuthMode`
DCQL-Query mit `trusted_authorities` + AKI-Matching	Verifier	Erzwungen wenn konfiguriert
Mandantenisolation	`TenantPaths.*`	Global erzwungen
ACL v3 SIP + IP-Allow/Deny-Gate	`IpAllowGate.Allow`	An jedem Einstiegspunkt erzwungen
Sitzungsgebundene Speicherung (kein langlebiges Credential-Caching)	`App_Data/<tenant>/sessions/`	Nur Sitzungsdauer
HttpOnly + SameSite=Lax + Secure Cookies	Alle authentifizierten Endpunkte	Erzwungen
Atomic write + `.backup`-Sidecar	Jeder JSON-Schreibvorgang	Erzwungen
LOUD `[TAG-DIAG]`-Audit-Logging	Jeder Einstiegspunkt	Erzwungen
RASP-Inline-Anomalie-Checks	Jeder neue Handler	Erzwungen
Runtime-IP-Auto-Blacklist (bekannter Scanner-Bereich)	ACL-Startup	Erzwungen
TLS 1.2+ / TLS 1.3-Durchsetzung	web.config + IIS-Binding	Erzwungen
Per-Tenant-`/.well-known/security.txt`	Tenant-JSON	Optional pro Tenant
OpenID Federation 1.0 Discovery	`.well-known/openid-federation`	Verfügbar
Keine Drittanbieter-Analytik auf Wallet-Seiten	`logineu.html`, `age-verify.html`	Keine Tracking-Pixel

6. Restrisiko

Nach den Maßnahmen in §5 sind die folgenden Risiken NICHT vollständig adressiert; der Tenant muss entscheiden, ob er sie akzeptiert, transferiert oder kompensierende Kontrollen ergänzt:

#	Restrisiko	Vorgeschlagene Maßnahme
RR1	Barrierefreiheits-Lücken (Farbkontrast, Focus-Ring, AT-Walkthrough unbestätigt gemäss WCAG-Audit 2026-07-26 §5)	Browser-getriebenen Audit + manuellen AT-Durchlauf vor Public-Launch abschliessen
RR2	DPoP-`jti`-Replay-Cache ist prozesslokal, nicht verteilt — Angreifer-Replay über Worker-Neustarts theoretisch aber nicht null	Für Hochverfügbarkeits-Tenants Redis-basierten Replay-Cache erwägen; der ausgelieferte dateibasierte Cache reicht für Single-Node
RR3	Wallet-seitige Verknüpfbarkeit über RPs hängt vom Wallet-Design ab (Batch-Credential-Re-Issuance) — ausserhalb der Plattformkontrolle	Endnutzer aufklären; Wallets bevorzugen, die Batch-Ausstellung implementieren
RR4	Grenzüberschreitende Uebermittlung, wenn der Tenant ausserhalb EU/EWR hostet	Art.-46-Bewertung durchführen; SCCs oder eine Art.-45-Angemessenheitsentscheidung nutzen
RR5	Aufbewahrungspolicy unter-konfiguriert — 12 Monate Default für Audit-Logs kann den Erforderlichkeitstest bei manchen Tenants überschreiten	Tenant-DSB setzt Aufbewahrung pro Zweck
RR6	Löschrecht (Art. 17) teilweise manuell — der ARF-TS7-Endpoint nimmt Anträge an, aber der Backoffice-Workflow ist operator-definiert	DSB-Kanal in per-Tenant-security.txt veröffentlichen
RR7	KI-Verordnungs-Pflichten, wenn der Tenant Wallet-Claims in automatisierte Entscheidungsfindung einspeist	Tenant bewertet KI-Verordnungs-Stufe separat

7. DSB-Konsultations-Nachweis

DSB-Name	[eintragen]
DSB konsultiert (Datum)	[eintragen]
DSB-Votum	[eintragen — akzeptieren / akzeptieren mit Auflagen / ablehnen]
Auferlegte Auflagen	[eintragen]
Art. 36 Vorabkonsultation ausgelöst?	[eintragen Ja/Nein — erforderlich bei hohem Restrisiko ohne Minderung]
Konsultation Betroffener / Vertreter (Art. 35 Abs. 9)?	[eintragen — beschreiben, wie die Sichten der Betroffenen ggf. eingeholt wurden]

8. Freigabe

Rolle	Name	Unterschrift	Datum
Verantwortlicher / Tenant-Betreiber
DSB
Prüfer
Nächstes Prüfdatum

9. Änderungshistorie

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

10. Begleitdokumente

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

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