Vinculação ao titular na EUDI Wallet: o que uma apresentação realmente prova
O problema da posse a partir do texto primário: o que uma apresentação da carteira prova, o que o ARF v3.0.0 diz sobre User binding e o retrato, tabela de ameaças e desenho de step-up baseado em risco para equipes reguladas.
Em resumo
A vinculação ao titular na carteira europeia de identidade digital (EUDI Wallet) é o elo entre a pessoa que apresenta a carteira e a pessoa a quem os dados de identidade foram emitidos. O Architecture and Reference Framework (ARF) chama isso de vinculação ao usuário, e na maioria das apresentações a parte utilizadora confia nesse elo em vez de verificá-lo.[2]
- Uma apresentação verificada e vinculada ao dispositivo prova que os dados são autênticos e não foram alterados e que a carteira detém a chave vinculada.[2]
- Ela não prova quem está com o celular no seu próximo login, saque ou redefinição de senha.
- O nível elevado é uma garantia real. Mantenha a carteira como padrão e acrescente verificações faciais apenas onde o risco as justificar.
Este é o problema da posse. Uma assinatura da carteira mostra que uma chave foi usada. É preciso uma cadeia de confiança para ir dessa chave até um ser humano, e o último elo fica em um celular que você não controla.
Nada disso torna a carteira fraca. Ela é emitida no âmbito de um sistema com nível de garantia elevado, e uma equipe que a trata como suspeita a desperdiça. Este guia mostra o que ela responde, o que deixa em aberto e como fechar essa lacuna.
Para registro e certificados, leia nosso guia para partes utilizadoras. Para escolher a via de integração, leia como escolher uma plataforma de integração da EUDI Wallet.
O que uma apresentação da carteira realmente prova
Uma apresentação remota executa várias verificações em sequência. Algumas são suas e outras acontecem dentro da carteira, onde você não consegue vê-las.
Você nunca vê a etapa 3
Verificar assinatura e status
Verificar vinculação ao dispositivo
Apresentação remota simplificada, baseada na seção 6.6.3 do ARF v3.0.0. As etapas 1, 2 e 4 são visíveis para você ou para a pessoa. A etapa 3 não é.[2]
| Camada | O que estabelece | Quem verifica | Status para você | Limite |
|---|---|---|---|---|
| Assinatura do emissor | Os dados vêm de um provedor autêntico e não foram alterados[2] | Você | O artigo 5b(9) atribui isso às partes utilizadoras, para PID e atestações[1] | Não diz nada sobre quem está apresentando |
| Status de revogação | Os dados não foram revogados pelo seu provedor[2] | Você | Recomendado, não obrigatório[3] | Só é tão atualizado quanto a fonte de status |
| Vinculação ao dispositivo | Os dados estão na unidade de carteira para a qual foram emitidos, não em uma cópia[2] | Você | Recomendado, mas obrigatório se você se apoiar na autenticação da própria carteira[2] | Comprova uma chave, não uma pessoa |
| Integridade da carteira | A unidade de carteira e seu hardware seguro eram válidos no momento da emissão[2] | O provedor dos dados, durante a emissão[2] | Você confia nisso de forma indireta[2] | Você não tem como verificar isso diretamente[2] |
| Autenticação do usuário | A carteira autenticou o usuário antes de liberar os dados[2][6] | A carteira | Você confia nisso de forma indireta[2] | Nenhum resultado chega até você |
O ARF v3.0.0 divide o atestado da unidade de carteira previsto no regulamento em um Wallet Instance Attestation, sobre a integridade e o status de revogação do aplicativo, e um Key Attestation, sobre o armazenamento seguro que guarda as chaves.[2] Sobre a sua posição: "The Relying Party Instance does not have a way to directly verify the authenticity of the Wallet Unit and the Wallet Provider." (A instância da parte utilizadora não tem como verificar diretamente a autenticidade da unidade de carteira e do provedor da carteira.)[2]
Figura 12 do ARF: o usuário acessa a unidade de carteira por um vínculo de autenticação que a parte utilizadora nunca vê. Fonte: EUDI Wallet Architecture and Reference Framework, Comissão Europeia, CC BY 4.0. Sem adaptações.
Cubra a lacuna que a carteira deixa aberta
Faça prova de vida e comparação facial nas ações que trazem risco real, no fluxo que você já usa hoje para verificação. Comece grátis ou fale com a gente.
Vinculação ao dispositivo, vinculação ao titular e a lacuna que fica depois delas
Três vínculos diferentes acabam reunidos sob "vinculação ao titular". Os dois primeiros são conceitos do ARF. O terceiro é um rótulo nosso.
Chave à carteira
Vinculação ao dispositivo
- Os dados ficam vinculados a uma chave em hardware seguro[2]
- Também chamada de prova de posse[2]
- Impede cópia e reutilização[2]
Verificado por você
Da carteira à pessoa
Vinculação ao usuário
- Quem apresenta é a pessoa a quem os dados foram emitidos[2]
- Depende da vinculação ao dispositivo[2]
- Geralmente presumida, não verificada[2]
Feita pela carteira
Da pessoa à ação
Vinculação à ação
- Esta pessoa realizou esta ação posterior
- Fica fora da apresentação
- Fica na sua sessão e nos seus controles
Só sua (termo nosso)
Vinculação ao dispositivo (device binding) e vinculação ao usuário (user binding) são termos do ARF. Vinculação à ação é um rótulo da Didit, não um termo de nenhuma norma.
O documento de discussão do ARF sobre atestados vinculados ao dispositivo resume a distinção em uma linha: "Um atestado pode estar vinculado a um dispositivo, mas não a um Usuário."[11] A definição que importa é esta.
Seção 6.6.3.9ARF v3.0.0
"A vinculação ao usuário (às vezes também chamada de 'holder binding') é a propriedade de que a pessoa que apresenta o PID ou o atestado à Parte Utilizadora é de fato o Usuário a quem o PID ou o atestado foi emitido."
Fonte: ARF v3.0.0, capítulo 6[2]
Na comunicação, a propriedade que você controla é require_cryptographic_holder_binding no OpenID4VP. O padrão é true, e defini-la como false informa à carteira que você aceita uma credencial sem essa prova.[12] O protocolo diz holder binding onde o ARF diz vinculação ao dispositivo (device binding).[12][2] Mantenha ativada. Nosso guia do verificador OpenID4VP trata das verificações.
O que a lei e o ARF dizem, com suas próprias palavras
Estas disposições regem a emissão e a apresentação pela carteira, não as ações posteriores na sua conta.
| Regra | Texto | O que significa para você |
|---|---|---|
| Art. 5a(4)(a), Regulamento 910/2014 | As carteiras devem permitir que os usuários apresentem dados "sob o controle exclusivo do usuário"[1] | Nossa leitura: um requisito sobre como as carteiras são construídas, não uma conclusão sobre qualquer sessão |
| Art. 5a(5)(d) e 5a(11) | As carteiras cumprem os requisitos do nível de garantia elevado e são fornecidas no âmbito de um sistema de nível de garantia elevado[1] | Base sólida, sem necessidade de prova adicional para esse atributo |
| Art. 5b(9) | As partes utilizadoras são responsáveis por "autenticar e validar" os dados[1] | As verificações de assinatura e de validade são suas |
| Art. 3(5), Regulamento 2024/2977 | Os fornecedores de PID "devem assegurar" que os PID que emitem "estão criptograficamente vinculados à unidade de carteira à qual são emitidos"[4] | Os fornecedores de PID devem vincular os PID à unidade de carteira; você verifica o resultado |
| Art. 3(1), Regulamento 2024/2979 | Nenhuma funcionalidade principal "até que a unidade de carteira tenha autenticado com êxito o usuário da carteira"[6] | A carteira autentica antes de agir |
| Anexo, ponto 2.2.1, Regulamento de Execução 2015/1502 | Para o nível elevado, "O meio de identificação eletrônica é concebido de modo a poder ser protegido de forma fiável pela pessoa a quem pertence contra a utilização por terceiros."[7] | Proteção contra terceiros, à disposição do titular |
| WIAM_14, ARF Anexo 2 | O hardware seguro para PID autentica o usuário em nível elevado antes de operações criptográficas sobre seus ativos críticos[3] | Uma segunda camada de autenticação dentro da carteira |
A seção 6.5.3.3.1 do ARF diz: "Durante a ativação da Unidade de Carteira, a Unidade de Carteira garante que o Usuário configure dois mecanismos de autenticação do Usuário." Um fica no nível do sistema operacional e o outro no hardware criptográfico seguro usado quando um PID é emitido, apresentado ou excluído.[2] O usuário precisa passar pelos dois para apresentar o PID.[2]
A seção 6.6.3.9, sobre confiar nessa autenticação: "Essa confiança não se baseia no resultado de nenhuma verificação feita pela própria Parte Utilizadora", mas na "confiança a priori na Unidade de Carteira certificada e (para PIDs e atestados com nível de segurança Alto) na WSCA/WSCD certificada."[2] (WSCA e WSCD: o aplicativo e o dispositivo criptográficos seguros da carteira.) O ARF acrescenta que confiar nesse método "implica que as Partes Utilizadoras devem verificar a vinculação ao dispositivo".[2]
Assim, o ARF prevê três caminhos para a vinculação ao usuário. Confiar na autenticação da carteira, que sempre é executada. Comparar um retrato contido no PID com o rosto ao vivo. Ou comparar atributos do PID com um documento de identidade que você consiga verificar que pertence de fato à pessoa.[2]
Por que o nível elevado é uma garantia real
O nível elevado exige proteção "contra atacantes com elevado potencial de ataque".[7] A certificação testa essa resistência.[8] Um PID falsificado, uma carteira clonada ou uma resposta reutilizada deveriam falhar. Nossa leitura: o nível elevado descreve o meio e não diz nada sobre um titular real que decide emprestar ou vender o seu uso.
O documento de trabalho Topic R do ARF, de 14 de outubro de 2025, registra que "até hoje os dispositivos móveis não têm meios nem base para atestar às Partes Utilizadoras da Carteira que a autenticação do Usuário foi realizada" e que, na opinião de alguns especialistas, a biometria do dispositivo "não é totalmente confiável".[10] Trata-se de um registro de discussão, não de um requisito.
- 11 de agosto de 2026Regras de confirmação do retratoRegulamento 2026/1731 em vigor: avisos e confirmação explícita.
- 24 de dezembro de 2026Prazo das carteirasCalculado: 24 meses a partir dos atos.
- 10 de julho de 2027Aplicação do AMLRO artigo 22(6) vincula as entidades obrigadas.
- 24 de dezembro de 2027AceitaçãoCalculado: artigo 5f(2). Entidades privadas obrigadas por lei ou por contrato a usar autenticação forte do usuário, a pedido do usuário; microempresas e pequenas empresas isentas.
- 11 de agosto de 2028Retrato no PIDAtributo obrigatório do PID a partir desta data, sujeito a opções de recusa.
As datas de dezembro são cálculo nosso a partir dos artigos 5a(1) e 5f(2), contadas da entrada em vigor dos atos de execução referidos nos artigos 5a(23) e 5c(6) (Regulamentos 2024/2977 a 2024/2982, em vigor em 24 de dezembro de 2024).[1][4][5][13] Veja nosso guia de prazos da carteira europeia de identidade digital (EUDI Wallet).
O retrato: útil, opcional e rigorosamente regulado
O retrato é o meio óbvio de verificar a pessoa. O Regulamento de Execução (UE) 2026/1731, adotado em 15 de julho de 2026 e publicado no Jornal Oficial em 22 de julho de 2026, alterou suas regras.
- Prazo. "o retrato do usuário da carteira poderá fazer parte dos dados de identificação pessoal obrigatórios da pessoa física apenas a partir de 11 de agosto de 2028".[5] Na tabela atual de PID, o retrato é incluído "exceto quando o usuário optar expressamente por não o incluir, se aplicável".[5]
- As opções de recusa continuam. Os Estados-Membros "podem prever que o usuário tenha a opção de recusar a inserção do retrato", e nesse caso o valor fica vazio.[5]
- Aviso da carteira. A carteira avisa que o pedido envolve dados biométricos, e o usuário deve "confirmar de forma explícita e específica a apresentação do retrato".[4] O ARF RPA_07c acrescenta: "O silêncio ou uma caixa pré-assinalada NÃO DEVE bastar."[3]
- Não é uma base legal. O considerando 2 do Regulamento 2026/1731 diz: "A confirmação explícita do usuário da carteira deve ser uma salvaguarda técnica e não constituir, por si só, um fundamento jurídico para o tratamento."[5] O considerando remete aos artigos 6 e 9 do GDPR para a base legal.[5]
- Conservação. O retrato "não deve ser conservado pelas partes que confiam na carteira, salvo se o seu tratamento for necessário para efeitos de identificação e autenticação" nos termos da legislação de proteção de dados, ou se o direito da União ou o direito nacional o previr.[4][5]
- Registro. Nos termos do artigo 5b(3), você não pode solicitar dados além dos que registrou, por isso o retrato deve constar do seu uso registrado.[1]
Para a comparação remota, o ARF exige boa iluminação, instruções claras e "um mecanismo aprovado de detecção de prova de vida que suporte a Presentation Attacks Detection", "bem como mecanismos de detecção de ataques de injeção, em especial detecção de deepfakes".[2] A ENISA detalha os ataques de apresentação facial.[21] A ETSI TS 119 461 define um ataque de injeção como um "ataque que consiste em injetar conteúdo controlado pelo atacante no processo de captura de dados".[23]
Uma verificação facial no celular: a etapa de captura é a superfície de ataque. Ilustração de mikemacmarketing, Wikimedia Commons, CC BY 2.0. Sem adaptações.
A verificação um para um cujo único objetivo é confirmar uma identidade alegada fica excluída da entrada do Anexo III do AI Act sobre identificação biométrica à distância.[16] Os dados biométricos usados para identificar uma pessoa de forma inequívoca continuam integrando as categorias especiais de dados pessoais nos termos do artigo 9 do GDPR, por isso planeje uma base legal e uma avaliação de impacto.[15]
Ameaça por ameaça: o que a carteira impede e o que continua com você
O regulamento de certificação contém um registro de riscos para carteiras. Os identificadores de ameaça abaixo são os oficiais. As duas últimas colunas são a nossa avaliação.[8]
| Ameaça | Registro | Efeito da carteira | O que resta | Seu controle |
|---|---|---|---|---|
| Dados da carteira copiados ou duplicados | TR60 | Forte: vinculação ao dispositivo[2] | Pouco, se você verificar | Mantenha a prova de vinculação ativada |
| Apresentação reproduzida | Tipo 5.3 | Forte: assinatura nova sobre os seus dados[2] | Pouco | Nonce único por pedido |
| Celular roubado, bloqueado | TR98 | Forte: duas camadas de autenticação[2] | Roubo do fator de conhecimento (TR35) | Verificar o status de revogação |
| Dispositivo compartilhado da família | TR35, TR98 | Parcial | Alguém que conhece o PIN ou código[22] | Autenticação reforçada em ações de alto risco |
| Usuário coagido ou manipulado | TR28, TR99 | Fraca: o usuário legítimo aprova | Quase tudo | Monitoramento de transações, período de reflexão, autenticação reforçada com contexto |
| Retransmissão entre dispositivos | TR103 | Parcial: verificação de proximidade[24] | Phishing da sessão do navegador | Mesmo dispositivo sempre que possível, nomeie a ação |
| Autenticação local burlada | TR113 | Depende da certificação[8] | Risco de dispositivo comprometido | Verificação de revogação, sinais do dispositivo |
| Tomada de conta após o onboarding | Fora da carteira | Nenhuma, salvo nova apresentação | Senhas, sessões, fluxos de recuperação | Autenticação reforçada em alterações sensíveis |
| Laranja com uma carteira real | Fora da carteira | Nenhuma: todas as verificações passam | Tudo | Monitoramento de comportamento, vínculos de rede |
O usuário legítimo que aprova
O TR99 diz: "Um atacante pode convencer um usuário a se autenticar e aprovar transações com um atacante ou com um terceiro não autorizado."[8] Todos os fatores são aprovados. A autenticação forte do cliente "continua eficaz contra os tipos de fraude que foi concebida para mitigar", segundo o ECB, e a fraude total reportada no Espaço Econômico Europeu foi de €4.2 bilhões em 2024.[19][20] Nas transferências a crédito, a fraude por manipulação do pagador cresceu "de 65% para 74% em valor e de 55% para 71% em volume, de 2023 para 2024".[19]
Duas pessoas, dois dispositivos
TR103: "O usuário por trás da conexão entre a parte utilizadora e o navegador pode ser diferente do usuário por trás da conexão entre a parte utilizadora e a carteira."[8] A seção 4.4.3.2 do ARF observa que "os fluxos entre dispositivos são vulneráveis a ataques de phishing e de retransmissão", e a seção 4.4.3 torna a verificação de proximidade obrigatória para eles.[24] Sua sessão web continua separada da aprovação na carteira.
Figura 5 do ARF: em um fluxo entre dispositivos, o seu serviço se comunica com um navegador, e a carteira fica em um segundo dispositivo. Fonte: EUDI Wallet Architecture and Reference Framework, Comissão Europeia, CC BY 4.0. Sem adaptações.
A conta laranja com uma carteira real
Uma pessoa que vende o acesso a uma conta, ou que abre uma conta para outra pessoa, passa honestamente por todas as verificações da carteira, porque essa pessoa é a titular. O controle é aquele que o Anti-Money Laundering Regulation (AMLR) já estabelece: "acompanhamento contínuo das relações de negócio".[13] Vínculos entre contas, dispositivos compartilhados e rostos repetidos são os sinais que expõem redes.
Um modelo de reforço que mantém a carteira como padrão
Nenhum texto que lemos exige prova de vida além da carteira. O artigo 22(6)(b) do AMLR lista, como uma das suas opções, "o recurso a meios de identificação eletrônica que cumpram os requisitos do Regulamento (UE) n.º 910/2014 no que respeita aos níveis de garantia 'substancial' ou 'elevado'".[13] As normas técnicas finais em projeto da Anti-Money Laundering Authority (AMLA) dizem que isso "inclui as Carteiras Europeias de Identidade Digital", e essas normas ainda são um projeto, não lei.[14] Veja o nosso guia do AMLR sobre a aceitação de carteiras.
O artigo 20(2) do AMLR deixa a extensão das medidas a "uma análise individual dos riscos".[13] Na nossa visão, uma selfie a cada apresentação é difícil de justificar à luz do princípio da minimização dos dados do GDPR.[15] Esses níveis são uma sugestão nossa, não categorias jurídicas.
1Classifique o evento
Onboarding, login ou uma ação específica, com o seu risco.
Quanto dano uma pessoa errada pode causar
Somente a carteira
Verificações criptográficas completas. Sem biometria.
Adicione prova de vida e comparação facial
Com o retrato, ou com um rosto que você mantém de forma lícita.
Verifique novamente no momento da ação
Nova verificação vinculada a esta ação, depois revisão.
2Registre as evidências
O que foi executado, o resultado, a data. Por padrão, não o retrato.
Um exemplo de fluxo de decisão. Defina os seus próprios limites na sua avaliação de risco.
| Nível | Eventos típicos | Controles | Por quê |
|---|---|---|---|
| Só a carteira | Verificação de idade ou de atributos, abertura de conta padrão, login de baixo risco | Assinatura, vinculação ao dispositivo, status, nonce | O nível elevado faz o trabalho; quanto menos dados, melhor |
| Carteira mais rosto | Cliente de maior risco, dispositivo ou localização incomum, primeiro uso após um longo intervalo | O anterior, mais prova de vida e comparação facial | Responde diretamente à vinculação ao usuário (User binding), como descreve o ARF[2] |
| Nova verificação na ação | Novo beneficiário, pagamento de valor alto, dados bancários alterados, recuperação, inclusão de dispositivo | Nova verificação facial ou aprovação vinculada à transação, mais revisão | Vincula a pessoa àquela ação |
| Sem carteira ou sem retrato | Cliente sem carteira, país com adoção tardia, retrato com opção de recusa | Documento, leitura do chip, prova de vida, comparação facial | O uso da carteira é voluntário[1] |
O PID não pode aprovar uma ação por você: "As unidades de carteira NÃO DEVEM usar uma chave privada do PID para assinar dados transacionais recebidos de uma parte utilizadora num pedido de apresentação."[9] A aprovação de transações cabe aos atestados de autenticação forte do usuário (SUA), que contêm dados transacionais e ficam no tópico do ARF sobre pagamentos eletrônicos.[3] A legislação de pagamentos funciona da mesma forma: o código deve ser "específico do montante da operação de pagamento e do beneficiário".[18] A expressão da PSD2 "qualquer ação através de um canal remoto que possa envolver um risco de fraude no pagamento ou outros abusos" é um modelo de gatilho útil.[17]
Opção
Carteira de novo
- Nova apresentação do PID
- Confirma a carteira de novo
- Sem vínculo com a ação
Bom para login
Opção
Verificação facial
- Prova de vida e comparação facial
- Verifica a pessoa presente
- Precisa de uma referência lícita
Bom para alterações de risco
Opção
Atestação de transação
- Assina os dados da ação
- Mostra ao usuário o que está sendo aprovado
- Depende do suporte do emissor
Bom para pagamentos
Atenção
Não use a chave do PID como identificador do dispositivo. Os provedores podem emitir atestações que são apresentadas uma única vez, para "mitigar o risco de associação pela parte utilizadora".[2] Identifique clientes recorrentes pelos atributos, como explica nosso guia de aceitação transfronteiriça.
Checklist: o que fazer este mês
A política interna por trás destes passos está no nosso guia de políticas e controles da EUDI Wallet, e a decisão sobre o caminho de integração está no guia de plataforma de integração.
Compliance e risco
- Registre quais dos seus eventos dependem apenas da carteira.
- Defina gatilhos de autenticação reforçada para pagamentos a terceiros, alterações de beneficiário e recuperação de conta.
- Defina a sua base legal para qualquer comparação facial.[5][15]
- Atualize o seu relatório de impacto à proteção de dados pessoais para o uso do retrato.[15]
Engenharia
- Mantenha a prova de vinculação ao titular como obrigatória em todas as solicitações.[12]
- Verifique a assinatura de vinculação ao dispositivo em todas as respostas.[2]
- Verifique o status de revogação, mesmo sendo opcional.[3]
- Vincule cada apresentação a uma única sessão com um nonce novo.
- Construa o fluxo do retrato de modo que um valor vazio seja tratado.[5]
Produto e suporte
- Solicite o retrato apenas quando as suas finalidades registradas o incluírem.[1]
- Mantenha um caminho por documento para pessoas sem carteira.[1]
- Escreva o texto de cada autenticação reforçada de modo que ele nomeie a ação.
- Informe aos clientes que eles podem pedir ao provedor da carteira que revogue uma carteira roubada.[6]
Como a Didit ajuda com o problema da posse
A documentação da Didit lista a aceitação da EUDI Wallet com o status Em breve.[28] Nossa página da EUDI Wallet diz "Ainda não existe uma API da Didit específica para a EUDI" e "Integre hoje e mantenha a integração quando a carteira chegar." Esta seção trata do que funciona hoje. A Biometric Authentication executa autenticações reforçadas com prova de vida e comparação facial.
- Reverificação. Biometric Authentication verifica usuários recorrentes apenas com prova de vida, ou com prova de vida e comparação facial com um retrato armazenado, como uma sessão dentro de um fluxo de trabalho.[25][27]
- Presença. A prova de vida verifica se há uma pessoa real diante da câmera, com métodos passivo, de ação 3D ou de flashes.[26]
- Autenticação reforçada. O produto Authentication da Didit documenta uma chamada que aplica as suas regras de autenticação reforçada antes de uma ação sensível e retorna se a verificação é necessária. Ele é novo e é ativado por aplicação.[31]
- Networks. Face Search encontra contas duplicadas, e o Networks agrupa os solicitantes que compartilham sinais de dispositivo, IP, biometria, documento ou contato.[29][30]
- Monitoramento. O Transaction Monitoring analisa as transações em tempo real com um motor de regras configurável e gestão de casos.[32]
- Alternativa. O ID Verification e as eIDs nacionais já em operação atendem os clientes que não têm carteira.[28]
A Didit fornece
- Prova de vida e comparação facial sob demanda
- Rotas por documento e por eID nacional
- Sinais de duplicidade e de rede
- O registro de cada verificação
Fica com você
- A avaliação de risco e a política de autenticação reforçada
- Sua base legal e sua avaliação de impacto
- O registro como parte utilizadora
- Cada decisão de onboarding e de transação
Planos e preços estão na nossa página de preços. Os dados armazenados seguem o prazo de retenção que você configurar, e a Didit atua como seu operador de dados (subcontratante).[33]
Desenhe sua autenticação reforçada conosco
Diga quais ações trazem mais risco e comece com prova de vida e comparação facial no seu fluxo.
Pontos principais
- A vinculação ao dispositivo prova uma chave. A vinculação ao usuário (User binding) liga essa chave a uma pessoa, e normalmente você confia nela em vez de verificá-la.
- O nível de garantia elevado é uma garantia forte sobre a carteira, e não cobre um laranja que age por vontade própria nem um usuário manipulado.
- O retrato passa a integrar os dados obrigatórios do PID a partir de 11 de agosto de 2028, ressalvadas as opções de recusa, e a confirmação do usuário não é uma base legal.
- O PID não pode assinar dados de transação, então ações de alto risco precisam de outra aprovação.
Perguntas frequentes
O que é a vinculação ao titular (holder binding) na carteira europeia de identidade digital (EUDI Wallet)?
A vinculação ao titular é a propriedade de que a pessoa que apresenta os dados é a pessoa para quem eles foram emitidos. O ARF a chama de vinculação ao usuário e diz que às vezes ela também é chamada de holder binding.[2]
Qual é a diferença entre vinculação ao dispositivo e vinculação ao titular?
A vinculação ao dispositivo liga os dados a uma chave no hardware seguro da carteira e impede cópia e reutilização (replay). A vinculação ao titular liga os dados a uma pessoa. O ARF trata a vinculação ao dispositivo como pré-requisito para a vinculação ao usuário (User binding).[2]
A vinculação ao dispositivo é obrigatória para o PID?
Sim, para os fornecedores. O Regulamento de Execução 2024/2977 exige que os fornecedores de PID garantam que o PID que emitem esteja vinculado criptograficamente à unidade de carteira.[4] Para as partes utilizadoras, verificar a assinatura é recomendado, e é obrigatório se você se apoiar na própria autenticação da carteira.[2]
Posso fazer uma comparação facial com o retrato da carteira?
Só se o PID tiver um retrato, se você tiver registrado esse uso, se o usuário confirmar e se houver uma base legal. O retrato passa a integrar os dados obrigatórios do PID a partir de 11 de agosto de 2028, e os Estados-Membros podem permitir que os usuários recusem.[5]
Posso guardar o retrato de uma apresentação feita pela carteira?
Não por padrão. Ele só pode ser conservado se o tratamento for necessário para identificação e autenticação em conformidade com o direito da União em matéria de proteção de dados, ou quando o direito da União ou o direito nacional o previr.[4][5]
O AMLR exige prova de vida além da carteira europeia de identidade digital (EUDI Wallet)?
Nenhum texto que lemos exige isso. O artigo 22(6)(b) lista, como uma das opções, os meios de identificação eletrônica que cumprem os requisitos do Regulamento 910/2014 no nível substancial ou elevado, e a extensão das medidas segue a sua análise de risco individual.[13] Os projetos finais de normas da AMLA dizem que isso inclui as carteiras, e eles ainda não são lei.[14]
Uma apresentação feita pela carteira pode aprovar um pagamento?
Não com o PID. O PID Rulebook proíbe usar a chave privada do PID para assinar dados de transação.[9] O ARF prevê que a aprovação específica de uma transação se baseie em atestados de autenticação forte do usuário, que carregam os dados da transação.[3]
O nível elevado impede o sequestro de conta?
Ele protege a carteira, não a sua conta. Depois do onboarding, suas senhas, sessões e fluxos de recuperação ficam fora da carteira, a menos que você peça uma nova apresentação ou outra verificação nos momentos sensíveis.
Um laranja consegue passar nas verificações da EUDI Wallet?
Sim. Um titular real usando uma carteira real passa em todas as verificações, porque as verificações são verdadeiras. O controle é o acompanhamento contínuo previsto no artigo 26 do AMLR, além das ligações entre contas.[13]
A Didit aceita a EUDI Wallet?
A documentação da Didit lista a aceitação da EUDI Wallet com o status Em breve, e a página de soluções diz que ainda não existe uma API da Didit específica para a EUDI.[28] eIDs nacionais, verificação de documentos, prova de vida e comparação facial já funcionam hoje, e a página de soluções descreve o plano.
Fontes
- Regulamento (UE) n.º 910/2014, alterado pelo Regulamento (UE) 2024/1183, texto consolidado de 18 de outubro de 2024, EUR-Lex.
- Architecture and Reference Framework v3.0.0, capítulo 6, Trust model, Comissão Europeia, 23 de julho de 2026.
- Architecture and Reference Framework v3.0.0, Anexo 2, High-Level Requirements, Comissão Europeia.
- Regulamento de Execução (UE) 2024/2977, texto consolidado de 11 de agosto de 2026, EUR-Lex.
- Regulamento de Execução (UE) 2026/1731, EUR-Lex, Jornal Oficial de 22 de julho de 2026.
- Regulamento de Execução (UE) 2024/2979, texto consolidado de 11 de agosto de 2026, EUR-Lex.
- Regulamento de Execução (UE) 2015/1502 relativo aos níveis de garantia, EUR-Lex.
- Regulamento de Execução (UE) 2024/2981 sobre a certificação das carteiras, registro de riscos do Anexo I, EUR-Lex.
- PID Rulebook v1.7, Comissão Europeia, 17 de julho de 2026.
- Topic R, Authentication of the User to the device, v1.0, documento de discussão do ARF, 14 de outubro de 2025.
- Topic Z, Device-bound Attestations, v1.0, documento de discussão do ARF, 29 de setembro de 2025.
- OpenID for Verifiable Presentations 1.0, OpenID Foundation.
- Regulamento (UE) 2024/1624 (AMLR), EUR-Lex, Jornal Oficial de 19 de junho de 2024.
- Relatório final, projeto de RTS nos termos do artigo 28(1) do AMLR, AMLA, 30 de setembro de 2026 (projeto final, não é lei).
- Regulamento (UE) 2016/679 (GDPR), EUR-Lex.
- Regulamento (UE) 2024/1689 (AI Act), EUR-Lex.
- Diretiva (UE) 2015/2366 (PSD2), EUR-Lex.
- Regulamento Delegado (UE) 2018/389, EUR-Lex.
- Relatório de 2025 sobre fraude em pagamentos, EBA e BCE, dezembro de 2025.
- Relatório conjunto EBA-BCE sobre fraude em pagamentos, comunicado à imprensa, BCE, 15 de dezembro de 2025.
- Remote Identity Proofing: Attacks and Countermeasures, ENISA.
- TechDispatch on Digital Identity Wallets, Autoridade Europeia para a Proteção de Dados, dezembro de 2025.
- ETSI TS 119 461 v2.1.1, identity proofing of trust service subjects, ETSI.
- Architecture and Reference Framework v3.0.0, capítulo 4, High-level architecture, Comissão Europeia.
- Autenticação biométrica, documentação da Didit.
- Detecção de vivacidade, documentação da Didit.
- Face Match 1:1, documentação da Didit.
- Carteiras de identidade digital, documentação da Didit.
- Face Search, documentação da Didit.
- Networks, documentação da Didit.
- Criar um step-up, documentação da Didit.
- Monitoramento de transações, documentação da Didit.
- Retenção de dados, documentação da Didit.
Uma carteira responde a quem pertence uma credencial, e o seu trabalho de risco começa a partir dessa resposta. Para os momentos que exigem uma pessoa, veja Autenticação biométrica. Para a prontidão para a carteira, veja nossa página sobre a EUDI Wallet e verificação de eID.
Verifique a pessoa, não apenas a chave
Adicione detecção de vivacidade e face match onde a sua avaliação de risco indicar que elas cabem.
Artigos relacionados
- Aceitação transfronteiriça da EUDI Wallet: uma integração para toda a UE
- Preparação para a EUDI Wallet: políticas e controles para instituições reguladas
- Vinculação ao titular na EUDI Wallet: o que uma apresentação realmente prova
- Integração com a EUDI Wallet: como escolher sua rota (guia 2026)
- Verificação de identidade FINTRAC em 2026: métodos, normas e C-12
- Lei 25 do Quebec e biometria: guia de verificação de identidade (2026)