WUA erklärt: wie sich eine Wallet gegenüber einem Aussteller ausweist
Eine Wallet Unit Attestation, WUA, ist das, was eine EUDI Wallet einem PID Provider oder Attestation Provider bei der Ausstellung vorzeigt, um zu beweisen, dass sie echt ist. Sie ist nicht ein Dokument, sondern zwei, beide vom Wallet-Anbieter signiert: eine Wallet Instance Attestation (WIA) über die Wallet-App und eine Key Attestation (KA) über die sichere Speicherung der Schlüssel, an die ein Credential gebunden wird.
Das Problem, das eine WUA löst
Ein Aussteller, der einer Wallet eine PID oder ein Handelsregister-Credential übergeben will, hat keine eingebaute Möglichkeit, eine zertifizierte EUDI Wallet von einer manipulierten App oder einem Skript zu unterscheiden, das einen Autorisierungsablauf wiederholt. Ebenso wenig sieht er, ob der Schlüssel, an den das Credential gebunden wird, in zertifizierter sicherer Hardware liegt oder in gewöhnlichem Speicher, aus dem er kopiert werden könnte.
Die WUA schließt beide Lücken. Der Wallet-Anbieter bürgt mit der WIA für die App und mit der Key Attestation für die Schlüsselspeicherung. Der Aussteller prüft beide vor der Ausstellung und prüft ihren Widerrufsstatus auch danach weiter, sodass er Ausgestelltes widerrufen kann, wenn sich später herausstellt, dass die Wallet oder ihre Schlüsselspeicherung kompromittiert ist.
Eine WUA wird nur bei der Ausstellung verwendet. Das ARF verbietet einer Wallet-Einheit, eine WIA oder Key Attestation einer Relying Party vorzulegen, wodurch Wallet-Details aus jeder Vorlage herausgehalten werden.
Die Akteure und wer wem vertraut
Fünf Rollen sind beteiligt, und nur vier davon haben jemals mit einer WUA zu tun. Das WSCD (Wallet Secure Cryptographic Device) oder ein Keystore erzeugt und bewacht die Schlüssel, der Wallet-Anbieter bürgt für die App und die Schlüssel, und der Aussteller verlässt sich darauf, statt die Wallet selbst zu bewerten.
Wallet-Anbieter
Signiert WIAs und Key Attestations nach Prüfung der App und der Schlüsselspeicherung und betreibt die Status Lists für beide
Wallet-Einheit
Sendet dem Aussteller bei der Ausstellung eine WIA und eine Key Attestation und nutzt jede nur für eine einzige Ausstellung
WSCD oder Keystore
Erzeugt und verwahrt die privaten Schlüssel, die eine Key Attestation beschreibt
PID Provider oder Attestation Provider
Prüft WIA und Key Attestation, bindet das Credential an einen attestierten Schlüssel und prüft beide fortlaufend auf Widerruf
Relying Party
Erhält nie eine WUA. Sie prüft stattdessen das Credential, dessen Gerätebindung und dessen Widerrufsstatus
Aussteller vertrauen einer WUA, weil das Signaturzertifikat des Wallet-Anbieters, übermittelt im x5c-Header, auf einen Trust Anchor der Trusted List für Wallet-Anbieter zurückführt. Die Wallet Solution selbst ist von einer Konformitätsbewertungsstelle zertifiziert, und die WIA enthält diese Zertifizierungsinformationen.
Zwei Attestierungen unter einem Namen
TS3, die technische EUDI-Spezifikation für WUAs, teilt die Attestierung in zwei, weil App und Schlüsselspeicherung verschiedene Dinge sind, die an verschiedenen Endpunkten geprüft und aus verschiedenen Gründen widerrufen werden.
Wallet Instance Attestation (WIA)
- Bestätigt
- Die Integrität der Wallet Instance, also der App
- Gesendet an
- Den Authorization Server, im Pushed Authorization Request und im Token Request
- Lebensdauer
- Weniger als 24 Stunden
- Widerruf
- client_status: der Widerrufsstatus dieser Wallet Instance
- Erforderlich für
- Jede Ausstellung, ob gerätegebunden oder nicht
Key Attestation (KA)
- Bestätigt
- Dass ein oder mehrere Schlüssel in einem benannten WSCD oder Keystore erzeugt wurden und dort verwahrt werden, und wie gut dieser Speicher Angriffen widersteht
- Gesendet an
- Den Credential Issuer, in den proofs des Credential Request
- Lebensdauer
- Vom Wallet-Anbieter festgelegt, kann länger sein als bei einer WIA
- Widerruf
- key_storage_status: der Widerrufsstatus des WSCD oder Keystores
- Erforderlich für
- Nur gerätegebundene Credentials, einschließlich jeder PID
Beide sind JWTs, die der Wallet-Anbieter mit ES256, ES384 oder ES512 signiert. Eine Key Attestation wird nur für eine einzige Ausstellung verwendet, und eine WIA wird nie gegenüber einem anderen Aussteller wiederverwendet, sodass Aussteller Anfragen derselben Wallet nicht miteinander verknüpfen können.
Wie eine Wallet-Einheit ihre WIAs und Key Attestations erhält
TS3 überlässt diesen Schritt dem jeweiligen Wallet-Anbieter, da er innerhalb eines einzelnen Wallet-Produkts stattfindet. Das ARF verlangt nur, dass der Wallet-Anbieter die Integrität der App prüft, bevor er eine WIA signiert, und prüft, dass die attestierten privaten Schlüssel tatsächlich im benannten WSCD oder Keystore liegen, bevor er eine Key Attestation signiert. Ein typischer Ablauf, mit Plattform-Attestierungen wie Google Play Integrity oder Apple DeviceCheck als Nachweis, sieht so aus.
1. Wallet-Einheit
Bittet das WSCD oder den Keystore, Schlüsselpaare zu erzeugen
2. WSCD oder Keystore
Gibt die öffentlichen Schlüssel zurück, mit Nachweisen der Plattform, wo sie erzeugt wurden
3. Wallet-Anbieter
Prüft die Integrität der App und die Schlüsselnachweise und signiert anschließend WIAs und Key Attestations
4. Wallet-Einheit
Hält einen Vorrat frischer WIAs und Key Attestations bereit und verwendet für jede Ausstellung eine neue
Was eine WIA und eine Key Attestation enthalten
Keine von beiden trägt einen iss-Claim: Der Aussteller erkennt den Wallet-Anbieter am Signaturzertifikat im x5c-Header. Die Beispiele unten sind dekodiert, Header und Payload sind durch einen Punkt getrennt.
Wallet Instance Attestation
{
"typ": "oauth-client-attestation+jwt",
"alg": "ES256",
"x5c": ["MIIC..."]
}.{
"sub": "https://wallet.example.eu",
"wallet_name": "ExampleWallet-mobile",
"wallet_version": "2.3.0",
"wallet_link": "https://wallet.example.eu/about",
"wallet_solution_certification_information": "https://wallet.example.eu/certification/2-3-0",
"exp": 1789329600,
"client_status": {
"status": {
"status_list": { "idx": 48213, "uri": "https://wallet.example.eu/status/wia/17" }
},
"exp": 1791936000
},
"cnf": {
"jwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." }
}
}| Feld | Was sie dem Aussteller mitteilt |
|---|---|
| typ / x5c | Dass es sich um eine Client Attestation handelt, und die Zertifikatskette des Wallet-Anbieters zur Prüfung gegen die Trusted List |
| sub | Der Wallet-Typ, für jede Installation gleich, sodass sich damit kein Nutzer verfolgen lässt |
| wallet_name / wallet_version | Die Wallet Solution, wie sie auf der Trusted List geführt wird, und ihre Version |
| wallet_solution_certification_information | Wer die Wallet Solution zertifiziert hat; der genaue Inhalt ist noch festzulegen |
| exp | Technischer Ablauf, weniger als 24 Stunden nach der Integritätsprüfung |
| client_status | Ein Status-List-Eintrag für diese Wallet Instance und das Datum, bis zu dem der Wallet-Anbieter ihn aktuell hält |
| cnf | Der Schlüssel, der den mit der WIA gesendeten Besitznachweis signiert |
Key Attestation
{
"typ": "key-attestation+jwt",
"alg": "ES256",
"x5c": ["MIIC..."]
}.{
"iat": 1789257600,
"exp": 1791936000,
"certification": "https://wallet.example.eu/certification/wscd/secure-element",
"key_storage": ["iso_18045_high"],
"user_authentication": ["iso_18045_high"],
"attested_keys": [
{ "kty": "EC", "crv": "P-256", "x": "...", "y": "..." },
{ "kty": "EC", "crv": "P-256", "x": "...", "y": "..." }
],
"key_storage_status": {
"status": {
"status_list": { "idx": 3, "uri": "https://wallet.example.eu/status/ka/1" }
},
"exp": 1794614400
}
}| Feld | Was sie dem Aussteller mitteilt |
|---|---|
| typ / x5c | Dass es sich um eine Key Attestation handelt, und die Zertifikatskette des Wallet-Anbieters zur Prüfung gegen die Trusted List |
| iat / exp | Wann sie ausgestellt wurde und wann sie technisch abläuft |
| attested_keys | Öffentliche Schlüssel, deren private Schlüssel das WSCD oder der Keystore erzeugt hat und verwahrt; mehrere Schlüssel ermöglichen die Batch-Ausstellung |
| key_storage / user_authentication | Wie gut der Speicher und die Nutzerauthentifizierung, die die Schlüssel entsperrt, Angriffen widerstehen; ein WSCD ist für beides immer iso_18045_high |
| certification | Die Zertifizierung des WSCD oder Keystores, an der der Aussteller erkennt, ob es sich um ein WSCD handelt |
| key_storage_status | Ein Status-List-Eintrag für das WSCD oder den Keystore und das Datum, bis zu dem der Wallet-Anbieter ihn aktuell hält |
| nonce | Die c_nonce des Ausstellers, nur vorhanden, wenn die Key Attestation als attestation-Proof gesendet wird |
Wohin eine WUA bei der Ausstellung über OpenID4VCI gelangt
Die beiden Attestierungen gehen an verschiedene Stellen. Die WIA authentifiziert die Wallet als OAuth-Client beim Authorization Server. Die Key Attestation geht zusammen mit der Anfrage nach dem Credential selbst an den Credential Issuer.
Authorization Server erhält die WIA
- Die Signatur der WIA führt auf die Trusted List für Wallet-Anbieter zurück
- Die WIA ist nicht abgelaufen und die Wallet Instance nicht widerrufen
- Der Besitznachweis ist mit dem Schlüssel aus dem cnf-Claim der WIA signiert
Credential Issuer erhält die Key Attestation
- Die Signatur der Key Attestation führt auf die Trusted List für Wallet-Anbieter zurück
- Die frische c_nonce des Ausstellers steht im jwt-Proof oder in der Key Attestation selbst
- Das WSCD oder der Keystore ist nicht widerrufen, und das Credential ist an einen der attested_keys gebunden
Pushed Authorization Request mit der WIA
POST /par HTTP/1.1 Host: issuer.example.eu Content-Type: application/x-www-form-urlencoded OAuth-Client-Attestation: <WIA JWT> OAuth-Client-Attestation-PoP: <PoP JWT signed with the WIA cnf key> response_type=code &client_id=https%3A%2F%2Fwallet.example.eu &scope=company_registration &code_challenge=<S256 challenge> &code_challenge_method=S256 &redirect_uri=<wallet redirect URI>
Die client_id entspricht dem sub der WIA. Der Token Request trägt dieselben beiden Header. Da der Credential Issuer die WIA nie sieht, muss der Authorization Server ihren client_status weitergeben, etwa im Access Token.
Credential Request mit der Key Attestation
POST /credential HTTP/1.1
Host: issuer.example.eu
Authorization: DPoP <access_token>
DPoP: <DPoP proof JWT>
Content-Type: application/json
{
"credential_configuration_id": "company_registration",
"proofs": {
"jwt": ["<proof JWT: Key Attestation in its key_attestation header, signed with attested_keys[0]>"]
}
}Beim Proof-Typ attestation enthält die Anfrage stattdessen "proofs": { "attestation": ["<Key-Attestation-JWT>"] }. Einen Besitznachweis gibt es dann nicht: Die Wallet-Einheit reicht die c_nonce des Ausstellers an den Wallet-Anbieter weiter, der sie in eine frisch signierte Key Attestation aufnimmt.
Der Lebenszyklus einer WUA
Eine WUA ist bewusst kurzlebig und für den einmaligen Gebrauch bestimmt, doch die Widerrufsinformation dahinter überdauert das Token selbst. Die ersten drei Phasen sind Routine; die vierte tritt nur ein, wenn etwas schiefgeht.
1. Ausstellung
Der Wallet-Anbieter signiert WIAs und Key Attestations nach seinen Prüfungen von Integrität und Schlüsselspeicherung
2. Einmalige Nutzung
Jede dient einer einzigen Ausstellung, daher bezieht die Wallet-Einheit laufend neue
3. Verketteter Widerruf
Ein PID Provider prüft den Status von WIA und Key Attestation mindestens alle 24 Stunden erneut und widerruft die PID, wenn eine der beiden widerrufen ist
4. Widerruf
Der Wallet-Anbieter widerruft eine Wallet Instance, etwa nach Verlust oder Diebstahl, oder ein WSCD oder einen Keystore mit einer Sicherheitslücke
Außerhalb des EUDI-Wallet-Ökosystems stellen manche Wallet-Anbieter Wallet-Attestierungen mit sehr kurzer Lebensdauer und ganz ohne Statusverweis aus und setzen auf Ablauf statt Widerruf; OpenID4VCI macht den Status-Claim optional. TS3 erlaubt das für EUDI Wallets nicht. Die WIA lebt ohnehin weniger als 24 Stunden, dennoch müssen WIA und Key Attestation einen Statusverweis tragen, den der Wallet-Anbieter mindestens 31 Tage lang pflegt, weil PID Provider damit PIDs noch lange nach der Ausstellung widerrufen.
WUA, WIA und KA: welcher Begriff was bedeutet
Die Terminologie hat sich geändert, während die Spezifikationen reiften. TS3 nannte die WIA bis Version 1.1 Wallet App Attestation und verwendete WUA bis Version 1.5 für das, was heute die Key Attestation ist. Ältere Artikel und ARF-Entwürfe verwenden die Begriffe daher anders.
| Begriff | Was sie abdeckt | Wer sie erhält |
|---|---|---|
| WUA | Oberbegriff für die beiden folgenden Attestierungen | PID Provider und Attestation Provider, nur während der Ausstellung |
| WIA | Die Wallet Instance, also die App | Der Authorization Server, im Pushed Authorization Request und im Token Request |
| KA | Ein WSCD oder Keystore und die darin verwahrten Schlüssel | Der Credential Issuer, in den proofs des Credential Request |
Verwandte Begriffe
Häufig gestellte Fragen
Ist eine WUA dasselbe wie eine Wallet Instance Attestation?
Nein. Seit Version 1.5 von TS3 ist WUA der Oberbegriff für zwei Attestierungen: die Wallet Instance Attestation (WIA), die die App abdeckt, und die Key Attestation (KA), die das WSCD oder den Keystore mit den Schlüsseln abdeckt. Ältere Dokumente verwenden WUA für das, was heute Key Attestation heißt, weshalb die Begriffe oft verwechselt werden.
Sieht ein Verifier jemals die WUA?
Nein. Die ARF-Anforderungen WUA_07 und WUA_24 erlauben einer Wallet-Einheit, eine WIA oder Key Attestation nur während der Ausstellung einem PID Provider oder Attestation Provider vorzulegen, niemals einer Relying Party. Ein Verifier prüft stattdessen das Credential: seine Signatur, seine Gerätebindung und seinen Widerrufsstatus. Wird die Wallet hinter einer PID widerrufen, widerruft der PID Provider die PID innerhalb seines 24-Stunden-Prüfzyklus, und der Verifier erkennt das am Status der PID selbst.
Wie lange ist eine WUA gültig?
Eine WIA läuft in weniger als 24 Stunden ab, gerechnet ab der Prüfung der App-Integrität durch den Wallet-Anbieter. Eine Key Attestation kann nach Ermessen des Wallet-Anbieters länger gültig sein. Unabhängig davon trägt jede ein Datum für die Statuspflege, client_status.exp oder key_storage_status.exp, bis zu dem der Wallet-Anbieter den Widerrufsstatus aktuell hält. Die Wallet-Einheit muss jederzeit eine vorlegen können, deren Datum mindestens 31 Tage in der Zukunft liegt, und eine PID muss vor diesem Datum ablaufen.
Was passiert, wenn eine Wallet-Einheit kompromittiert wird, bevor ihre WUA abläuft?
Der Wallet-Anbieter widerruft die Wallet Instance auf seiner WIA-Status-List oder, bei einer Schwachstelle in einem WSCD- oder Keystore-Typ, den Status-List-Eintrag für diesen Speicher. Ein PID Provider prüft mindestens einmal alle 24 Stunden den Status von WIA und Key Attestation hinter jeder von ihm ausgestellten PID und widerruft die PID, wenn eine der beiden widerrufen ist. Attestation Provider können dasselbe tun. Nicht der Ablauf der WUA selbst entfernt die Wallet, sondern der Widerruf der für sie ausgestellten Credentials.
Kann eine Key Attestation mehr als einen Schlüssel abdecken?
Ja. attested_keys kann mehrere öffentliche Schlüssel aus demselben WSCD oder Keystore auflisten, und so funktioniert die Batch-Ausstellung: Der Aussteller bindet jedes Credential im Batch an einen anderen Schlüssel, und eine einzige Signatur des Wallet-Anbieters deckt alle ab. Wird die Key Attestation in einem jwt-Proof übermittelt, signiert die Wallet-Einheit diesen Proof nur mit dem ersten Schlüssel der Liste.
Quellen
Diese Seite dient nur zur Information und stellt keine Rechtsberatung dar. Für verbindliche Hinweise wenden Sie sich direkt an die Europäische Kommission und die OpenID Foundation.