WUA forklaret: sådan beviser en wallet sin ægthed over for en udsteder
En Wallet Unit Attestation, WUA, er det, en EUDI Wallet viser en PID Provider eller Attestation Provider under udstedelsen for at bevise, at den er ægte. Det er ikke ét dokument, men to, begge signeret af Wallet Provider: en Wallet Instance Attestation (WIA) om wallet-appen og en Key Attestation (KA) om det sikre lager for de nøgler, et credential bliver bundet til.
Problemet, en WUA løser
En udsteder, der er ved at overdrage en PID eller et credential for en virksomhedsregistrering til en wallet, har ingen indbygget måde at skelne en certificeret EUDI Wallet fra en modificeret app eller et script, der afspiller et autorisationsflow igen. Den kan heller ikke se, om den nøgle, credentialet bliver bundet til, ligger i certificeret sikker hardware eller i almindeligt lager, hvorfra den kan kopieres.
WUA'en lukker begge huller. Wallet Provider står inde for appen via WIA'en og for nøglelageret via Key Attestation. Udstederen kontrollerer begge før udstedelsen og fortsætter med at kontrollere deres tilbagekaldelsesstatus bagefter, så den kan tilbagekalde det, den har udstedt, hvis wallet'en eller dens nøglelager senere viser sig at være kompromitteret.
En WUA bruges kun under udstedelse. ARF forbyder en Wallet Unit at fremvise en WIA eller Key Attestation til en Relying Party, så oplysninger om wallet'en holdes ude af alle fremvisninger.
Aktørerne, og hvem der stoler på hvem
Fem roller er involveret, og kun fire af dem håndterer nogensinde en WUA. WSCD'et (Wallet Secure Cryptographic Device) eller et keystore genererer og beskytter nøglerne, Wallet Provider står inde for appen og nøglerne, og udstederen forlader sig på det i stedet for selv at vurdere wallet'en.
Wallet Provider
Signerer WIA'er og Key Attestations efter at have kontrolleret appen og nøglelageret, og driver Status Lists for begge
Wallet Unit
Sender en WIA og en Key Attestation til udstederen under udstedelsen og bruger hver af dem til én udstedelse
WSCD eller keystore
Genererer og opbevarer de private nøgler, en Key Attestation beskriver
PID Provider eller Attestation Provider
Kontrollerer WIA'en og Key Attestation, binder credentialet til en attesteret nøgle og bliver ved med at kontrollere begge for tilbagekaldelse
Relying Party
Modtager aldrig en WUA. Den kontrollerer i stedet credentialet, dets binding til enheden og dets tilbagekaldelsesstatus
Udstedere stoler på en WUA, fordi Wallet Providerens signeringscertifikat, der sendes i x5c-headeren, kæder op til et tillidsanker på Trusted List for Wallet Providers. Selve Wallet Solution er certificeret af et overensstemmelsesvurderingsorgan, og WIA'en indeholder disse certificeringsoplysninger.
To attesteringer under ét navn
TS3, den tekniske EUDI-specifikation for WUA'er, deler attesteringen i to, fordi appen og nøglelageret er forskellige ting, som kontrolleres ved forskellige endpoints og tilbagekaldes af forskellige grunde.
Wallet Instance Attestation (WIA)
- Attesterer
- Integriteten af Wallet Instance, altså appen
- Sendes til
- Authorization Server, i Pushed Authorization Request og Token Request
- Levetid
- Under 24 timer
- Tilbagekaldelse
- client_status: tilbagekaldelsesstatus for denne Wallet Instance
- Kræves til
- Enhver udstedelse, enhedsbundet eller ej
Key Attestation (KA)
- Attesterer
- At en eller flere nøgler er genereret i og opbevares af et navngivet WSCD eller keystore, og hvor godt det lager modstår angreb
- Sendes til
- Credential Issuer, i proofs i Credential Request
- Levetid
- Fastsættes af Wallet Provider og kan være længere end for en WIA
- Tilbagekaldelse
- key_storage_status: tilbagekaldelsesstatus for WSCD'et eller keystoret
- Kræves til
- Kun enhedsbundne credentials, herunder alle PID'er
Begge er JWT'er signeret af Wallet Provider med ES256, ES384 eller ES512. En Key Attestation bruges kun til én udstedelse, og en WIA genbruges aldrig over for en anden udsteder, så udstedere ikke kan koble anmodninger fra den samme wallet sammen.
Sådan får en Wallet Unit sine WIA'er og Key Attestations
TS3 overlader dette trin til den enkelte Wallet Provider, da det foregår inde i ét wallet-produkt. ARF kræver kun, at Wallet Provider kontrollerer appens integritet, før den signerer en WIA, og kontrollerer, at de attesterede private nøgler reelt ligger i det navngivne WSCD eller keystore, før den signerer en Key Attestation. Et typisk flow, der bruger platformsattesteringer som Google Play Integrity eller Apple DeviceCheck som bevis, ser sådan ud.
1. Wallet Unit
Beder WSCD'et eller keystoret om at generere nøglepar
2. WSCD eller keystore
Returnerer de offentlige nøgler med platformsbevis for, hvor de blev genereret
3. Wallet Provider
Kontrollerer appens integritet og nøglebeviset og signerer derefter WIA'er og Key Attestations
4. Wallet Unit
Holder et lager af friske WIA'er og Key Attestations og bruger en ny til hver udstedelse
Hvad en WIA og en Key Attestation indeholder
Ingen af dem har et iss-claim: udstederen identificerer Wallet Provider ud fra signeringscertifikatet i x5c-headeren. Eksemplerne nedenfor er afkodet, med header og payload adskilt af et punktum.
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": "..." }
}
}| Felt | Hvad den fortæller udstederen |
|---|---|
| typ / x5c | At dette er en client attestation, og Wallet Providerens certifikatkæde, der skal kontrolleres mod Trusted List |
| sub | Wallet-typen, som er den samme for alle installationer, så den ikke kan bruges til at spore en bruger |
| wallet_name / wallet_version | Wallet Solution, som den står på Trusted List, og dens version |
| wallet_solution_certification_information | Hvem der har certificeret Wallet Solution; det præcise indhold er endnu ikke fastlagt |
| exp | Teknisk udløb, mindre end 24 timer efter integritetskontrollen |
| client_status | En post på Status List for denne Wallet Instance og den dato, indtil hvilken Wallet Provider holder den opdateret |
| cnf | Nøglen, der signerer beviset for besiddelse, som sendes sammen med WIA'en |
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
}
}| Felt | Hvad den fortæller udstederen |
|---|---|
| typ / x5c | At dette er en key attestation, og Wallet Providerens certifikatkæde, der skal kontrolleres mod Trusted List |
| iat / exp | Hvornår den blev udstedt, og hvornår den teknisk udløber |
| attested_keys | Offentlige nøgler, hvis private nøgler WSCD'et eller keystoret har genereret og opbevarer; flere nøgler muliggør batchudstedelse |
| key_storage / user_authentication | Hvor godt lageret og den brugergodkendelse, der låser nøglerne op, modstår angreb; et WSCD er altid iso_18045_high for begge |
| certification | Certificeringen af WSCD'et eller keystoret, som udstederen kan se ud fra, om det er et WSCD |
| key_storage_status | En post på Status List for WSCD'et eller keystoret og den dato, indtil hvilken Wallet Provider holder den opdateret |
| nonce | Udstederens c_nonce, som kun er til stede, når Key Attestation sendes som et attestation-proof |
Hvor en WUA bevæger sig hen under OpenID4VCI-udstedelse
De to attesteringer sendes til forskellige steder. WIA'en autentificerer wallet'en som OAuth-klient hos Authorization Server. Key Attestation sendes til Credential Issuer sammen med anmodningen om selve credentialet.
Authorization Server modtager WIA'en
- WIA'ens signatur kæder op til Trusted List for Wallet Providers
- WIA'en er ikke udløbet, og Wallet Instance er ikke tilbagekaldt
- Bevis for besiddelse er signeret med nøglen i WIA'ens cnf-claim
Credential Issuer modtager Key Attestation
- Key Attestations signatur kæder op til Trusted List for Wallet Providers
- Udstederens friske c_nonce står i jwt-proofet eller i selve Key Attestation
- WSCD'et eller keystoret er ikke tilbagekaldt, og credentialet bindes til en af attested_keys
Pushed Authorization Request med WIA'en
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>
client_id svarer til sub i WIA'en. Token Request indeholder de samme to headers. Da Credential Issuer aldrig ser WIA'en, skal Authorization Server give dens client_status videre, f.eks. i access tokenet.
Credential Request med 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]>"]
}
}Med proof-typen attestation indeholder anmodningen i stedet "proofs": { "attestation": ["<Key Attestation-JWT>"] }. Så er der intet bevis for besiddelse: Wallet Unit giver udstederens c_nonce videre til Wallet Provider, som sætter den ind i en nysigneret Key Attestation.
WUA'ens livscyklus
En WUA er bevidst kortlivet og til engangsbrug, men tilbagekaldelsesoplysningerne bag den lever længere end selve tokenet. De første tre faser er rutine; den fjerde indtræffer kun, når noget går galt.
1. Udstedelse
Wallet Provider signerer WIA'er og Key Attestations efter sine kontroller af integritet og nøglelager
2. Engangsbrug
Hver af dem bruges til én udstedelse, så Wallet Unit bliver ved med at hente nye
3. Kædet tilbagekaldelse
En PID Provider kontrollerer status for WIA og Key Attestation igen mindst hver 24. time og tilbagekalder PID'en, hvis en af dem er tilbagekaldt
4. Tilbagekaldelse
Wallet Provider tilbagekalder en Wallet Instance, f.eks. efter tab eller tyveri, eller et WSCD eller keystore med en sikkerhedssårbarhed
Uden for EUDI Wallet-økosystemet udsteder nogle Wallet Providers wallet-attesteringer med meget kort levetid og slet ingen statusreference, og de forlader sig på udløb frem for tilbagekaldelse; OpenID4VCI gør status-claimet valgfrit. TS3 tillader ikke det for EUDI Wallets. WIA'en lever allerede under 24 timer, men både WIA'en og Key Attestation skal have en statusreference, som Wallet Provider vedligeholder i mindst 31 dage, fordi PID Providers bruger den til at tilbagekalde PID'er længe efter udstedelsen.
WUA, WIA og KA: hvad betyder hvilket begreb
Terminologien ændrede sig, efterhånden som specifikationerne modnedes. TS3 kaldte WIA'en en Wallet App Attestation frem til version 1.1 og brugte WUA om det, der nu er Key Attestation, frem til version 1.5. Ældre artikler og ARF-udkast bruger derfor begreberne anderledes.
| Begreb | Hvad den dækker | Hvem modtager den |
|---|---|---|
| WUA | Samlebetegnelse for de to attesteringer nedenfor | PID Providers og Attestation Providers, kun under udstedelse |
| WIA | Wallet Instance, altså appen | Authorization Server, i Pushed Authorization Request og Token Request |
| KA | Et WSCD eller keystore og de nøgler, det opbevarer | Credential Issuer, i proofs i Credential Request |
Relaterede begreber
Ofte stillede spørgsmål
Er en WUA det samme som en Wallet Instance Attestation?
Nej. Siden version 1.5 af TS3 er WUA samlebetegnelsen for to attesteringer: Wallet Instance Attestation (WIA), der dækker appen, og Key Attestation (KA), der dækker det WSCD eller keystore, som opbevarer nøglerne. Ældre dokumenter bruger WUA om det, der nu hedder Key Attestation, og derfor forveksles begreberne ofte.
Ser en verifikator nogensinde WUA'en?
Nej. ARF-kravene WUA_07 og WUA_24 tillader kun en Wallet Unit at fremvise en WIA eller Key Attestation til en PID Provider eller Attestation Provider under udstedelse, aldrig til en Relying Party. En verifikator kontrollerer i stedet credentialet: signaturen, bindingen til enheden og tilbagekaldelsesstatus. Hvis den wallet, der står bag en PID, bliver tilbagekaldt, tilbagekalder PID Provider PID'en inden for sin kontrolcyklus på 24 timer, og verifikatoren ser det via PID'ens egen status.
Hvor længe er en WUA gyldig?
En WIA udløber mindre end 24 timer efter, at Wallet Provider har kontrolleret appens integritet. En Key Attestation kan være gyldig længere, efter Wallet Providerens skøn. Derudover har hver af dem en dato for statusvedligeholdelse, client_status.exp eller key_storage_status.exp, indtil hvilken Wallet Provider holder tilbagekaldelsesstatus opdateret. Wallet Unit skal altid kunne fremvise en, hvis dato ligger mindst 31 dage ude i fremtiden, og en PID skal udløbe før den dato.
Hvad sker der, hvis en wallet-enhed bliver kompromitteret, før dens WUA udløber?
Wallet Provider tilbagekalder Wallet Instance på sin Status List for WIA'er, eller, ved en sårbarhed i en type WSCD eller keystore, posten på Status List for det lager. En PID Provider kontrollerer mindst én gang hver 24. time status for WIA og Key Attestation bag hver PID, den har udstedt, og tilbagekalder PID'en, når en af dem er tilbagekaldt. Attestation Providers kan gøre det samme. Det er ikke udløbet af selve WUA'en, der fjerner wallet'en, men tilbagekaldelsen af de credentials, der er udstedt til den.
Kan én Key Attestation dække mere end én nøgle?
Ja. attested_keys kan indeholde flere offentlige nøgler fra det samme WSCD eller keystore, og det er sådan batchudstedelse fungerer: udstederen binder hvert credential i batchen til en forskellig nøgle, og én signatur fra Wallet Provider dækker dem alle. Når Key Attestation sendes i et jwt-proof, signerer Wallet Unit kun det proof med den første nøgle på listen.
Kilder
Denne side er informativ og udgør ikke juridisk rådgivning. Kontakt Europa-Kommissionen og OpenID Foundation direkte for autoritativ vejledning.