Verificador OpenID4VP: aceitar a carteira europeia de identidade digital (EUDI Wallet)
Como funciona o verificador OpenID4VP para a EUDI Wallet: objetos de solicitação, consultas DCQL, modos de resposta, verificações SD-JWT VC e mdoc, regras HAIP no direito da UE, erros comuns e onde testar.
Em resumo
O OpenID4VP (OpenID for Verifiable Presentations) é o protocolo que um verificador usa para solicitar credenciais a uma carteira digital e receber de volta uma apresentação assinada. A versão 1.0 tornou-se uma OpenID Final Specification em 10 de julho de 2025, e a carteira europeia de identidade digital (EUDI Wallet) o utiliza para apresentação remota.[2][3]
- Você envia uma solicitação assinada com uma consulta DCQL. A carteira retorna um VP Token.
- Você mesmo verifica a assinatura do emissor, as divulgações, a vinculação de chave e a revogação.
- Para a EUDI Wallet, o direito da UE acrescenta regras de certificados e de registro.
O OpenID4VP é a forma como um site ou aplicativo pede a uma carteira que comprove algo sobre uma pessoa, como o nome ou a data de nascimento. O verificador informa quais credenciais e atributos deseja, o usuário aprova na carteira e a carteira retorna uma apresentação que o verificador confere criptograficamente. Nas palavras da própria especificação, ela "define um protocolo para solicitar e apresentar Credenciais".[1]
Este guia é para desenvolvedores que estão construindo um verificador OpenID4VP para a EUDI Wallet: o objeto de solicitação, DCQL, modos de resposta, fluxos entre dispositivos, verificações de SD-JWT VC e mdoc, as regras HAIP no direito da UE, erros comuns e onde testar.
OpenID4VP em palavras simples
O OpenID4VP reaproveita o formato de uma solicitação de autorização OAuth 2.0. O verificador solicita o tipo de resposta vp_token, e uma resposta bem-sucedida deve incluir um parâmetro vp_token com as apresentações.[1] Não há código nem token de acesso a trocar: os dados chegam na própria resposta.
A carteira autentica a parte utilizadora, verifica se ela não pede mais do que registrou, coleta a aprovação do usuário e assina a apresentação. Em seguida, a parte utilizadora verifica a assinatura do emissor, o status de revogação e a vinculação ao dispositivo.[3] Os dados de identificação pessoal (PID) são emitidos em dois formatos, SD-JWT VC e ISO/IEC mdoc, e ambos usam hashes com salt para que o usuário possa compartilhar alguns atributos e ocultar os demais.[5][3]
- 10 de julho de 2025Especificação finalOpenID4VP 1.0 aprovado.
- 22 de julho de 2026PublicaçãoCIR 2026/1731 (adotado em 15 de julho de 2026) no Jornal Oficial.
- 23 de julho de 2026ARF v3.0.0Versão atual da arquitetura.
- 24 de dezembro de 2026CarteirasPelo menos uma por Estado-Membro.
- 24 de dezembro de 2027AceitaçãoPartes utilizadoras privadas regulamentadas.
Da especificação final até a data de aceitação pelo setor privado.[2][3][4][5]
Como funciona a troca com um verificador OpenID4VP
O OpenID4VP publica um desenho de referência para o modo de resposta direct_post, em que a carteira envia a resposta por POST a um endpoint do servidor em vez de enviá-la pelo navegador.[1]
A carteira verifica o verificador, o usuário consente
O design de referência direct_post no OpenID4VP 1.0, seção 13.3, simplificado.[1]
- Gere um nonce de "pelo menos 16 bytes novos e criptograficamente aleatórios" por requisição.
- Envie o request-id do endpoint de resposta para a carteira como
state. - Retorne uma URI de redirecionamento com um
response_codenovo assim que a carteira fizer o POST. - Busque o VP Token com o transaction-id e esse código e depois verifique o nonce.
O response_code impede a fixação de sessão, em que um invasor repassa a sua requisição para a carteira de uma vítima. A especificação observa que ele não ajuda em fluxos entre dispositivos e recomenda mecanismos adicionais nesses casos.[1]
Vídeo pendente: flow-eudi-openid4vp
Uma apresentação OpenID4VP a partir de uma EUDI Wallet, do início ao fim.
O objeto de requisição do OpenID4VP e os identificadores de cliente
O client_id começa com um Client Identifier Prefix que indica à carteira como autenticar o verificador.[1] Requisições grandes trafegam por referência: a carteira busca o objeto de requisição assinado em um request_uri. Para QR codes, a especificação recomenda direct_post com request_uri, já que a requisição "pode não caber em um QR code".[1]
| Prefixo | Como a carteira autentica o verificador | Requisição assinada |
|---|---|---|
redirect_uri | O identificador é a URI de redirecionamento ou de resposta | Não pode ser assinada |
x509_san_dns | Nome DNS no SAN do certificado folha | Obrigatória |
x509_hash | Hash SHA-256 do certificado folha | Obrigatória |
decentralized_identifier | Chave do DID Document | Obrigatória |
verifier_attestation | JWT de atestação de um emissor em que a carteira confia | Obrigatória |
openid_federation | Cadeia de confiança da federação | Via OpenID Federation |
Prefixos de Client Identifier, OpenID4VP 1.0, seção 5.9.[1]
Para verificadores EUDI, o direito da UE define o prefixo: o certificado final "para uso com o Client Identifier Prefix x509_hash deve ser um certificado de acesso de RP conforme especificado na ETSI TS 119 475", e um elemento de verifier_info "deve incluir o certificado de registro".[5]
Consultas DCQL: peça o que você registrou
A Digital Credentials Query Language (DCQL) é a consulta em JSON que indica as credenciais e os atributos que você quer. Ela contém um array credentials obrigatório e um array credential_sets opcional. Cada consulta de credencial precisa de um id, um format e um objeto meta.[1] O exemplo de SD-JWT VC da especificação:[1]
{ "credentials": [ { "id": "my_credential", "format": "dc+sd-jwt", "meta": { "vct_values": [ "https://credentials.example.com/identity_credential" ] }, "claims": [ {"path": ["last_name"]}, {"path": ["first_name"]}, {"path": ["address", "street_address"]} ] } ] }
Para um mdoc, o formato é mso_mdoc e meta traz um doctype_value.[1] Para o PID, substitua pelo tipo e pelos nomes de atributos dele. Os atributos obrigatórios do PID são sobrenome, nome, data de nascimento, local de nascimento e nacionalidade.[7]
require_cryptographic_holder_bindingtem como padrão true. Mantenha assim: isso faz a carteira devolver uma prova de vinculação de chave.[1]trusted_authoritiesapenas filtra o que a carteira oferece. Os verificadores "devem verificar por conta própria se o emissor de uma apresentação recebida é confiável".[1]- As partes utilizadoras "não podem solicitar aos usuários quaisquer dados além" do que registraram, e a carteira verifica isso.[4][3]
Modos de resposta do OpenID4VP
O modo de resposta define como o VP Token volta. O padrão para vp_token é fragment, no fragmento da URI de redirecionamento.[1]
| Modo de resposta | Para onde vai o VP Token | Criptografado |
|---|---|---|
fragment | Fragmento da URI de redirecionamento, pelo navegador | Não |
direct_post | HTTP POST para a response_uri | Não |
direct_post.jwt | HTTP POST de um JWT criptografado | Sim |
dc_api | De volta pela Digital Credentials API | Não |
dc_api.jwt | Igual, criptografado | Sim |
Modos de resposta no OpenID4VP 1.0.[1]
Com direct_post, response_uri é obrigatório e redirect_uri deve estar ausente. Caso contrário, a carteira retorna invalid_request.[1] O EVO Wallet da Moldávia, por exemplo, documenta o OpenID4VP 1.0 com direct_post.jwt em um fluxo no mesmo dispositivo, mdoc ISO/IEC 18013-5 perfilado conforme o OpenID4VC HAIP 1.0 e uma IETF Token Status List para revogação.[11]
Mesmo dispositivo, entre dispositivos e a Digital Credentials API
O ARF lista as combinações remotas suportadas: OpenID4VP combinado com um mecanismo de transmissão baseado em redirecionamentos e esquemas de URI personalizados; OpenID4VP ou ISO/IEC 18013-7 combinado com a W3C Digital Credentials API; e, opcionalmente, ISO/IEC 18013-7 com redirecionamentos e esquemas de URI personalizados.[3]
Mesmo dispositivo
Esquema de URI personalizado
- O navegador entrega openid4vp:// ao sistema operacional
- A carteira abre no mesmo celular
ARF 4.4.3.1
Entre dispositivos
QR code
- O desktop exibe um QR code para escanear
- Exposto a phishing e retransmissão
ARF 4.4.3.1
API do navegador
Digital Credentials API
- O navegador repassa a origem verificada
- Ativada por padrão no Chrome 141
Apêndice A do OpenID4VP
Três formas pelas quais uma carteira recebe uma solicitação OpenID4VP.[3][1][10]
O ARF afirma que esquemas de URI personalizados "não são recomendados para fluxos entre dispositivos" e indica a Digital Credentials API como alternativa.[3] Pela API, a carteira conhece a origem do verificador conforme autenticada pelo navegador, "o que é importante para a resistência a phishing".[1] A especificação do W3C ainda é um rascunho.[9] O que o usuário vê no celular:
Verifique sua identidade
Este site solicita seus dados à sua carteira.
1O navegador envia uma URI openid4vp:// ao sistema operacional.[3]
Verificando a solicitação
A carteira abre e se conecta à parte utilizadora.
2A carteira autentica a parte utilizadora e verifica o que ela registrou.[3]
Escolha o que compartilhar
- SobrenomeCompartilhado
- Data de nascimentoCompartilhado
- EndereçoNão compartilhado
Compartilhar
3O usuário aprova os atributos.[3]
Dados recebidos
4A carteira envia os dados e devolve o usuário.[1]
Como verificar uma apresentação SD-JWT VC passo a passo
Uma apresentação SD-JWT VC contém o JWT assinado pelo emissor, as divulgações que o usuário revelou e um Key Binding JWT. O verificador "DEVE validar cada Verifiable Presentation individual" e rejeitar qualquer uma com o nonce errado.[1]
1Verifique a assinatura do emissor
A chave remete, por cadeia, a um provedor de PID ou de atestados confiável.
2Confira cada divulgação
O hash de cada uma corresponde a um digest no payload assinado.
3Verifique o Key Binding JWT
Assinatura com a chave do titular; nonce e audience conferem.
4Verifique a revogação
Consulte a lista de status do emissor.
Todas as verificações são aprovadas
Use os atributos divulgados
Rejeite e ofereça outro caminho
As verificações do verificador em uma apresentação SD-JWT VC.[1][3]
Assinatura do emissor. O ARF a coloca em primeiro lugar entre as verificações da parte utilizadora. As âncoras de confiança vêm das listas de confiança (ETSI TS 119 612) e das listas de entidades confiáveis (ETSI TS 119 602).[3]
Divulgações. O payload assinado contém um array _sd de digests. Cada divulgação é um salt, um nome de claim e um valor, como ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"].[1] Calcule o hash de cada uma e encontre o digest correspondente. Se não houver correspondência, o emissor não a assinou.
Key Binding JWT. Quando o vínculo com o titular é exigido, a carteira "DEVE retornar um SD-JWT com um Key Binding JWT". O nonce dele deve ser igual ao nonce da sua solicitação, e o aud deve ser igual ao seu Client Identifier ou, na Digital Credentials API, à sua origem com o prefixo origin:.[1] O exemplo da especificação:
{ "nonce": "n-0S6_WzA2Mj", "aud": "x509_san_dns:client.example.org", "iat": 1709838604, "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4" }
Revogação. A parte utilizadora verifica se o provedor "não revogou o PID ou o atestado".[3] A EVO Wallet da Moldávia, por exemplo, documenta uma IETF Token Status List para isso.[11]
Observação
O retrato do PID passa a ser obrigatório somente a partir de 11 de agosto de 2028. Portanto, não planeje uma comparação facial com o retrato da carteira antes dessa data.[5]
Apresentações mdoc via ISO/IEC 18013-7, em resumo
Para um mdoc, o VP Token contém um DeviceResponse da ISO/IEC 18013-5 codificado em base64url, que "contém uma assinatura ou MAC sobre o SessionTranscript", incluindo uma estrutura de handover do OpenID4VP.[1] Esse handover vincula o mdoc à sua solicitação, da mesma forma que o nonce e o audience vinculam um SD-JWT VC.
Atenção
O direito da UE aplica o "Anexo C da ISO/IEC 18013-7:2025" para mdoc via Digital Credentials API.[5] A ISO lista a edição de 2024 da 18013-7 como retirada e substituída. Verifique qual edição a sua biblioteca implementa.[8]
Nossa comparação entre SD-JWT VC e mdoc explica quando cada formato é adequado.
O que o perfil HAIP acrescenta para verificadores EUDI
O High Assurance Interoperability Profile (HAIP) restringe as opções do OpenID4VP. O ARF já o exige para a emissão e afirma que o seu uso "é necessário para garantir a interoperabilidade".[3] Para a apresentação, o CIR 2026/1731 define um "perfil OpenID4VC-HAIP" e um "perfil ISO/IEC-mdoc".[5]
| Requisito | Para o seu verificador | Fonte |
|---|---|---|
| Certificado de acesso | Assine com um certificado de acesso de RP x509_hash, ETSI TS 119 475 | CIR 2026/1731[5] |
| Certificado de registro | Inclua-o em verifier_info | CIR 2026/1731[5] |
| Registro | Registre-se onde você está estabelecido | eIDAS, Art. 5b(1)[4] |
| Verificações da carteira | As unidades de carteira validam certificados de registro somente a partir de 11 de agosto de 2028. Não é um prazo de registro | CIR 2026/1731[5] |
O certificado de registro "descreve o uso pretendido da parte utilizadora e indica os atributos" que ela registrou, e o regulamento de registro se aplica a partir de 24 de dezembro de 2026.[6] A data de 11 de agosto de 2028 abrange apenas a verificação desse certificado pela carteira, e não o registro.[5] A Alemanha resume assim: uma organização "recebe um certificado de acesso e de registro para a organização e o caso de uso".[12] Nosso guia sobre partes utilizadoras da EUDI Wallet trata do registro em detalhes.
Erros comuns ao criar um verificador OpenID4VP
| Erro | Correção |
|---|---|
| Nonces reutilizados ou curtos | Pelo menos 16 bytes aleatórios novos por solicitação[1] |
| Sem verificação de audiência | Compare aud com seu Client Identifier ou com a origem[1] |
| Solicitar dados não registrados | Monte a consulta DCQL a partir do seu registro[4] |
| QR codes com URI personalizado entre dispositivos | Prefira a Digital Credentials API[3] |
Confiar em trusted_authorities | Valide você mesmo o emissor com base nas listas de confiança[1] |
| Ignorar a revogação | Verifique o status todas as vezes[3] |
Assinar com o prefixo redirect_uri | Não é possível assinar com ele; use x509_hash[1][5] |
A carteira também é voluntária: o acesso "não pode, de forma alguma, ser restringido ou tornado desvantajoso" para pessoas que não a utilizam. Por isso, seu verificador coexiste com outra via.[4]
Recursos de teste
Comece pelo software de referência e pelos testes de conformidade antes de testar com as carteiras nacionais.
- Execute os testes de conformidade em conformance.eudi.dev.[3]
- Leia a documentação da implementação de referência em docs.eudi.dev. Ela é documentação, não são testes.[3]
- Estude o verificador de demonstração do Banco Nacional da Moldávia e o seu código-fonte.[13]
- Consulte a minuta da Digital Credentials API antes de depender da via do navegador.[9]
Para as datas por trás do seu plano de testes, veja prazos da EUDI Wallet para 2026 e 2027.
Como a Didit ajuda na verificação com a EUDI Wallet
A aceitação da EUDI Wallet chega em breve à Didit: ela está no nosso roadmap, alinhada ao cronograma da EUDI Wallet, no mesmo fluxo de trabalho que você usa hoje. Enquanto isso, você já pode verificar pessoas remotamente.
- Cinco eIDs nacionais funcionam hoje na Didit por meio de carteiras de identidade digital: MitID, BankID Sweden, Finnish Trust Network, Smart-ID e Mobile-ID. Veja verificação de eID.
- Se a pessoa não tiver eID, o fluxo recorre à verificação de documentos com leitura do chip NFC, prova de vida e comparação facial, configurados por país. Uma verificação KYC completa custa $0.33.
- A triagem AML roda no mesmo fluxo por $0.20.
Você mantém suas obrigações como parte utilizadora. A documentação das carteiras mostra como os eIDs são ativados por país.
A Didit fornece
- Logins com eID nacional e a via documental em um único fluxo de trabalho
- As evidências de cada verificação
Fica com você
- Seu registro como parte utilizadora da carteira
- A decisão de onboarding e suas políticas
Planeje conosco seu caminho para a carteira europeia de identidade digital (EUDI Wallet)
Informe seus países e seu caso de uso e comece hoje com eIDs nacionais e documentos.
Pontos principais
- O OpenID4VP 1.0 é uma especificação final da OpenID desde 10 de julho de 2025.
- Envie uma consulta DCQL limitada pelo seu registro e um nonce novo.
- Verifique a assinatura do emissor, cada divulgação, o Key Binding JWT e a revogação.
- Os verificadores EUDI assinam com um certificado de acesso RP
x509_hash. - As partes utilizadoras privadas abrangidas aceitam a carteira até 24 de dezembro de 2027.
Perguntas frequentes
O que é o OpenID4VP?
O OpenID for Verifiable Presentations é um protocolo para solicitar e apresentar credenciais. A carteira devolve apresentações assinadas em um VP Token, sem código de autorização nem token de acesso para trocar. A versão 1.0 se tornou uma Especificação Final da OpenID em 10 de julho de 2025.[1][2]
A EUDI Wallet usa o OpenID4VP?
Sim, para apresentação remota, ao lado da ISO/IEC 18013-7. O direito da UE define um perfil OpenID4VC-HAIP e um perfil ISO/IEC-mdoc.[3][5]
O que é a DCQL?
A Digital Credentials Query Language é a consulta JSON que especifica as credenciais e os atributos que um verificador deseja. A carteira devolve as apresentações correspondentes. Para a EUDI Wallet, solicite apenas os atributos que você registrou.[1][4]
Qual modo de resposta um verificador EUDI deve usar?
Um verificador do lado do servidor usa direct_post ou o direct_post.jwt criptografado. Pela Digital Credentials API, os modos são dc_api e dc_api.jwt.[1]
Como verifico o Key Binding JWT?
Confira a assinatura dele com a chave vinculada na credencial e, em seguida, confira o nonce e o público-alvo em relação à sua solicitação. Pela Digital Credentials API, o público-alvo é a sua origem.[1]
Qual prefixo de identificador de cliente os verificadores EUDI usam?
x509_hash, com um certificado de acesso RP conforme a ETSI TS 119 475. O certificado de registro vai em verifier_info.[5]
Posso usar um QR code entre dispositivos?
Pode, mas o ARF não recomenda esquemas de URI personalizados entre dispositivos por causa de ataques de phishing e de retransmissão. Ele indica a Digital Credentials API como alternativa.[3]
Posso fazer a comparação facial com o retrato da carteira?
Ainda não de forma confiável. O retrato passa a ser dado obrigatório do PID somente a partir de 11 de agosto de 2028.[5]
Onde posso testar um verificador OpenID4VP?
Execute os testes de conformidade em conformance.eudi.dev e leia a documentação da implementação de referência em docs.eudi.dev. O banco central da Moldávia também publicou um verificador de demonstração com código-fonte.[3][13]
Fontes
- OpenID for Verifiable Presentations 1.0, OpenID Foundation, especificação final.
- Especificação final do OpenID for Verifiable Presentations 1.0 aprovada, OpenID Foundation, 10 de julho de 2025.
- Architecture and Reference Framework v3.0.0, eu-digital-identity-wallet no GitHub, versão de 23 de julho de 2026.
- Regulamento (UE) 2024/1183 (eIDAS 2), EUR-Lex, Jornal Oficial de 30 de abril de 2024.
- Regulamento de Execução (UE) 2026/1731 da Comissão, EUR-Lex, Jornal Oficial de 22 de julho de 2026.
- Regulamento de Execução (UE) 2025/848 da Comissão sobre o registro das partes utilizadoras de carteiras, EUR-Lex, Jornal Oficial de 7 de maio de 2025.
- Regulamento de Execução (UE) 2024/2977 da Comissão sobre os dados de identificação pessoal, EUR-Lex, Jornal Oficial de 4 de dezembro de 2024.
- ISO/IEC 18013-7, página da norma na ISO.
- Digital Credentials, rascunho do W3C.
- Digital Credentials API lançada, Chrome for Developers.
- Guia para desenvolvedores da EVO Wallet, Governo da Moldávia, egov4dev.
- Perguntas frequentes sobre a EUDI Wallet, eudi-wallet.gov.de.
- Verificador de demonstração do BNM, Governo da Moldávia, egov4dev.
O OpenID4VP é a parte da EUDI Wallet com que os desenvolvedores mais lidam, e já é estável o bastante para servir de base para o desenvolvimento. Veja como a Didit aborda a aceitação de carteiras na página da solução EUDI Wallet e o panorama mais amplo na nossa visão geral do eIDAS 2.
Verifique pessoas remotamente enquanto as carteiras são implantadas
Use agora as eIDs nacionais e a rota por documento, e fale conosco sobre a EUDI Wallet.
Artigos relacionados
- Integração com Cl@ve na Espanha: quem pode se conectar e o que usar no lugar
- Verificação PhilSys: como as empresas checam a National ID
- Verificador OpenID4VP: aceitar a carteira europeia de identidade digital (EUDI Wallet)
- Entenda o regulamento eIDAS e as mudanças trazidas pelo eIDAS 2 (2024/1183)
- API do Smart-ID: guia para desenvolvedores da RP API v3
- Identidade digital nacional no mundo: modelos, líderes, padrões