WUA explicada: cómo demuestra una cartera ante un emisor que es genuina
Una Wallet Unit Attestation, WUA, es lo que un EUDI Wallet muestra a un PID Provider o Attestation Provider durante la emisión para demostrar que es genuino. No es un documento sino dos, ambos firmados por el Proveedor de Cartera: una Wallet Instance Attestation (WIA) sobre la aplicación de cartera y una Key Attestation (KA) sobre el almacenamiento seguro de las claves a las que se vinculará una credencial.
El problema que resuelve una WUA
Un emisor que va a entregar un PID o una credencial de registro empresarial a una cartera no tiene una forma integrada de distinguir un EUDI Wallet certificado de una aplicación modificada o de un script que repite un flujo de autorización. Tampoco puede ver si la clave a la que se vinculará la credencial reside en hardware seguro certificado o en un almacenamiento corriente del que podría copiarse.
La WUA cierra ambas brechas. El Proveedor de Cartera responde por la aplicación mediante la WIA y por el almacenamiento de claves mediante la Key Attestation. El emisor comprueba ambas antes de emitir y sigue comprobando después su estado de revocación, de modo que puede revocar lo que emitió si más adelante se descubre que la cartera o su almacenamiento de claves están comprometidos.
Una WUA solo se usa durante la emisión. El ARF prohíbe que una unidad de cartera presente una WIA o una Key Attestation a una parte usuaria, lo que mantiene los datos de la cartera fuera de cualquier presentación.
Los actores y quién confía en quién
Intervienen cinco roles, y solo cuatro de ellos manejan alguna vez una WUA. El WSCD (Wallet Secure Cryptographic Device) o un keystore genera y custodia las claves, el Proveedor de Cartera responde por la aplicación y las claves, y el emisor confía en esa garantía en lugar de evaluar él mismo la cartera.
Proveedor de Cartera
Firma las WIA y las Key Attestations tras comprobar la aplicación y el almacenamiento de claves, y gestiona las Status Lists de ambas
Unidad de Cartera
Envía una WIA y una Key Attestation al emisor durante la emisión, y usa cada una para una sola emisión
WSCD o keystore
Genera y guarda las claves privadas que describe una Key Attestation
PID Provider o Attestation Provider
Verifica la WIA y la Key Attestation, vincula la credencial a una clave atestada y sigue comprobando la revocación de ambas
Parte usuaria
Nunca recibe una WUA. En su lugar comprueba la credencial, su vinculación al dispositivo y su estado de revocación
Los emisores confían en una WUA porque el certificado de firma del Proveedor de Cartera, enviado en la cabecera x5c, se encadena hasta un trust anchor de la Trusted List de Proveedores de Cartera. La propia Wallet Solution está certificada por un organismo de evaluación de la conformidad, y la WIA incluye esa información de certificación.
Dos atestaciones bajo un mismo nombre
TS3, la especificación técnica de EUDI para las WUA, divide la atestación en dos porque la aplicación y el almacenamiento de claves son cosas distintas, que se comprueban en endpoints distintos y se revocan por motivos distintos.
Wallet Instance Attestation (WIA)
- Certifica
- La integridad de la Wallet Instance, es decir, la aplicación
- Se envía a
- El Authorization Server, en la Pushed Authorization Request y la Token Request
- Vida útil
- Menos de 24 horas
- Revocación
- client_status: el estado de revocación de esta Wallet Instance
- Necesaria para
- Toda emisión, esté vinculada al dispositivo o no
Key Attestation (KA)
- Certifica
- Que una o más claves se generaron en un WSCD o keystore concreto y se guardan en él, y hasta qué punto ese almacenamiento resiste ataques
- Se envía a
- El Credential Issuer, dentro de los proofs de la Credential Request
- Vida útil
- La elige el Proveedor de Cartera, y puede ser más larga que la de una WIA
- Revocación
- key_storage_status: el estado de revocación del WSCD o keystore
- Necesaria para
- Solo credenciales vinculadas al dispositivo, incluido todo PID
Ambas son JWT firmados por el Proveedor de Cartera con ES256, ES384 o ES512. Una Key Attestation se usa para una sola emisión y una WIA nunca se reutiliza ante otro emisor, de modo que los emisores no pueden vincular solicitudes de la misma cartera.
Cómo obtiene una unidad de cartera sus WIA y Key Attestations
TS3 deja este paso en manos de cada Proveedor de Cartera, ya que ocurre dentro de un mismo producto de cartera. El ARF solo exige que el Proveedor de Cartera verifique la integridad de la aplicación antes de firmar una WIA, y que verifique que las claves privadas atestadas residen realmente en el WSCD o keystore indicado antes de firmar una Key Attestation. Un flujo típico, que usa como evidencia atestaciones de plataforma como Google Play Integrity o Apple DeviceCheck, es el siguiente.
1. Unidad de Cartera
Pide al WSCD o keystore que genere pares de claves
2. WSCD o keystore
Devuelve las claves públicas, con evidencias de la plataforma sobre dónde se generaron
3. Proveedor de Cartera
Comprueba la integridad de la aplicación y las evidencias de las claves, y luego firma las WIA y las Key Attestations
4. Unidad de Cartera
Mantiene una reserva de WIA y Key Attestations nuevas, y usa una distinta en cada emisión
Qué contienen una WIA y una Key Attestation
Ninguna de las dos lleva una claim iss: el emisor identifica al Proveedor de Cartera por el certificado de firma de la cabecera x5c. Los ejemplos siguientes están decodificados, con la cabecera y el payload separados por un punto.
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": "..." }
}
}| Campo | Qué le indica al emisor |
|---|---|
| typ / x5c | Que se trata de una client attestation, y la cadena de certificados del Proveedor de Cartera para comprobarla con la Trusted List |
| sub | El tipo de cartera, igual para todas las instalaciones, de modo que no puede usarse para rastrear a un usuario |
| wallet_name / wallet_version | La Wallet Solution tal como figura en la Trusted List, y su versión |
| wallet_solution_certification_information | Quién certificó la Wallet Solution; el contenido exacto aún está por definir |
| exp | Caducidad técnica, menos de 24 horas después de la comprobación de integridad |
| client_status | Una entrada de Status List para esta Wallet Instance, y la fecha hasta la cual el Proveedor de Cartera la mantiene actualizada |
| cnf | La clave que firma la prueba de posesión enviada junto con 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
}
}| Campo | Qué le indica al emisor |
|---|---|
| typ / x5c | Que se trata de una key attestation, y la cadena de certificados del Proveedor de Cartera para comprobarla con la Trusted List |
| iat / exp | Cuándo se emitió y cuándo caduca técnicamente |
| attested_keys | Claves públicas cuyas claves privadas generó y guarda el WSCD o keystore; varias claves permiten la emisión por lotes |
| key_storage / user_authentication | Hasta qué punto resisten ataques el almacenamiento y la autenticación del usuario que desbloquea las claves; un WSCD es siempre iso_18045_high en ambos |
| certification | La certificación del WSCD o keystore, a partir de la cual el emisor puede saber si se trata de un WSCD |
| key_storage_status | Una entrada de Status List para el WSCD o keystore, y la fecha hasta la cual el Proveedor de Cartera la mantiene actualizada |
| nonce | El c_nonce del emisor, presente solo cuando la Key Attestation se envía como proof de tipo attestation |
Adónde viaja una WUA durante la emisión mediante OpenID4VCI
Las dos atestaciones van a sitios distintos. La WIA autentica la cartera como cliente OAuth ante el Authorization Server. La Key Attestation va al Credential Issuer junto con la solicitud de la propia credencial.
El Authorization Server recibe la WIA
- La firma de la WIA se encadena hasta la Trusted List de Proveedores de Cartera
- La WIA no ha caducado y la Wallet Instance no está revocada
- La prueba de posesión está firmada con la clave de la claim cnf de la WIA
El Credential Issuer recibe la Key Attestation
- La firma de la Key Attestation se encadena hasta la Trusted List de Proveedores de Cartera
- El c_nonce reciente del emisor figura en el proof jwt o en la propia Key Attestation
- El WSCD o keystore no está revocado, y la credencial está vinculada a una de las attested_keys
Pushed Authorization Request con 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>
El client_id coincide con el sub de la WIA. La Token Request lleva las mismas dos cabeceras. Como el Credential Issuer nunca ve la WIA, el Authorization Server tiene que transmitirle su client_status, por ejemplo dentro del access token.
Credential Request con 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]>"]
}
}Con el tipo de proof attestation, la solicitud lleva en su lugar "proofs": { "attestation": ["<JWT de la Key Attestation>"] }. En ese caso no hay prueba de posesión: la unidad de cartera pasa el c_nonce del emisor al Proveedor de Cartera, que lo incluye en una Key Attestation recién firmada.
El ciclo de vida de una WUA
Una WUA es deliberadamente de corta duración y de un solo uso, pero la información de revocación que la respalda sobrevive al propio token. Las tres primeras etapas son rutinarias; la cuarta solo ocurre cuando algo sale mal.
1. Emisión
El Proveedor de Cartera firma las WIA y las Key Attestations tras sus comprobaciones de integridad y de almacenamiento de claves
2. Un solo uso
Cada una sirve para una única emisión, así que la unidad de cartera obtiene continuamente otras nuevas
3. Revocación en cadena
Un PID Provider vuelve a comprobar el estado de la WIA y de la Key Attestation al menos cada 24 horas, y revoca el PID si cualquiera de ellas está revocada
4. Revocación
El Proveedor de Cartera revoca una Wallet Instance, por ejemplo tras una pérdida o un robo, o un WSCD o keystore con una vulnerabilidad de seguridad
Fuera del ecosistema del EUDI Wallet, algunos Proveedores de Cartera emiten atestaciones de cartera de vida muy corta y sin ninguna referencia de estado, y confían en la caducidad en lugar de la revocación; OpenID4VCI hace opcional la claim de estado. TS3 no lo permite para los EUDI Wallets. La WIA ya vive menos de 24 horas, pero tanto la WIA como la Key Attestation deben llevar una referencia de estado que el Proveedor de Cartera mantenga durante al menos 31 días, porque los PID Providers la usan para revocar PID mucho después de la emisión.
WUA, WIA y KA: qué significa cada término
La terminología cambió a medida que maduraban las especificaciones. TS3 llamó a la WIA Wallet App Attestation hasta la versión 1.1, y usó WUA para lo que ahora es la Key Attestation hasta la versión 1.5. Por eso los artículos más antiguos y los borradores del ARF usan los términos de otra manera.
| Término | Qué cubre | Quién la recibe |
|---|---|---|
| WUA | Término general para las dos atestaciones siguientes | PID Providers y Attestation Providers, solo durante la emisión |
| WIA | La Wallet Instance, es decir, la aplicación | El Authorization Server, en la Pushed Authorization Request y la Token Request |
| KA | Un WSCD o keystore y las claves que guarda | El Credential Issuer, en los proofs de la Credential Request |
Términos relacionados
Preguntas frecuentes
¿Es una WUA lo mismo que una Wallet Instance Attestation?
No. Desde la versión 1.5 de TS3, WUA es el término general para dos atestaciones: la Wallet Instance Attestation (WIA), que cubre la aplicación, y la Key Attestation (KA), que cubre el WSCD o keystore que guarda las claves. Los documentos más antiguos usan WUA para lo que ahora se llama Key Attestation, y por eso los términos se confunden a menudo.
¿Llega a ver un verificador la WUA?
No. Los requisitos del ARF WUA_07 y WUA_24 solo permiten a una unidad de cartera presentar una WIA o una Key Attestation a un PID Provider o Attestation Provider durante la emisión, nunca a una parte usuaria. El verificador comprueba en su lugar la credencial: su firma, su vinculación al dispositivo y su estado de revocación. Si se revoca la cartera que hay detrás de un PID, el PID Provider revoca el PID dentro de su ciclo de comprobación de 24 horas, y el verificador lo ve a través del propio estado del PID.
¿Cuánto tiempo es válida una WUA?
Una WIA caduca menos de 24 horas después de que el Proveedor de Cartera haya comprobado la integridad de la aplicación. Una Key Attestation puede ser válida durante más tiempo, a criterio del Proveedor de Cartera. Además, cada una lleva una fecha de mantenimiento del estado, client_status.exp o key_storage_status.exp, hasta la cual el Proveedor de Cartera mantiene actualizado el estado de revocación. La unidad de cartera debe poder presentar siempre una cuya fecha esté al menos a 31 días vista, y un PID debe caducar antes de esa fecha.
¿Qué ocurre si una unidad de cartera se ve comprometida antes de que caduque su WUA?
El Proveedor de Cartera revoca la Wallet Instance en su Status List de WIA o, ante una vulnerabilidad en un tipo de WSCD o keystore, la entrada de la Status List correspondiente a ese almacenamiento. Un PID Provider comprueba al menos una vez cada 24 horas el estado de la WIA y la Key Attestation que respaldan cada PID que ha emitido, y revoca el PID cuando cualquiera de ellas está revocada. Los Attestation Providers pueden hacer lo mismo. Lo que expulsa a la cartera no es la caducidad de la propia WUA, sino la revocación de las credenciales que se le emitieron.
¿Puede una Key Attestation cubrir más de una clave?
Sí. attested_keys puede enumerar varias claves públicas del mismo WSCD o keystore, y así funciona la emisión por lotes: el emisor vincula cada credencial del lote a una clave distinta, y una sola firma del Proveedor de Cartera las cubre todas. Cuando la Key Attestation viaja en un proof jwt, la unidad de cartera firma ese proof solo con la primera clave de la lista.
Fuentes
Esta página tiene carácter informativo y no constituye asesoramiento jurídico. Para obtener orientación autorizada, consulte directamente a la Comisión Europea y a la OpenID Foundation.