WUA uitgelegd: hoe een wallet zich bewijst tegenover een uitgever
Een Wallet Unit Attestation, WUA, is wat een EUDI Wallet tijdens de uitgifte aan een PID Provider of Attestation Provider laat zien om te bewijzen dat hij echt is. Het is niet één document maar twee, beide ondertekend door de walletprovider: een Wallet Instance Attestation (WIA) over de walletapp, en een Key Attestation (KA) over de beveiligde opslag van de sleutels waaraan een credential wordt gekoppeld.
Het probleem dat een WUA oplost
Een uitgever die op het punt staat een PID of een bedrijfsregistratiecredential aan een wallet te geven, kan uit zichzelf geen gecertificeerde EUDI Wallet onderscheiden van een aangepaste app of een script dat een autorisatieflow herhaalt. Evenmin kan hij zien of de sleutel waaraan de credential wordt gekoppeld in gecertificeerde beveiligde hardware staat, of in gewone opslag waaruit hij gekopieerd kan worden.
De WUA dicht beide gaten. De walletprovider staat via de WIA garant voor de app en via de Key Attestation voor de sleutelopslag. De uitgever controleert beide vóór de uitgifte en blijft daarna hun intrekkingsstatus controleren, zodat hij wat hij heeft uitgegeven kan intrekken als later blijkt dat de wallet of zijn sleutelopslag is gecompromitteerd.
Een WUA wordt alleen tijdens de uitgifte gebruikt. Het ARF verbiedt een walleteenheid om een WIA of Key Attestation aan een Relying Party te tonen, waardoor walletgegevens buiten elke presentatie blijven.
De actoren en wie wie vertrouwt
Er zijn vijf rollen betrokken, en slechts vier daarvan komen ooit met een WUA in aanraking. De WSCD (Wallet Secure Cryptographic Device) of een keystore genereert en bewaakt de sleutels, de walletprovider staat garant voor de app en de sleutels, en de uitgever vertrouwt daarop in plaats van de wallet zelf te beoordelen.
Walletprovider
Ondertekent WIA's en Key Attestations na controle van de app en de sleutelopslag, en beheert de Status Lists voor beide
Walleteenheid
Stuurt tijdens de uitgifte een WIA en een Key Attestation naar de uitgever, en gebruikt elk ervan voor slechts één uitgifte
WSCD of keystore
Genereert en bewaart de private sleutels die een Key Attestation beschrijft
PID Provider of Attestation Provider
Verifieert de WIA en Key Attestation, koppelt de credential aan een geattesteerde sleutel en blijft beide controleren op intrekking
Relying Party
Ontvangt nooit een WUA. Controleert in plaats daarvan de credential, de apparaatbinding en de intrekkingsstatus ervan
Uitgevers vertrouwen een WUA omdat het ondertekeningscertificaat van de walletprovider, meegestuurd in de x5c-header, terugleidt naar een trust anchor op de Trusted List voor walletproviders. De Wallet Solution zelf is gecertificeerd door een conformiteitsbeoordelingsinstantie, en de WIA bevat die certificeringsinformatie.
Twee attestaties onder één naam
TS3, de technische EUDI-specificatie voor WUA's, splitst de attestatie in tweeën omdat de app en de sleutelopslag verschillende dingen zijn, die bij verschillende endpoints worden gecontroleerd en om verschillende redenen worden ingetrokken.
Wallet Instance Attestation (WIA)
- Attesteert
- De integriteit van de Wallet Instance, oftewel de app
- Gestuurd naar
- De Authorization Server, in het Pushed Authorization Request en het Token Request
- Levensduur
- Minder dan 24 uur
- Intrekking
- client_status: de intrekkingsstatus van deze Wallet Instance
- Nodig voor
- Elke uitgifte, al dan niet apparaatgebonden
Key Attestation (KA)
- Attesteert
- Dat een of meer sleutels zijn gegenereerd in en worden bewaard door een benoemde WSCD of keystore, en hoe goed die opslag bestand is tegen aanvallen
- Gestuurd naar
- De Credential Issuer, in de proofs van het Credential Request
- Levensduur
- Bepaald door de walletprovider, en mag langer zijn dan die van een WIA
- Intrekking
- key_storage_status: de intrekkingsstatus van de WSCD of keystore
- Nodig voor
- Alleen apparaatgebonden credentials, waaronder elke PID
Beide zijn JWT's die de walletprovider ondertekent met ES256, ES384 of ES512. Een Key Attestation wordt voor slechts één uitgifte gebruikt en een WIA wordt nooit hergebruikt richting een andere uitgever, zodat uitgevers verzoeken van dezelfde wallet niet aan elkaar kunnen koppelen.
Hoe een walleteenheid zijn WIA's en Key Attestations verkrijgt
TS3 laat deze stap over aan elke walletprovider, omdat die zich binnen één walletproduct afspeelt. Het ARF eist alleen dat de walletprovider de integriteit van de app verifieert voordat hij een WIA ondertekent, en verifieert dat de geattesteerde private sleutels echt in de genoemde WSCD of keystore staan voordat hij een Key Attestation ondertekent. Een typische flow, met platformattestaties zoals Google Play Integrity of Apple DeviceCheck als bewijs, ziet er zo uit.
1. Walleteenheid
Vraagt de WSCD of keystore om sleutelparen te genereren
2. WSCD of keystore
Geeft de publieke sleutels terug, met platformbewijs van waar ze zijn gegenereerd
3. Walletprovider
Controleert de integriteit van de app en het sleutelbewijs, en ondertekent vervolgens WIA's en Key Attestations
4. Walleteenheid
Houdt een voorraad verse WIA's en Key Attestations aan, en gebruikt voor elke uitgifte een nieuwe
Wat een WIA en een Key Attestation bevatten
Geen van beide bevat een iss-claim: de uitgever herkent de walletprovider aan het ondertekeningscertificaat in de x5c-header. De voorbeelden hieronder zijn gedecodeerd, met header en payload gescheiden door een punt.
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": "..." }
}
}| Veld | Wat het de uitgever vertelt |
|---|---|
| typ / x5c | Dat dit een client attestation is, en de certificaatketen van de walletprovider om tegen de Trusted List te controleren |
| sub | Het wallettype, gelijk voor elke installatie, zodat het niet kan worden gebruikt om een gebruiker te volgen |
| wallet_name / wallet_version | De Wallet Solution zoals vermeld op de Trusted List, en de versie ervan |
| wallet_solution_certification_information | Wie de Wallet Solution heeft gecertificeerd; de precieze inhoud moet nog worden vastgesteld |
| exp | Technische vervaldatum, minder dan 24 uur na de integriteitscontrole |
| client_status | Een Status List-vermelding voor deze Wallet Instance, en de datum tot wanneer de walletprovider die actueel houdt |
| cnf | De sleutel die het bewijs van bezit ondertekent dat met de WIA wordt meegestuurd |
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
}
}| Veld | Wat het de uitgever vertelt |
|---|---|
| typ / x5c | Dat dit een key attestation is, en de certificaatketen van de walletprovider om tegen de Trusted List te controleren |
| iat / exp | Wanneer hij is uitgegeven en wanneer hij technisch verloopt |
| attested_keys | Publieke sleutels waarvan de WSCD of keystore de private sleutels heeft gegenereerd en bewaart; meerdere sleutels maken batch-uitgifte mogelijk |
| key_storage / user_authentication | Hoe goed de opslag, en de gebruikersauthenticatie die de sleutels ontgrendelt, bestand zijn tegen aanvallen; een WSCD is voor beide altijd iso_18045_high |
| certification | De certificering van de WSCD of keystore, waaruit de uitgever kan afleiden of het een WSCD is |
| key_storage_status | Een Status List-vermelding voor de WSCD of keystore, en de datum tot wanneer de walletprovider die actueel houdt |
| nonce | De c_nonce van de uitgever, alleen aanwezig wanneer de Key Attestation als attestation-proof wordt verstuurd |
Waar een WUA naartoe gaat tijdens uitgifte via OpenID4VCI
De twee attestaties gaan naar verschillende plekken. De WIA authenticeert de wallet als OAuth-client bij de Authorization Server. De Key Attestation gaat naar de Credential Issuer, samen met het verzoek om de credential zelf.
Authorization Server ontvangt de WIA
- De handtekening van de WIA leidt terug naar de Trusted List voor walletproviders
- De WIA is niet verlopen en de Wallet Instance is niet ingetrokken
- Het bewijs van bezit is ondertekend met de sleutel in de cnf-claim van de WIA
Credential Issuer ontvangt de Key Attestation
- De handtekening van de Key Attestation leidt terug naar de Trusted List voor walletproviders
- De verse c_nonce van de uitgever staat in het jwt-proof of in de Key Attestation zelf
- De WSCD of keystore is niet ingetrokken, en de credential is gekoppeld aan een van de attested_keys
Pushed Authorization Request met de 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>
De client_id komt overeen met de sub van de WIA. Het Token Request bevat dezelfde twee headers. Omdat de Credential Issuer de WIA nooit ziet, moet de Authorization Server de client_status ervan doorgeven, bijvoorbeeld in het access token.
Credential Request met de 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]>"]
}
}Met het attestation-prooftype bevat het verzoek in plaats daarvan "proofs": { "attestation": ["<Key Attestation JWT>"] }. Er is dan geen bewijs van bezit: de walleteenheid geeft de c_nonce van de uitgever door aan de walletprovider, die deze opneemt in een vers ondertekende Key Attestation.
De levenscyclus van een WUA
Een WUA is bewust kortlevend en voor eenmalig gebruik, maar de intrekkingsinformatie erachter leeft langer dan het token zelf. De eerste drie fasen zijn routine; de vierde vindt alleen plaats wanneer er iets misgaat.
1. Uitgifte
De walletprovider ondertekent WIA's en Key Attestations na zijn controles van de integriteit en de sleutelopslag
2. Eenmalig gebruik
Elke attestatie dient één uitgifte, dus de walleteenheid haalt steeds nieuwe op
3. Gekoppelde intrekking
Een PID Provider controleert de status van de WIA en Key Attestation minstens elke 24 uur opnieuw, en trekt de PID in als een van beide is ingetrokken
4. Intrekking
De walletprovider trekt een Wallet Instance in, bijvoorbeeld na verlies of diefstal, of een WSCD of keystore met een beveiligingslek
Buiten het EUDI Wallet-ecosysteem geven sommige walletproviders wallet attestations uit met een zeer korte levensduur en helemaal geen statusverwijzing, en vertrouwen ze op verlopen in plaats van intrekking; OpenID4VCI maakt de statusclaim optioneel. TS3 staat dat niet toe voor EUDI Wallets. De WIA leeft al minder dan 24 uur, maar toch moeten zowel de WIA als de Key Attestation een statusverwijzing bevatten die de walletprovider minstens 31 dagen bijhoudt, omdat PID Providers die gebruiken om PID's lang na de uitgifte in te trekken.
WUA, WIA en KA: welke term wat betekent
De terminologie veranderde terwijl de specificaties volwassen werden. TS3 noemde de WIA tot versie 1.1 een Wallet App Attestation, en gebruikte WUA tot versie 1.5 voor wat nu de Key Attestation is. Oudere artikelen en ARF-concepten gebruiken de termen daarom anders.
| Term | Wat het dekt | Wie het ontvangt |
|---|---|---|
| WUA | Overkoepelende term voor de twee attestaties hieronder | PID Providers en Attestation Providers, alleen tijdens uitgifte |
| WIA | De Wallet Instance, oftewel de app | De Authorization Server, in het Pushed Authorization Request en het Token Request |
| KA | Een WSCD of keystore en de sleutels die deze bewaart | De Credential Issuer, in de proofs van het Credential Request |
Gerelateerde termen
Veelgestelde vragen
Is een WUA hetzelfde als een Wallet Instance Attestation?
Nee. Sinds versie 1.5 van TS3 is WUA de overkoepelende term voor twee attestaties: de Wallet Instance Attestation (WIA), die de app dekt, en de Key Attestation (KA), die de WSCD of keystore met de sleutels dekt. Oudere documenten gebruiken WUA voor wat nu de Key Attestation heet, en daarom worden de termen vaak verward.
Krijgt een verifier de WUA ooit te zien?
Nee. Volgens de ARF-eisen WUA_07 en WUA_24 mag een walleteenheid een WIA of Key Attestation alleen tijdens de uitgifte aan een PID Provider of Attestation Provider tonen, nooit aan een Relying Party. Een verifier controleert in plaats daarvan de credential: de handtekening, de apparaatbinding en de intrekkingsstatus. Als de wallet achter een PID wordt ingetrokken, trekt de PID Provider de PID binnen zijn controlecyclus van 24 uur in, en de verifier ziet dat aan de eigen status van de PID.
Hoe lang is een WUA geldig?
Een WIA verloopt minder dan 24 uur nadat de walletprovider de integriteit van de app heeft gecontroleerd. Een Key Attestation kan langer geldig zijn, naar keuze van de walletprovider. Daarnaast heeft elk van beide een datum voor statusonderhoud, client_status.exp of key_storage_status.exp, tot wanneer de walletprovider de intrekkingsstatus actueel houdt. De walleteenheid moet altijd een attestatie kunnen tonen waarvan die datum minstens 31 dagen in de toekomst ligt, en een PID moet vóór die datum verlopen.
Wat gebeurt er als een walleteenheid wordt gecompromitteerd voordat de WUA verloopt?
De walletprovider trekt de Wallet Instance in op zijn WIA-Status List of, bij een kwetsbaarheid in een type WSCD of keystore, de Status List-vermelding voor die opslag. Een PID Provider controleert minstens eens per 24 uur de status van de WIA en Key Attestation achter elke PID die hij heeft uitgegeven, en trekt de PID in als een van beide is ingetrokken. Attestation Providers mogen hetzelfde doen. Het is niet het verlopen van de WUA zelf dat de wallet uitschakelt, maar de intrekking van de credentials die eraan zijn uitgegeven.
Kan één Key Attestation meer dan één sleutel dekken?
Ja. attested_keys kan meerdere publieke sleutels uit dezelfde WSCD of keystore bevatten, en zo werkt batch-uitgifte: de uitgever koppelt elke credential in de batch aan een andere sleutel, en één handtekening van de walletprovider dekt ze allemaal. Wanneer de Key Attestation in een jwt-proof wordt meegestuurd, ondertekent de walleteenheid dat proof alleen met de eerste sleutel in de lijst.
Bronnen
Deze pagina is informatief en vormt geen juridisch advies. Raadpleeg voor gezaghebbende richtlijnen rechtstreeks de Europese Commissie en de OpenID Foundation.