WUA expliqué : comment un portefeuille prouve son authenticité à un émetteur
Une Wallet Unit Attestation, WUA, est ce qu'un EUDI Wallet présente à un PID Provider ou à un Attestation Provider lors de l'émission pour prouver qu'il est authentique. Il ne s'agit pas d'un document mais de deux, tous deux signés par le Fournisseur de Portefeuille : une Wallet Instance Attestation (WIA) portant sur l'application de portefeuille, et une Key Attestation (KA) portant sur le stockage sécurisé des clés auxquelles un credential sera lié.
Le problème que résout une WUA
Un émetteur sur le point de remettre un PID ou un credential d'immatriculation d'entreprise à un portefeuille n'a aucun moyen intégré de distinguer un EUDI Wallet certifié d'une application modifiée ou d'un script rejouant un flux d'autorisation. Il ne peut pas non plus savoir si la clé à laquelle le credential sera lié se trouve dans du matériel sécurisé certifié, ou dans un stockage ordinaire d'où elle pourrait être copiée.
La WUA comble ces deux lacunes. Le Fournisseur de Portefeuille se porte garant de l'application par la WIA et du stockage des clés par la Key Attestation. L'émetteur vérifie les deux avant l'émission, puis continue de contrôler leur statut de révocation, ce qui lui permet de révoquer ce qu'il a délivré si le portefeuille ou son stockage de clés s'avère compromis par la suite.
Une WUA n'est utilisée que lors de l'émission. L'ARF interdit à une unité de portefeuille de présenter une WIA ou une Key Attestation à une partie utilisatrice, ce qui tient les informations sur le portefeuille à l'écart de toute présentation.
Les acteurs et qui fait confiance à qui
Cinq rôles sont impliqués, et seuls quatre d'entre eux manipulent une WUA. Le WSCD (Wallet Secure Cryptographic Device) ou un keystore génère et protège les clés, le Fournisseur de Portefeuille se porte garant de l'application et des clés, et l'émetteur s'appuie sur cette garantie plutôt que d'évaluer lui-même le portefeuille.
Fournisseur de Portefeuille
Signe les WIA et les Key Attestations après avoir vérifié l'application et le stockage des clés, et gère les Status Lists des deux
Unité de Portefeuille
Envoie une WIA et une Key Attestation à l'émetteur lors de l'émission, et n'utilise chacune que pour une seule émission
WSCD ou keystore
Génère et conserve les clés privées décrites par une Key Attestation
PID Provider ou Attestation Provider
Vérifie la WIA et la Key Attestation, lie le credential à une clé attestée et continue de contrôler la révocation des deux
Partie utilisatrice
Ne reçoit jamais de WUA. Elle vérifie à la place le credential, son lien à l'appareil et son statut de révocation
Les émetteurs font confiance à une WUA parce que le certificat de signature du Fournisseur de Portefeuille, transmis dans l'en-tête x5c, remonte à un trust anchor de la Trusted List des Fournisseurs de Portefeuille. La Wallet Solution elle-même est certifiée par un organisme d'évaluation de la conformité, et la WIA contient ces informations de certification.
Deux attestations sous un même nom
TS3, la spécification technique EUDI consacrée aux WUA, scinde l'attestation en deux parce que l'application et le stockage des clés sont des choses différentes, vérifiées sur des endpoints différents et révoquées pour des raisons différentes.
Wallet Instance Attestation (WIA)
- Atteste
- L'intégrité de la Wallet Instance, c'est-à-dire l'application
- Envoyée à
- L'Authorization Server, dans la Pushed Authorization Request et la Token Request
- Durée de vie
- Moins de 24 heures
- Révocation
- client_status : l'état de révocation de cette Wallet Instance
- Requise pour
- Chaque émission, liée à l'appareil ou non
Key Attestation (KA)
- Atteste
- Qu'une ou plusieurs clés ont été générées dans un WSCD ou keystore désigné et y sont conservées, et dans quelle mesure ce stockage résiste aux attaques
- Envoyée à
- Le Credential Issuer, dans les proofs de la Credential Request
- Durée de vie
- Choisie par le Fournisseur de Portefeuille, et peut être plus longue que celle d'une WIA
- Révocation
- key_storage_status : l'état de révocation du WSCD ou keystore
- Requise pour
- Credentials liés à l'appareil uniquement, y compris tout PID
Les deux sont des JWT signés par le Fournisseur de Portefeuille avec ES256, ES384 ou ES512. Une Key Attestation ne sert qu'à une seule émission et une WIA n'est jamais réutilisée auprès d'un autre émetteur, si bien que les émetteurs ne peuvent pas relier les demandes provenant d'un même portefeuille.
Comment une unité de portefeuille obtient ses WIA et ses Key Attestations
TS3 laisse cette étape à chaque Fournisseur de Portefeuille, puisqu'elle se déroule au sein d'un seul produit de portefeuille. L'ARF exige seulement que le Fournisseur de Portefeuille vérifie l'intégrité de l'application avant de signer une WIA, et qu'il vérifie que les clés privées attestées se trouvent réellement dans le WSCD ou keystore désigné avant de signer une Key Attestation. Un flux type, utilisant comme preuves des attestations de plateforme telles que Google Play Integrity ou Apple DeviceCheck, se présente ainsi.
1. Unité de Portefeuille
Demande au WSCD ou keystore de générer des paires de clés
2. WSCD ou keystore
Renvoie les clés publiques, avec des preuves de la plateforme indiquant où elles ont été générées
3. Fournisseur de Portefeuille
Vérifie l'intégrité de l'application et les preuves relatives aux clés, puis signe les WIA et les Key Attestations
4. Unité de Portefeuille
Garde une réserve de WIA et de Key Attestations récentes, et en utilise une nouvelle pour chaque émission
Ce que contiennent une WIA et une Key Attestation
Aucune des deux ne contient de claim iss : l'émetteur identifie le Fournisseur de Portefeuille grâce au certificat de signature de l'en-tête x5c. Les exemples ci-dessous sont décodés, l'en-tête et le payload étant séparés par un point.
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": "..." }
}
}| Champ | Ce qu'elle indique à l'émetteur |
|---|---|
| typ / x5c | Qu'il s'agit d'une client attestation, et la chaîne de certificats du Fournisseur de Portefeuille à vérifier par rapport à la Trusted List |
| sub | Le type de portefeuille, identique pour chaque installation, afin qu'il ne puisse pas servir à suivre un utilisateur |
| wallet_name / wallet_version | La Wallet Solution telle qu'inscrite sur la Trusted List, et sa version |
| wallet_solution_certification_information | Qui a certifié la Wallet Solution ; le contenu exact reste à définir |
| exp | Expiration technique, moins de 24 heures après le contrôle d'intégrité |
| client_status | Une entrée de Status List pour cette Wallet Instance, et la date jusqu'à laquelle le Fournisseur de Portefeuille la tient à jour |
| cnf | La clé qui signe la preuve de possession envoyée avec la WIA |
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
}
}| Champ | Ce qu'elle indique à l'émetteur |
|---|---|
| typ / x5c | Qu'il s'agit d'une key attestation, et la chaîne de certificats du Fournisseur de Portefeuille à vérifier par rapport à la Trusted List |
| iat / exp | Quand elle a été émise et quand elle expire techniquement |
| attested_keys | Clés publiques dont le WSCD ou keystore a généré et conserve les clés privées ; plusieurs clés permettent l'émission par lots |
| key_storage / user_authentication | Dans quelle mesure le stockage, et l'authentification de l'utilisateur qui déverrouille les clés, résistent aux attaques ; un WSCD est toujours iso_18045_high pour les deux |
| certification | La certification du WSCD ou keystore, qui permet à l'émetteur de savoir s'il s'agit d'un WSCD |
| key_storage_status | Une entrée de Status List pour le WSCD ou keystore, et la date jusqu'à laquelle le Fournisseur de Portefeuille la tient à jour |
| nonce | Le c_nonce de l'émetteur, présent uniquement lorsque la Key Attestation est envoyée sous forme de proof attestation |
Où circule une WUA lors de l'émission via OpenID4VCI
Les deux attestations vont à des endroits différents. La WIA authentifie le portefeuille en tant que client OAuth auprès de l'Authorization Server. La Key Attestation est envoyée au Credential Issuer avec la demande du credential lui-même.
L'Authorization Server reçoit la WIA
- La signature de la WIA remonte à la Trusted List des Fournisseurs de Portefeuille
- La WIA n'a pas expiré et la Wallet Instance n'est pas révoquée
- La preuve de possession est signée avec la clé figurant dans la claim cnf de la WIA
Le Credential Issuer reçoit la Key Attestation
- La signature de la Key Attestation remonte à la Trusted List des Fournisseurs de Portefeuille
- Le c_nonce récent de l'émetteur figure dans le proof jwt ou dans la Key Attestation elle-même
- Le WSCD ou keystore n'est pas révoqué, et le credential est lié à l'une des attested_keys
Pushed Authorization Request avec la 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>
Le client_id correspond au sub de la WIA. La Token Request porte les deux mêmes en-têtes. Comme le Credential Issuer ne voit jamais la WIA, l'Authorization Server doit lui transmettre son client_status, par exemple dans l'access token.
Credential Request avec la 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]>"]
}
}Avec le type de proof attestation, la requête contient à la place "proofs": { "attestation": ["<JWT de la Key Attestation>"] }. Il n'y a alors pas de preuve de possession : l'unité de portefeuille transmet le c_nonce de l'émetteur au Fournisseur de Portefeuille, qui l'insère dans une Key Attestation fraîchement signée.
Le cycle de vie d'une WUA
Une WUA est volontairement de courte durée et à usage unique, mais les informations de révocation qui la sous-tendent survivent au token lui-même. Les trois premières étapes sont routinières ; la quatrième ne se produit que lorsque quelque chose tourne mal.
1. Émission
Le Fournisseur de Portefeuille signe les WIA et les Key Attestations après ses contrôles d'intégrité et de stockage des clés
2. Usage unique
Chacune sert à une seule émission, donc l'unité de portefeuille en obtient continuellement de nouvelles
3. Révocation en cascade
Un PID Provider revérifie le statut de la WIA et de la Key Attestation au moins toutes les 24 heures, et révoque le PID si l'une ou l'autre est révoquée
4. Révocation
Le Fournisseur de Portefeuille révoque une Wallet Instance, par exemple après une perte ou un vol, ou un WSCD ou keystore présentant une faille de sécurité
En dehors de l'écosystème EUDI Wallet, certains Fournisseurs de Portefeuille délivrent des wallet attestations à durée de vie très courte et sans aucune référence de statut, en misant sur l'expiration plutôt que sur la révocation ; OpenID4VCI rend la claim de statut facultative. TS3 ne l'autorise pas pour les EUDI Wallets. La WIA vit déjà moins de 24 heures, mais la WIA comme la Key Attestation doivent porter une référence de statut que le Fournisseur de Portefeuille maintient pendant au moins 31 jours, car les PID Providers s'en servent pour révoquer des PID longtemps après l'émission.
WUA, WIA et KA : quel terme désigne quoi
La terminologie a évolué à mesure que les spécifications mûrissaient. TS3 appelait la WIA Wallet App Attestation jusqu'à la version 1.1, et employait WUA pour ce qui est aujourd'hui la Key Attestation jusqu'à la version 1.5. Les articles plus anciens et les projets de l'ARF utilisent donc les termes différemment.
| Terme | Ce qu'elle couvre | Qui la reçoit |
|---|---|---|
| WUA | Terme générique désignant les deux attestations ci-dessous | Les PID Providers et Attestation Providers, uniquement lors de l'émission |
| WIA | La Wallet Instance, c'est-à-dire l'application | L'Authorization Server, dans la Pushed Authorization Request et la Token Request |
| KA | Un WSCD ou keystore et les clés qu'il conserve | Le Credential Issuer, dans les proofs de la Credential Request |
Termes associés
Questions fréquentes
Une WUA est-elle la même chose qu'une Wallet Instance Attestation ?
Non. Depuis la version 1.5 de TS3, WUA est le terme générique désignant deux attestations : la Wallet Instance Attestation (WIA), qui couvre l'application, et la Key Attestation (KA), qui couvre le WSCD ou keystore détenant les clés. Les documents plus anciens emploient WUA pour ce qu'on appelle aujourd'hui la Key Attestation, d'où la confusion fréquente entre les termes.
Un vérificateur voit-il un jour la WUA ?
Non. Les exigences WUA_07 et WUA_24 de l'ARF n'autorisent une unité de portefeuille à présenter une WIA ou une Key Attestation qu'à un PID Provider ou un Attestation Provider lors de l'émission, jamais à une partie utilisatrice. Un vérificateur contrôle plutôt le credential : sa signature, son lien à l'appareil et son statut de révocation. Si le portefeuille derrière un PID est révoqué, le PID Provider révoque le PID dans son cycle de contrôle de 24 heures, et le vérificateur le constate via le statut propre du PID.
Combien de temps une WUA est-elle valide ?
Une WIA expire moins de 24 heures après que le Fournisseur de Portefeuille a vérifié l'intégrité de l'application. Une Key Attestation peut être valide plus longtemps, à la discrétion du Fournisseur de Portefeuille. Par ailleurs, chacune porte une date de maintien du statut, client_status.exp ou key_storage_status.exp, jusqu'à laquelle le Fournisseur de Portefeuille tient le statut de révocation à jour. L'unité de portefeuille doit toujours pouvoir en présenter une dont cette date se situe au moins 31 jours plus tard, et un PID doit expirer avant cette date.
Que se passe-t-il si une unité de portefeuille est compromise avant l'expiration de sa WUA ?
Le Fournisseur de Portefeuille révoque la Wallet Instance sur sa Status List de WIA ou, en cas de vulnérabilité touchant un type de WSCD ou de keystore, l'entrée de la Status List correspondant à ce stockage. Un PID Provider vérifie au moins une fois toutes les 24 heures le statut de la WIA et de la Key Attestation associées à chaque PID qu'il a émis, et révoque le PID si l'une ou l'autre est révoquée. Les Attestation Providers peuvent faire de même. Ce n'est pas l'expiration de la WUA elle-même qui écarte le portefeuille, mais la révocation des credentials qui lui ont été délivrés.
Une Key Attestation peut-elle couvrir plus d'une clé ?
Oui. attested_keys peut lister plusieurs clés publiques issues du même WSCD ou keystore, et c'est ainsi que fonctionne l'émission par lots : l'émetteur lie chaque credential du lot à une clé différente, et une seule signature du Fournisseur de Portefeuille les couvre toutes. Lorsque la Key Attestation est transmise dans un proof jwt, l'unité de portefeuille signe ce proof uniquement avec la première clé de la liste.
Sources
Cette page est informative et ne constitue pas un avis juridique. Pour des conseils faisant autorité, consultez directement la Commission européenne et l'OpenID Foundation.