WUA explicado: como uma carteira se identifica perante um emissor
Um Wallet Unit Attestation, WUA, é o que uma EUDI Wallet mostra a um PID Provider ou Attestation Provider durante a emissão para provar que é genuína. Não é um documento, mas dois, ambos assinados pelo Fornecedor de Carteira: um Wallet Instance Attestation (WIA) sobre a aplicação da carteira, e uma Key Attestation (KA) sobre o armazenamento seguro das chaves às quais uma credencial ficará associada.
O problema que um WUA resolve
Um emissor prestes a entregar um PID ou uma credencial de registo comercial a uma carteira não tem forma nativa de distinguir uma EUDI Wallet certificada de uma aplicação modificada ou de um script que repete um fluxo de autorização. Também não consegue ver se a chave à qual a credencial ficará associada reside em hardware seguro certificado ou em armazenamento comum de onde poderia ser copiada.
O WUA resolve ambas as lacunas. O Fornecedor de Carteira garante a aplicação através do WIA e o armazenamento de chaves através da Key Attestation. O emissor verifica ambos antes de emitir e continua a verificar o seu estado de revogação depois, para poder revogar o que emitiu se mais tarde se descobrir que a carteira ou o seu armazenamento de chaves foi comprometido.
Um WUA só é usado durante a emissão. O ARF proíbe que uma Unidade de Carteira apresente um WIA ou uma Key Attestation a uma Relying Party, o que mantém os dados da carteira fora de todas as apresentações.
Os intervenientes e quem confia em quem
Estão envolvidos cinco papéis, e apenas quatro deles lidam alguma vez com um WUA. O WSCD (Wallet Secure Cryptographic Device) ou um keystore gera e protege as chaves, o Fornecedor de Carteira garante a aplicação e as chaves, e o emissor confia nisso em vez de avaliar a própria carteira.
Fornecedor de Carteira
Assina WIAs e Key Attestations depois de verificar a aplicação e o armazenamento de chaves, e gere as Status Lists de ambos
Unidade de Carteira
Envia um WIA e uma Key Attestation ao emissor durante a emissão, e usa cada um apenas para uma emissão
WSCD ou keystore
Gera e guarda as chaves privadas que uma Key Attestation descreve
PID Provider ou Attestation Provider
Verifica o WIA e a Key Attestation, associa a credencial a uma chave atestada e continua a verificar a revogação de ambos
Relying Party
Nunca recebe um WUA. Em vez disso, verifica a credencial, a sua associação ao dispositivo e o seu estado de revogação
Os emissores confiam num WUA porque o certificado de assinatura do Fornecedor de Carteira, enviado no cabeçalho x5c, se encadeia até uma âncora de confiança na Trusted List de Fornecedores de Carteira. A própria Wallet Solution é certificada por um organismo de avaliação da conformidade, e o WIA contém essa informação de certificação.
Dois atestados com um só nome
O TS3, a especificação técnica EUDI para WUAs, divide o atestado em dois porque a aplicação e o armazenamento de chaves são coisas diferentes, verificadas em endpoints diferentes e revogadas por motivos diferentes.
Wallet Instance Attestation (WIA)
- Atesta
- A integridade da Wallet Instance, ou seja, da aplicação
- Enviado para
- O Authorization Server, no Pushed Authorization Request e no Token Request
- Validade
- Menos de 24 horas
- Revogação
- client_status: o estado de revogação desta Wallet Instance
- Necessário para
- Todas as emissões, associadas ao dispositivo ou não
Key Attestation (KA)
- Atesta
- Que uma ou mais chaves foram geradas e são guardadas por um WSCD ou keystore identificado, e o grau de resistência desse armazenamento a ataques
- Enviado para
- O Credential Issuer, dentro das proofs do Credential Request
- Validade
- Definida pelo Fornecedor de Carteira, e pode ser mais longa do que a de um WIA
- Revogação
- key_storage_status: o estado de revogação do WSCD ou keystore
- Necessário para
- Apenas credenciais associadas ao dispositivo, incluindo todos os PID
Ambos são JWTs assinados pelo Fornecedor de Carteira com ES256, ES384 ou ES512. Uma Key Attestation é usada apenas para uma emissão, e um WIA nunca é reutilizado junto de outro emissor, pelo que os emissores não conseguem relacionar pedidos da mesma carteira.
Como uma Unidade de Carteira obtém os seus WIAs e Key Attestations
O TS3 deixa este passo a cada Fornecedor de Carteira, uma vez que acontece dentro de um único produto de carteira. O ARF apenas exige que o Fornecedor de Carteira verifique a integridade da aplicação antes de assinar um WIA, e que verifique que as chaves privadas atestadas estão realmente no WSCD ou keystore indicado antes de assinar uma Key Attestation. Um fluxo típico, que usa atestados da plataforma como Google Play Integrity ou Apple DeviceCheck como prova, é o seguinte.
1. Unidade de Carteira
Pede ao WSCD ou keystore que gere pares de chaves
2. WSCD ou keystore
Devolve as chaves públicas, com provas da plataforma sobre o local onde foram geradas
3. Fornecedor de Carteira
Verifica a integridade da aplicação e as provas das chaves, e depois assina WIAs e Key Attestations
4. Unidade de Carteira
Mantém uma reserva de WIAs e Key Attestations novos, e usa um novo em cada emissão
O que contêm um WIA e uma Key Attestation
Nenhum dos dois contém uma claim iss: o emissor identifica o Fornecedor de Carteira a partir do certificado de assinatura no cabeçalho x5c. Os exemplos abaixo estão descodificados, com o cabeçalho e o payload separados por um ponto.
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 | O que indica ao emissor |
|---|---|
| typ / x5c | Que se trata de um client attestation, e a cadeia de certificados do Fornecedor de Carteira a verificar face à Trusted List |
| sub | O tipo de carteira, igual em todas as instalações, pelo que não pode ser usado para rastrear um utilizador |
| wallet_name / wallet_version | A Wallet Solution tal como consta da Trusted List, e a sua versão |
| wallet_solution_certification_information | Quem certificou a Wallet Solution; o conteúdo exato ainda está por definir |
| exp | Expiração técnica, menos de 24 horas após a verificação de integridade |
| client_status | Uma entrada da Status List para esta Wallet Instance, e a data até à qual o Fornecedor de Carteira a mantém atualizada |
| cnf | A chave que assina a prova de posse enviada juntamente com o 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 | O que indica ao emissor |
|---|---|
| typ / x5c | Que se trata de uma key attestation, e a cadeia de certificados do Fornecedor de Carteira a verificar face à Trusted List |
| iat / exp | Quando foi emitida e quando expira tecnicamente |
| attested_keys | Chaves públicas cujas chaves privadas o WSCD ou keystore gerou e guarda; várias chaves permitem a emissão em lote |
| key_storage / user_authentication | O grau de resistência a ataques do armazenamento e da autenticação do utilizador que desbloqueia as chaves; um WSCD é sempre iso_18045_high em ambos |
| certification | A certificação do WSCD ou keystore, a partir da qual o emissor consegue saber se se trata de um WSCD |
| key_storage_status | Uma entrada da Status List para o WSCD ou keystore, e a data até à qual o Fornecedor de Carteira a mantém atualizada |
| nonce | O c_nonce do emissor, presente apenas quando a Key Attestation é enviada como attestation proof |
Por onde passa um WUA durante a emissão OpenID4VCI
Os dois atestados seguem para destinos diferentes. O WIA autentica a carteira como cliente OAuth junto do Authorization Server. A Key Attestation vai para o Credential Issuer com o pedido da própria credencial.
O Authorization Server recebe o WIA
- A assinatura do WIA encadeia-se até à Trusted List de Fornecedores de Carteira
- O WIA não expirou e a Wallet Instance não está revogada
- A prova de posse está assinada com a chave da claim cnf do WIA
O Credential Issuer recebe a Key Attestation
- A assinatura da Key Attestation encadeia-se até à Trusted List de Fornecedores de Carteira
- O c_nonce recente do emissor está na jwt proof ou na própria Key Attestation
- O WSCD ou keystore não está revogado, e a credencial fica associada a uma das attested_keys
Pushed Authorization Request com o 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>
O client_id corresponde ao sub do WIA. O Token Request contém os mesmos dois cabeçalhos. Como o Credential Issuer nunca vê o WIA, o Authorization Server tem de lhe transmitir o client_status, por exemplo dentro do access token.
Credential Request com a 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]>"]
}
}Com o tipo de proof attestation, o pedido contém antes "proofs": { "attestation": ["<JWT da Key Attestation>"] }. Nesse caso não há prova de posse: a Unidade de Carteira passa o c_nonce do emissor ao Fornecedor de Carteira, que o coloca numa Key Attestation acabada de assinar.
O ciclo de vida do WUA
Um WUA tem, propositadamente, uma vida curta e utilização única, mas a informação de revogação por trás dele sobrevive ao próprio token. As três primeiras fases são rotineiras; a quarta só ocorre quando algo corre mal.
1. Emissão
O Fornecedor de Carteira assina WIAs e Key Attestations depois das suas verificações de integridade e de armazenamento de chaves
2. Utilização única
Cada um serve para uma única emissão, por isso a Unidade de Carteira continua a obter novos
3. Revogação em cadeia
Um PID Provider volta a verificar o estado do WIA e da Key Attestation pelo menos a cada 24 horas, e revoga o PID se algum deles estiver revogado
4. Revogação
O Fornecedor de Carteira revoga uma Wallet Instance, por exemplo após perda ou roubo, ou um WSCD ou keystore com uma vulnerabilidade de segurança
Fora do ecossistema EUDI Wallet, alguns Fornecedores de Carteira emitem atestados de carteira com uma validade muito curta e sem qualquer referência de estado, confiando na expiração em vez da revogação; o OpenID4VCI torna a claim de estado opcional. O TS3 não permite isso para EUDI Wallets. O WIA já dura menos de 24 horas, mas tanto o WIA como a Key Attestation têm de conter uma referência de estado que o Fornecedor de Carteira mantém durante pelo menos 31 dias, porque os PID Providers a usam para revogar PIDs muito depois da emissão.
WUA, WIA e KA: o que significa cada termo
A terminologia mudou à medida que as especificações amadureceram. O TS3 chamava ao WIA Wallet App Attestation até à versão 1.1, e usou WUA para o que é hoje a Key Attestation até à versão 1.5. Por isso, artigos mais antigos e versões preliminares do ARF usam os termos de forma diferente.
| Termo | O que abrange | Quem o recebe |
|---|---|---|
| WUA | Termo abrangente para os dois atestados abaixo | PID Providers e Attestation Providers, apenas durante a emissão |
| WIA | A Wallet Instance, ou seja, a aplicação | O Authorization Server, no Pushed Authorization Request e no Token Request |
| KA | Um WSCD ou keystore e as chaves que guarda | O Credential Issuer, nas proofs do Credential Request |
Termos relacionados
Perguntas frequentes
Um WUA é o mesmo que um Wallet Instance Attestation?
Não. Desde a versão 1.5 do TS3, WUA é o termo abrangente para dois atestados: o Wallet Instance Attestation (WIA), que abrange a aplicação, e a Key Attestation (KA), que abrange o WSCD ou keystore onde estão as chaves. Documentos mais antigos usam WUA para aquilo a que hoje se chama Key Attestation, e é por isso que os termos são frequentemente confundidos.
Um verificador chega alguma vez a ver o WUA?
Não. Os requisitos do ARF WUA_07 e WUA_24 só permitem que uma Unidade de Carteira apresente um WIA ou uma Key Attestation a um PID Provider ou Attestation Provider durante a emissão, nunca a uma Relying Party. Em vez disso, o verificador verifica a credencial: a assinatura, a associação ao dispositivo e o estado de revogação. Se a carteira por trás de um PID for revogada, o PID Provider revoga o PID dentro do seu ciclo de verificação de 24 horas, e o verificador vê isso através do estado do próprio PID.
Durante quanto tempo é válido um WUA?
Um WIA expira menos de 24 horas depois de o Fornecedor de Carteira ter verificado a integridade da aplicação. Uma Key Attestation pode ser válida durante mais tempo, ao critério do Fornecedor de Carteira. Além disso, cada um contém uma data de manutenção do estado, client_status.exp ou key_storage_status.exp, até à qual o Fornecedor de Carteira mantém o estado de revogação atualizado. A Unidade de Carteira tem de conseguir apresentar sempre um cuja data esteja a pelo menos 31 dias de distância, e um PID tem de expirar antes dessa data.
O que acontece se uma unidade de carteira for comprometida antes de o seu WUA expirar?
O Fornecedor de Carteira revoga a Wallet Instance na sua Status List de WIA ou, no caso de uma vulnerabilidade num tipo de WSCD ou keystore, a entrada da Status List desse armazenamento. Um PID Provider verifica o estado do WIA e da Key Attestation por trás de cada PID que emitiu pelo menos uma vez a cada 24 horas, e revoga o PID quando algum deles está revogado. Os Attestation Providers podem fazer o mesmo. Não é a expiração do próprio WUA que afasta a carteira, mas sim a revogação das credenciais que lhe foram emitidas.
Uma Key Attestation pode abranger mais do que uma chave?
Sim. attested_keys pode listar várias chaves públicas do mesmo WSCD ou keystore, e é assim que funciona a emissão em lote: o emissor associa cada credencial do lote a uma chave diferente, e uma única assinatura do Fornecedor de Carteira abrange todas. Quando a Key Attestation segue numa jwt proof, a Unidade de Carteira assina essa proof apenas com a primeira chave da lista.
Fontes
Esta página tem caráter informativo e não constitui aconselhamento jurídico. Para orientação oficial, consulte diretamente a Comissão Europeia e a OpenID Foundation.