WUA förklarad: hur en plånbok bevisar sin äkthet för en utfärdare
En plånboksenhetsattestering, WUA, är det en EUDI Wallet visar för en PID Provider eller Attestation Provider vid utfärdande för att bevisa att den är äkta. Det är inte ett dokument utan två, båda signerade av plånboksleverantören: en plånboksinstansattestering (WIA) om plånboksappen, och en nyckelattestering (KA) om den säkra lagringen av de nycklar som ett intyg ska bindas till.
Problemet som en WUA löser
En utfärdare som ska lämna över en PID eller ett företagsregistreringsintyg till en plånbok har inget inbyggt sätt att skilja en certifierad EUDI Wallet från en modifierad app eller ett skript som spelar upp ett auktoriseringsflöde. Den kan inte heller se om nyckeln som intyget ska bindas till finns i certifierad säker hårdvara eller i vanlig lagring som den skulle kunna kopieras från.
WUA:n täpper till båda luckorna. Plånboksleverantören går i god för appen genom WIA:n och för nyckellagringen genom nyckelattesteringen. Utfärdaren kontrollerar båda före utfärdandet och fortsätter att kontrollera deras återkallelsestatus efteråt, så att den kan återkalla det den utfärdat om plånboken eller dess nyckellagring senare visar sig vara komprometterad.
En WUA används endast vid utfärdande. ARF förbjuder en plånboksenhet att visa upp en WIA eller nyckelattestering för en förlitande part, vilket håller uppgifter om plånboken utanför varje presentation.
Aktörerna och vem som litar på vem
Fem roller är inblandade, och bara fyra av dem hanterar någonsin en WUA. WSCD (Wallet Secure Cryptographic Device) eller ett nyckellager genererar och skyddar nycklarna, plånboksleverantören går i god för appen och nycklarna, och utfärdaren förlitar sig på det i stället för att själv bedöma plånboken.
Plånboksleverantör
Signerar WIA:er och nyckelattesteringar efter att ha kontrollerat appen och nyckellagringen, och driver Status Lists för båda
Plånboksenhet
Skickar en WIA och en nyckelattestering till utfärdaren vid utfärdande, och använder var och en för endast ett utfärdande
WSCD eller nyckellager
Genererar och förvarar de privata nycklar som en nyckelattestering beskriver
PID Provider eller Attestation Provider
Verifierar WIA:n och nyckelattesteringen, binder intyget till en attesterad nyckel och fortsätter att kontrollera båda för återkallelse
Förlitande part
Får aldrig en WUA. Den kontrollerar i stället intyget, dess enhetsbindning och dess återkallelsestatus
Utfärdare litar på en WUA eftersom plånboksleverantörens signeringscertifikat, som skickas i x5c-headern, kedjar till ett tillitsankare på Trusted List för plånboksleverantörer. Själva plånbokslösningen certifieras av ett organ för bedömning av överensstämmelse, och WIA:n innehåller den certifieringsinformationen.
Två attesteringar under ett namn
TS3, den tekniska EUDI-specifikationen för WUA:er, delar upp attesteringen i två eftersom appen och nyckellagringen är olika saker, som kontrolleras vid olika endpoints och återkallas av olika skäl.
Plånboksinstansattestering (WIA)
- Intygar
- Plånboksinstansens integritet, alltså appens
- Skickas till
- Authorization Server, i Pushed Authorization Request och Token Request
- Livslängd
- Mindre än 24 timmar
- Återkallelse
- client_status: återkallelsestatus för denna plånboksinstans
- Behövs för
- Varje utfärdande, enhetsbundet eller inte
Nyckelattestering (KA)
- Intygar
- Att en eller flera nycklar har genererats i och förvaras av en namngiven WSCD eller ett namngivet nyckellager, och hur väl den lagringen motstår attacker
- Skickas till
- Credential Issuer, inuti proofs i Credential Request
- Livslängd
- Bestäms av plånboksleverantören och kan vara längre än för en WIA
- Återkallelse
- key_storage_status: återkallelsestatus för WSCD:n eller nyckellagret
- Behövs för
- Endast enhetsbundna intyg, inklusive varje PID
Båda är JWT:er signerade av plånboksleverantören med ES256, ES384 eller ES512. En nyckelattestering används för endast ett utfärdande, och en WIA återanvänds aldrig mot en annan utfärdare, så utfärdare kan inte koppla ihop förfrågningar från samma plånbok.
Hur en plånboksenhet får sina WIA:er och nyckelattesteringar
TS3 överlåter det här steget till varje plånboksleverantör, eftersom det sker inom en enskild plånboksprodukt. ARF kräver bara att plånboksleverantören verifierar appens integritet innan den signerar en WIA, och verifierar att de attesterade privata nycklarna verkligen finns i den namngivna WSCD:n eller det namngivna nyckellagret innan den signerar en nyckelattestering. Ett typiskt flöde, med plattformsattesteringar som Google Play Integrity eller Apple DeviceCheck som bevis, ser ut så här.
1. Plånboksenhet
Ber WSCD:n eller nyckellagret att generera nyckelpar
2. WSCD eller nyckellager
Returnerar de publika nycklarna, med plattformsbevis på var de genererades
3. Plånboksleverantör
Kontrollerar appens integritet och nyckelbevisen, och signerar sedan WIA:er och nyckelattesteringar
4. Plånboksenhet
Håller ett förråd av färska WIA:er och nyckelattesteringar och använder en ny för varje utfärdande
Vad en WIA och en nyckelattestering innehåller
Ingen av dem bär ett iss-anspråk: utfärdaren identifierar plånboksleverantören utifrån signeringscertifikatet i x5c-headern. Exemplen nedan är avkodade, med header och payload åtskilda av en punkt.
Plånboksinstansattestering
{
"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": "..." }
}
}| Fält | Vad den berättar för utfärdaren |
|---|---|
| typ / x5c | Att detta är en klientattestering, och plånboksleverantörens certifikatkedja att kontrollera mot Trusted List |
| sub | Plånbokstypen, densamma för varje installation, så att den inte kan användas för att spåra en användare |
| wallet_name / wallet_version | Plånbokslösningen så som den står på Trusted List, och dess version |
| wallet_solution_certification_information | Vem som certifierade plånbokslösningen; det exakta innehållet är ännu inte fastställt |
| exp | Teknisk utgångstid, mindre än 24 timmar efter integritetskontrollen |
| client_status | En post på Status List för denna plånboksinstans, och datumet fram till vilket plånboksleverantören håller den uppdaterad |
| cnf | Nyckeln som signerar beviset på innehav som skickas tillsammans med WIA:n |
Nyckelattestering
{
"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
}
}| Fält | Vad den berättar för utfärdaren |
|---|---|
| typ / x5c | Att detta är en nyckelattestering, och plånboksleverantörens certifikatkedja att kontrollera mot Trusted List |
| iat / exp | När den utfärdades och när den tekniskt löper ut |
| attested_keys | Publika nycklar vars privata nycklar WSCD:n eller nyckellagret har genererat och förvarar; flera nycklar möjliggör batchutfärdande |
| key_storage / user_authentication | Hur väl lagringen, och användarautentiseringen som låser upp nycklarna, motstår attacker; en WSCD är alltid iso_18045_high för båda |
| certification | Certifieringen av WSCD:n eller nyckellagret, utifrån vilken utfärdaren kan avgöra om det är en WSCD |
| key_storage_status | En post på Status List för WSCD:n eller nyckellagret, och datumet fram till vilket plånboksleverantören håller den uppdaterad |
| nonce | Utfärdarens c_nonce, som bara finns med när nyckelattesteringen skickas som ett attestation-bevis |
Var en WUA skickas vid utfärdande med OpenID4VCI
De två attesteringarna går till olika ställen. WIA:n autentiserar plånboken som OAuth-klient hos Authorization Server. Nyckelattesteringen går till Credential Issuer tillsammans med begäran om själva intyget.
Authorization Server tar emot WIA:n
- WIA-signaturen kedjar till Trusted List för plånboksleverantörer
- WIA:n har inte löpt ut och plånboksinstansen är inte återkallad
- Beviset på innehav är signerat med nyckeln i WIA:ns cnf-anspråk
Credential Issuer tar emot nyckelattesteringen
- Nyckelattesteringens signatur kedjar till Trusted List för plånboksleverantörer
- Utfärdarens färska c_nonce finns i jwt-beviset eller i själva nyckelattesteringen
- WSCD:n eller nyckellagret är inte återkallat, och intyget binds till en av attested_keys
Pushed Authorization Request med WIA:n
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 matchar sub i WIA:n. Token Request bär samma två headers. Eftersom Credential Issuer aldrig ser WIA:n måste Authorization Server föra vidare dess client_status, till exempel i access token.
Credential Request med nyckelattesteringen
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 bevistypen attestation innehåller begäran i stället "proofs": { "attestation": ["<Key Attestation JWT>"] }. Då finns inget bevis på innehav: plånboksenheten skickar utfärdarens c_nonce till plånboksleverantören, som lägger in den i en nysignerad nyckelattestering.
WUA:ns livscykel
En WUA är medvetet kortlivad och avsedd för engångsbruk, men återkallelseinformationen bakom den lever längre än själva token. De tre första stegen är rutin; det fjärde inträffar bara när något går fel.
1. Utfärdande
Plånboksleverantören signerar WIA:er och nyckelattesteringar efter sina kontroller av integritet och nyckellagring
2. Engångsbruk
Var och en används för ett enda utfärdande, så plånboksenheten skaffar hela tiden nya
3. Kedjad återkallelse
En PID Provider kontrollerar statusen för WIA:n och nyckelattesteringen minst var 24:e timme och återkallar PID:en om någon av dem är återkallad
4. Återkallelse
Plånboksleverantören återkallar en plånboksinstans, till exempel efter förlust eller stöld, eller en WSCD eller ett nyckellager med en säkerhetssårbarhet
Utanför EUDI Wallet-ekosystemet utfärdar vissa plånboksleverantörer plånboksattesteringar med mycket kort livslängd och helt utan statusreferens, och förlitar sig på utgångstid i stället för återkallelse; OpenID4VCI gör statusanspråket valfritt. TS3 tillåter inte det för EUDI Wallets. WIA:n lever redan mindre än 24 timmar, men både WIA:n och nyckelattesteringen måste bära en statusreferens som plånboksleverantören underhåller i minst 31 dagar, eftersom PID Providers använder den för att återkalla PID:er långt efter utfärdandet.
WUA, WIA och KA: vilket begrepp betyder vad
Terminologin ändrades i takt med att specifikationerna mognade. TS3 kallade WIA för Wallet App Attestation fram till version 1.1, och använde WUA för det som nu är nyckelattesteringen fram till version 1.5. Äldre artiklar och ARF-utkast använder därför begreppen på olika sätt.
| Term | Vad den omfattar | Vem som tar emot den |
|---|---|---|
| WUA | Samlingsbegrepp för de två attesteringarna nedan | PID Providers och Attestation Providers, endast vid utfärdande |
| WIA | Plånboksinstansen, alltså appen | Authorization Server, i Pushed Authorization Request och Token Request |
| KA | En WSCD eller ett nyckellager och de nycklar som förvaras där | Credential Issuer, i proofs i Credential Request |
Relaterade begrepp
Vanliga frågor
Är en WUA samma sak som en plånboksinstansattestering?
Nej. Sedan version 1.5 av TS3 är WUA samlingsbegreppet för två attesteringar: plånboksinstansattesteringen (WIA), som omfattar appen, och nyckelattesteringen (KA), som omfattar den WSCD eller det nyckellager som förvarar nycklarna. Äldre dokument använder WUA för det som nu kallas nyckelattestering, vilket är anledningen till att begreppen ofta blandas ihop.
Ser en verifierare någonsin WUA:n?
Nej. ARF-kraven WUA_07 och WUA_24 tillåter en plånboksenhet att visa upp en WIA eller nyckelattestering endast för en PID Provider eller Attestation Provider vid utfärdande, aldrig för en förlitande part. En verifierare kontrollerar i stället intyget: dess signatur, dess enhetsbindning och dess återkallelsestatus. Om plånboken bakom en PID återkallas, återkallar PID Provider PID:en inom sin kontrollcykel på 24 timmar, och verifieraren ser det genom PID:ens egen status.
Hur länge är en WUA giltig?
En WIA löper ut mindre än 24 timmar efter att plånboksleverantören kontrollerade appens integritet. En nyckelattestering kan vara giltig längre, enligt plånboksleverantörens bedömning. Utöver det bär var och en ett datum för statusunderhåll, client_status.exp eller key_storage_status.exp, fram till vilket plånboksleverantören håller återkallelsestatusen uppdaterad. Plånboksenheten måste alltid kunna visa upp en vars datum ligger minst 31 dagar fram i tiden, och en PID måste löpa ut före det datumet.
Vad händer om en plånboksenhet komprometteras innan dess WUA löper ut?
Plånboksleverantören återkallar plånboksinstansen på sin Status List för WIA:er eller, vid en sårbarhet i en typ av WSCD eller nyckellager, posten på Status List för den lagringen. En PID Provider kontrollerar statusen för WIA:n och nyckelattesteringen bakom varje PID den har utfärdat minst en gång var 24:e timme och återkallar PID:en när någon av dem är återkallad. Attestation Providers får göra detsamma. Det är inte att själva WUA:n löper ut som tar bort plånboken, utan att de intyg som utfärdats till den återkallas.
Kan en nyckelattestering omfatta mer än en nyckel?
Ja. attested_keys kan lista flera publika nycklar från samma WSCD eller nyckellager, och det är så batchutfärdande fungerar: utfärdaren binder varje intyg i batchen till en egen nyckel, och en enda signatur från plånboksleverantören täcker dem alla. När nyckelattesteringen skickas i ett jwt-bevis signerar plånboksenheten det beviset endast med den första nyckeln i listan.
Källor
Den här sidan är informativ och utgör inte juridisk rådgivning. Vänd dig direkt till Europeiska kommissionen och OpenID Foundation för auktoritativ vägledning.