WUA forklart: slik beviser en wallet at den er ekte for en utsteder
En Wallet Unit Attestation, WUA, er det en EUDI Wallet viser en PID Provider eller Attestation Provider under utstedelse for å bevise at den er ekte. Det er ikke ett dokument, men to, begge signert av Wallet Provider: en Wallet Instance Attestation (WIA) om wallet-appen, og en Key Attestation (KA) om den sikre lagringen av nøklene et credential skal bindes til.
Problemet en WUA løser
En utsteder som skal overlevere en PID eller et foretaksregistreringscredential til en wallet, har ingen innebygd måte å skille en sertifisert EUDI Wallet fra en modifisert app eller et skript som spiller av en autorisasjonsflyt på nytt. Den kan heller ikke se om nøkkelen credentialet skal bindes til, ligger i sertifisert sikker maskinvare eller i vanlig lagring den kan kopieres fra.
WUA-en tetter begge hullene. Wallet Provider går god for appen gjennom WIA-en og for nøkkellagringen gjennom Key Attestation. Utstederen kontrollerer begge før utstedelse og fortsetter å sjekke tilbakekallingsstatusen deres etterpå, slik at den kan tilbakekalle det den har utstedt hvis wallet-en eller nøkkellagringen senere viser seg å være kompromittert.
En WUA brukes bare under utstedelse. ARF forbyr en Wallet Unit å fremvise en WIA eller Key Attestation for en relying party, noe som holder detaljer om wallet-en utenfor alle fremvisninger.
Aktørene og hvem som stoler på hvem
Fem roller er involvert, og bare fire av dem håndterer noen gang en WUA. WSCD-en (Wallet Secure Cryptographic Device) eller et nøkkellager genererer og beskytter nøklene, Wallet Provider går god for appen og nøklene, og utstederen stoler på det i stedet for å vurdere wallet-en selv.
Wallet Provider
Signerer WIA-er og Key Attestations etter å ha kontrollert appen og nøkkellagringen, og driver Status Lists for begge
Wallet Unit
Sender en WIA og en Key Attestation til utstederen under utstedelse, og bruker hver av dem til bare én utstedelse
WSCD eller nøkkellager
Genererer og oppbevarer de private nøklene en Key Attestation beskriver
PID Provider eller Attestation Provider
Verifiserer WIA-en og Key Attestation, binder credentialet til en attestert nøkkel, og fortsetter å sjekke begge for tilbakekalling
Relying party
Mottar aldri en WUA. Den kontrollerer i stedet credentialet, enhetsbindingen og tilbakekallingsstatusen
Utstedere stoler på en WUA fordi Wallet Providers signeringssertifikat, som sendes i x5c-headeren, kjedes til et tillitsanker på Trusted List for Wallet Providers. Selve Wallet Solution er sertifisert av et samsvarsvurderingsorgan, og WIA-en inneholder denne sertifiseringsinformasjonen.
To attestasjoner under ett navn
TS3, den tekniske EUDI-spesifikasjonen for WUA-er, deler attestasjonen i to fordi appen og nøkkellagringen er forskjellige ting, som kontrolleres ved forskjellige endepunkter og tilbakekalles av forskjellige grunner.
Wallet Instance Attestation (WIA)
- Attesterer
- Integriteten til Wallet Instance, altså appen
- Sendes til
- Authorization Server, i Pushed Authorization Request og Token Request
- Levetid
- Mindre enn 24 timer
- Tilbakekalling
- client_status: tilbakekallingsstatusen til denne Wallet Instance
- Nødvendig for
- Hver utstedelse, enhetsbundet eller ikke
Key Attestation (KA)
- Attesterer
- At én eller flere nøkler ble generert i og oppbevares av en navngitt WSCD eller et navngitt nøkkellager, og hvor godt den lagringen motstår angrep
- Sendes til
- Credential Issuer, inne i proofs i Credential Request
- Levetid
- Bestemmes av Wallet Provider, og kan være lengre enn for en WIA
- Tilbakekalling
- key_storage_status: tilbakekallingsstatusen til WSCD-en eller nøkkellageret
- Nødvendig for
- Kun enhetsbundne credentials, inkludert hver PID
Begge er JWT-er signert av Wallet Provider med ES256, ES384 eller ES512. En Key Attestation brukes til bare én utstedelse, og en WIA gjenbrukes aldri mot en annen utsteder, slik at utstedere ikke kan koble sammen forespørsler fra samme wallet.
Slik får en Wallet Unit sine WIA-er og Key Attestations
TS3 overlater dette steget til hver Wallet Provider, siden det skjer inne i ett wallet-produkt. ARF krever bare at Wallet Provider verifiserer appens integritet før den signerer en WIA, og verifiserer at de attesterte private nøklene faktisk ligger i den navngitte WSCD-en eller det navngitte nøkkellageret før den signerer en Key Attestation. En typisk flyt, med plattformattestasjoner som Google Play Integrity eller Apple DeviceCheck som bevis, ser slik ut.
1. Wallet Unit
Ber WSCD-en eller nøkkellageret om å generere nøkkelpar
2. WSCD eller nøkkellager
Returnerer de offentlige nøklene, med plattformbevis for hvor de ble generert
3. Wallet Provider
Kontrollerer appens integritet og nøkkelbevisene, og signerer deretter WIA-er og Key Attestations
4. Wallet Unit
Holder et lager av ferske WIA-er og Key Attestations, og bruker en ny for hver utstedelse
Hva en WIA og en Key Attestation inneholder
Ingen av dem har et iss-claim: utstederen identifiserer Wallet Provider ut fra signeringssertifikatet i x5c-headeren. Eksemplene nedenfor er dekodet, med header og payload skilt med 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 | Hva den forteller utstederen |
|---|---|
| typ / x5c | At dette er en klientattestasjon, og Wallet Providers sertifikatkjede som skal kontrolleres mot Trusted List |
| sub | Wallet-typen, lik for alle installasjoner, slik at den ikke kan brukes til å spore en bruker |
| wallet_name / wallet_version | Wallet Solution slik den står oppført på Trusted List, og versjonen |
| wallet_solution_certification_information | Hvem som sertifiserte Wallet Solution; det nøyaktige innholdet er ennå ikke definert |
| exp | Teknisk utløp, mindre enn 24 timer etter integritetskontrollen |
| client_status | En Status List-oppføring for denne Wallet Instance, og datoen Wallet Provider holder den oppdatert frem til |
| cnf | Nøkkelen som signerer beviset for besittelse 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 | Hva den forteller utstederen |
|---|---|
| typ / x5c | At dette er en nøkkelattestasjon, og Wallet Providers sertifikatkjede som skal kontrolleres mot Trusted List |
| iat / exp | Når den ble utstedt og når den teknisk utløper |
| attested_keys | Offentlige nøkler der WSCD-en eller nøkkellageret genererte og oppbevarer de private nøklene; flere nøkler muliggjør batch-utstedelse |
| key_storage / user_authentication | Hvor godt lagringen, og brukerautentiseringen som låser opp nøklene, motstår angrep; en WSCD er alltid iso_18045_high for begge |
| certification | Sertifiseringen av WSCD-en eller nøkkellageret, som utstederen kan bruke til å se om det er en WSCD |
| key_storage_status | En Status List-oppføring for WSCD-en eller nøkkellageret, og datoen Wallet Provider holder den oppdatert frem til |
| nonce | Utstederens c_nonce, bare til stede når Key Attestation sendes som en attestation-proof |
Hvor en WUA sendes under OpenID4VCI-utstedelse
De to attestasjonene går til forskjellige steder. WIA-en autentiserer wallet-en som OAuth-klient hos Authorization Server. Key Attestation går til Credential Issuer sammen med forespørselen om selve credentialet.
Authorization Server mottar WIA-en
- WIA-signaturen kjedes til Trusted List for Wallet Providers
- WIA-en er ikke utløpt, og Wallet Instance er ikke tilbakekalt
- Beviset for besittelse er signert med nøkkelen i WIA-ens cnf-claim
Credential Issuer mottar Key Attestation
- Key Attestation-signaturen kjedes til Trusted List for Wallet Providers
- Utstederens ferske c_nonce finnes i jwt-proofen eller i selve Key Attestation
- WSCD-en eller nøkkellageret er ikke tilbakekalt, og credentialet er bundet til en av 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 samsvarer med sub i WIA-en. Token Request har de samme to headerne. Fordi Credential Issuer aldri ser WIA-en, må Authorization Server sende client_status videre, for eksempel inne 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 inneholder forespørselen i stedet "proofs": { "attestation": ["<Key Attestation JWT>"] }. Da finnes det ikke noe bevis for besittelse: Wallet Unit-en sender utstederens c_nonce til Wallet Provider, som legger den inn i en nysignert Key Attestation.
Livssyklusen til en WUA
En WUA er bevisst kortlevd og til engangsbruk, men tilbakekallingsinformasjonen bak den lever lenger enn selve tokenet. De tre første stadiene er rutine; det fjerde skjer bare når noe går galt.
1. Utstedelse
Wallet Provider signerer WIA-er og Key Attestations etter sine kontroller av integritet og nøkkellagring
2. Engangsbruk
Hver av dem brukes til én utstedelse, så Wallet Unit-en skaffer stadig nye
3. Kjedet tilbakekalling
En PID Provider sjekker statusen til WIA-en og Key Attestation på nytt minst hver 24. time, og tilbakekaller PID-en hvis en av dem er tilbakekalt
4. Tilbakekall
Wallet Provider tilbakekaller en Wallet Instance, for eksempel etter tap eller tyveri, eller en WSCD eller et nøkkellager med en sikkerhetssårbarhet
Utenfor EUDI Wallet-økosystemet utsteder noen Wallet Providers wallet-attestasjoner med svært kort levetid og uten statusreferanse overhodet, og baserer seg på utløp i stedet for tilbakekalling; OpenID4VCI gjør status-claimet valgfritt. TS3 tillater ikke dette for EUDI Wallets. WIA-en lever allerede mindre enn 24 timer, men både WIA-en og Key Attestation må ha en statusreferanse som Wallet Provider vedlikeholder i minst 31 dager, fordi PID Providers bruker den til å tilbakekalle PID-er lenge etter utstedelse.
WUA, WIA og KA: hvilket begrep betyr hva
Terminologien endret seg mens spesifikasjonene modnet. TS3 kalte WIA-en Wallet App Attestation frem til versjon 1.1, og brukte WUA om det som nå er Key Attestation frem til versjon 1.5. Eldre artikler og ARF-utkast bruker derfor begrepene forskjellig.
| Begrep | Hva den dekker | Hvem som mottar den |
|---|---|---|
| WUA | Samlebegrep for de to attestasjonene nedenfor | PID Providers og Attestation Providers, bare under utstedelse |
| WIA | Wallet Instance, altså appen | Authorization Server, i Pushed Authorization Request og Token Request |
| KA | En WSCD eller et nøkkellager og nøklene som oppbevares der | Credential Issuer, i proofs i Credential Request |
Relaterte begreper
Ofte stilte spørsmål
Er en WUA det samme som en Wallet Instance Attestation?
Nei. Siden versjon 1.5 av TS3 er WUA samlebegrepet for to attestasjoner: Wallet Instance Attestation (WIA), som dekker appen, og Key Attestation (KA), som dekker WSCD-en eller nøkkellageret som oppbevarer nøklene. Eldre dokumenter bruker WUA om det som nå kalles Key Attestation, og derfor forveksles begrepene ofte.
Ser en verifikator noen gang WUA-en?
Nei. ARF-kravene WUA_07 og WUA_24 tillater at en Wallet Unit fremviser en WIA eller Key Attestation bare for en PID Provider eller Attestation Provider under utstedelse, aldri for en relying party. En verifikator kontrollerer i stedet credentialet: signaturen, enhetsbindingen og tilbakekallingsstatusen. Hvis wallet-en bak en PID blir tilbakekalt, tilbakekaller PID Provider PID-en innenfor sin kontrollsyklus på 24 timer, og verifikatoren ser det gjennom PID-ens egen status.
Hvor lenge er en WUA gyldig?
En WIA utløper mindre enn 24 timer etter at Wallet Provider kontrollerte appens integritet. En Key Attestation kan være gyldig lenger, etter Wallet Providers skjønn. I tillegg har hver av dem en dato for statusvedlikehold, client_status.exp eller key_storage_status.exp, som Wallet Provider holder tilbakekallingsstatusen oppdatert frem til. Wallet Unit-en må alltid kunne fremvise en der denne datoen ligger minst 31 dager frem i tid, og en PID må utløpe før den datoen.
Hva skjer hvis en Wallet Unit blir kompromittert før WUA-en utløper?
Wallet Provider tilbakekaller Wallet Instance på sin Status List for WIA-er, eller, ved en sårbarhet i en type WSCD eller nøkkellager, Status List-oppføringen for den lagringen. En PID Provider sjekker statusen til WIA-en og Key Attestation bak hver PID den har utstedt minst én gang hver 24. time, og tilbakekaller PID-en når en av dem er tilbakekalt. Attestation Providers kan gjøre det samme. Det er ikke utløpet av selve WUA-en som fjerner wallet-en, men tilbakekallingen av credentials som er utstedt til den.
Kan én Key Attestation dekke mer enn én nøkkel?
Ja. attested_keys kan liste flere offentlige nøkler fra samme WSCD eller nøkkellager, og det er slik batch-utstedelse fungerer: utstederen binder hvert credential i batchen til en egen nøkkel, og én signatur fra Wallet Provider dekker dem alle. Når Key Attestation sendes i en jwt-proof, signerer Wallet Unit-en den proofen bare med den første nøkkelen i listen.
Kilder
Denne siden er kun til informasjon og utgjør ikke juridisk rådgivning. For autoritativ veiledning, kontakt Europakommisjonen og OpenID Foundation direkte.