Se o seu app pede hoje aos usuários uma foto do passaporte ou do documento de identidade, você provavelmente já ouviu que as carteiras europeias de identidade digital (EUDI Wallet) chegam "no fim de 2026". A data é real, e é exata: 24 de dezembro de 2026. Mas é um prazo para os Estados-Membros, não para você, e ele não desliga a leitura de documentos.
Este post faz três coisas. Mostra de onde vem a data, com as contas. Lista o que uma carteira de fato entrega, a partir das tabelas de atributos das normas. E esboça um desenho que aceita uma carteira quando o usuário tem uma e recorre à leitura do documento quando não tem. Ele é escrito pelo doc.cheap, uma API de OCR para passaportes e documentos de identidade, então leia as partes de produto com isso em mente. O doc.cheap lê imagens de documentos; ele não lê carteiras.
De onde vem 24 de dezembro de 2026
A obrigação é o art. 5a(1) do Reg. (UE) n.º 910/2014, inserido pelo Reg. (UE) 2024/1183, a alteração do eIDAS. Ele diz que cada Estado-Membro "disponibiliza pelo menos uma carteira europeia de identidade digital no prazo de 24 meses a contar da data de entrada em vigor dos atos de execução referidos no n.º 23 do presente artigo e no artigo 5c(6)".
Ou seja, o relógio não começa com a própria alteração do eIDAS. Ele começa com os atos de execução da Comissão. Os atos do art. 5a(23) são quatro atos de execução da Comissão datados de 28 de novembro de 2024, entre eles o Reg. de Execução (UE) 2024/2979, sobre a integridade e as funcionalidades principais das carteiras. Ele foi publicado no Jornal Oficial (JO L, 2024/2979) em 4 de dezembro de 2024. O seu art. 15 diz que ele "entra em vigor no vigésimo dia seguinte ao da sua publicação no Jornal Oficial da União Europeia".
As contas:
| Etapa | Data |
|---|---|
| Publicado no Jornal Oficial | 4 de dezembro de 2024 |
| Dia 1 após a publicação | 5 de dezembro de 2024 |
| Dia 20 após a publicação: entrada em vigor | 24 de dezembro de 2024 |
| Mais 24 meses (art. 5a(1)): prazo das carteiras | 24 de dezembro de 2026 |
| Mais 36 meses (art. 5f(2)): certas partes utilizadoras privadas devem aceitar carteiras | 24 de dezembro de 2027 |
O "vigésimo dia seguinte" é contado a partir do dia depois da publicação, então 4 de dezembro mais 20 dias cai no dia 24, não no 23. A mesma data de entrada em vigor define a segunda data da tabela, que é a que mais importa para a maioria dos times de produto (mais sobre ela abaixo).
O que uma carteira entrega
Uma carteira não envia a foto de um passaporte. Ela apresenta dados assinados. O conjunto de dados de uma pessoa física está fixado no anexo do Reg. de Execução (UE) 2024/2977: os "dados de identificação pessoal" (PID, person identification data). O anexo diz que os PID são emitidos em dois formatos: ISO/IEC 18013-5:2021 e o "Verifiable Credentials Data Model 1.1" do W3C.
Estes são os atributos, com o caráter que o texto dá a cada um (tabelas 1, 2 e 5 do anexo, conforme publicadas em 4 de dezembro de 2024). A última coluna é o campo mais próximo em uma resposta de leitura do doc.cheap, para você ver onde os dois mundos se encaixam e onde não.
| Atributo PID | Caráter | Campo mais próximo em uma leitura de documento |
|---|---|---|
family_name |
obrigatório | holder.surname |
given_name |
obrigatório | holder.given_names |
birth_date |
obrigatório | holder.birth_date (ISO 8601) |
birth_place |
obrigatório | uma entrada birth_place em fields[], quando o documento a imprime |
nationality |
obrigatório (alfa-2, um ou mais) | holder.nationality (alfa-3, um) |
resident_address, resident_country, resident_state, resident_city, resident_postal_code, resident_street, resident_house_number |
opcional | nenhum na página de dados de um passaporte |
personal_administrative_number |
opcional | não é a mesma coisa; fields[] pode trazer um personal_number impresso no documento |
portrait |
opcional | images.main_photo |
family_name_birth, given_name_birth |
opcional | sem campo curado |
sex |
opcional (códigos 0, 1, 2, 3, 4, 5, 6, 9) | holder.sex (M, F, X) |
email_address, mobile_phone_number |
opcional | não constam em um documento |
expiry_date (metadados) |
obrigatório | document.expiry_date, mas do documento, não dos PID |
issuing_authority (metadados) |
obrigatório | uma entrada authority em fields[], quando impressa |
issuing_country (metadados) |
obrigatório (alfa-2) | document.issuing_state (alfa-3) |
document_number (metadados) |
opcional | não é a mesma coisa: o número dos PID é atribuído pelo fornecedor de PID, document.number é o do passaporte |
issuing_jurisdiction, location_status (metadados) |
opcional | nenhum |
Três pontos dessa tabela importam na hora de escrever o código de mapeamento.
- Os códigos de país são diferentes. Os PID usam ISO 3166-1 alfa-2 (
DE). Passaportes e a zona de leitura mecânica usam alfa-3 (DEU). Mantenha uma única forma interna e converta na borda. - "Obrigatório" não quer dizer "sempre conhecido". Abaixo da tabela 1 o texto acrescenta: "Caso o valor de um atributo não seja conhecido para a pessoa ou não possa de outra forma ser emitido como parte do conjunto de dados de identificação pessoal, os Estados-Membros devem utilizar, em seu lugar, um valor de atributo adequado à situação." Espere valores de preenchimento, não chaves ausentes.
- Só cinco atributos sobre a pessoa são obrigatórios. Endereço, retrato, sexo e nomes de nascimento são todos opcionais. Se o seu fluxo precisa de um deles, a carteira pode simplesmente não trazê-lo para um determinado usuário.
Quem continua chegando com um documento
O prazo obriga cada Estado-Membro a disponibilizar uma carteira. Ele não obriga ninguém a usá-la. O art. 5a(15) é direto: "A utilização das carteiras europeias de identidade digital é voluntária." E continua: "Deve continuar a ser possível aceder a serviços públicos e privados por outros meios de identificação e autenticação existentes."
Então, depois de 24 de dezembro de 2026, você ainda vai ver:
- Viajantes e clientes de fora da UE. Os considerandos ligam a carteira à "identidade jurídica dos cidadãos da União, dos residentes na União ou das pessoas coletivas". Um visitante com passaporte de outro lugar não tem uma carteira da UE para apresentar.
- Pessoas que não instalaram uma, ou não podem, ou preferem não fazê-lo. O texto protege essa escolha.
- Fluxos que precisam do próprio documento. Alguns processos querem a imagem do documento, o número do documento ou a zona de leitura mecânica do documento físico, não um atestado sobre a pessoa. Os PID de uma carteira trazem o seu próprio
document_number, atribuído pelo fornecedor de PID, que não é o número do passaporte. - O período antes de a carteira de um país estar no ar. 24 de dezembro de 2026 é o prazo legal. Quando cada carteira nacional chega de fato aos usuários é outra questão, e a única resposta confiável para um país é o anúncio desse próprio país ou o da Comissão.
Um desenho que aceita os dois
O formato que sobrevive a tudo isso é simples: peça a apresentação de uma carteira quando o usuário tiver uma e recorra à leitura do documento quando não tiver. Os dois caminhos terminam no mesmo registro interno.
user starts verification
|
v
offers a wallet? --yes--> wallet presentation --> verify signature --> map PID
| |
no v
| internal identity
v record
document photo --> POST /v1/scans --> map scan fields ----------------^
Algumas diretrizes tornam os dois caminhos intercambiáveis:
- Mapeie os dois para um único registro com os seus próprios nomes de campo. Use a tabela acima como mapeamento.
- Guarde a origem. Registre se um registro veio de uma carteira ou de uma leitura. Eles trazem evidências diferentes, e quem for revisar vai querer saber qual.
- Trate os nulos como honestos. Em uma resposta do doc.cheap todas as chaves estão sempre presentes e um valor desconhecido é
null. Uma carteira pode enviar um valor de preenchimento no lugar. Normalize os dois para uma única convenção. - Guarde o mínimo que o fluxo precisa. Uma leitura pode ser feita de forma que nada fique gravado do lado da API (veja abaixo).
Esta é a chamada alternativa com fetch puro. A chave pública de sandbox sk_sandbox_public está impressa na documentação e não exige cadastro; ela tem limite de requisições por endereço de cliente.
import { readFileSync } from "node:fs";
import { randomUUID } from "node:crypto";
async function scanDocument(path, apiKey = "sk_sandbox_public") {
const response = await fetch("https://api.doc.cheap/v1/scans", {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
"Idempotency-Key": randomUUID(), // uma retentativa devolve o primeiro resultado
},
body: JSON.stringify({
image: readFileSync(path).toString("base64"),
options: { retain_hours: 0, return_portrait: false }, // nada é armazenado
}),
});
if (!response.ok) throw new Error(`scan failed: HTTP ${response.status}`);
return response.json();
}
// Mapeia uma leitura para o mesmo registro que a apresentação de uma carteira preencheria.
function fromScan(scan) {
if (scan.meta.status !== "recognized") return null;
const field = (name) => scan.fields.find((f) => f.id === `${name}@0`)?.value ?? null;
return {
source: "document_scan",
family_name: scan.holder?.surname ?? null,
given_name: scan.holder?.given_names ?? null,
birth_date: scan.holder?.birth_date ?? null,
birth_place: field("birth_place"),
nationality_alpha3: scan.holder?.nationality ?? null,
issuing_country_alpha3: scan.document?.issuing_state ?? null,
document_number: scan.document?.number ?? null,
mrz_status: scan.mrz.status, // "passed", "failed" ou "absent"
};
}
meta.status é uma de cinco strings: recognized, no_document_found, unreadable, unsupported_document ou rejected. Só a primeira deve preencher um registro; as outras devem mandar o usuário tirar a foto de novo. Em uma chave paga, o saldo só é cobrado quando a leitura é faturável.
Fizemos uma chamada desse tipo contra sk_sandbox_public em 24 de setembro de 2026 às 21:17 UTC, com o documento de teste do próprio produto, um passaporte. A resposta voltou com HTTP 200. Todos os valores do documento abaixo estão mascarados, e fields, images e mrz.lines estão encurtados:
{
"meta": {
"schema_version": "1.0",
"id": "<SCAN_ID>",
"status": "recognized",
"billed": true,
"confidence": "medium",
"timing": { "upload_ms": 255, "processing_ms": 409, "total_ms": 678 },
"created_at": "<RUN_TIMESTAMP>",
"reference": null
},
"document": {
"kind": "passport", "country": "<ISO3>", "country_name": "<COUNTRY>",
"issuing_state": "<ISO3>", "number": "<DOCUMENT_NUMBER>", "series": null,
"issue_date": "<DATE>", "expiry_date": "<DATE>", "is_expired": false, "days_remaining": "<N>"
},
"holder": {
"given_names": "<GIVEN_NAMES>", "surname": "<SURNAME>", "full_name": "<FULL_NAME>",
"birth_date": "<DATE>", "sex": "<SEX>", "nationality": "<ISO3>"
},
"mrz": { "status": "passed", "reason": null, "lines": ["<LINE_1>", "<LINE_2>"], "text": "<MRZ>" },
"quality": { "overall": "pass" },
"authenticity": { "overall": "not_checked", "checks": [] }
}
billed: true aqui significa que a leitura era faturável e foi descontada da cota grátis do sandbox; a chave de sandbox em si nunca é cobrada. O array fields dessa execução trazia entradas birth_place, authority e personal_number, que é para onde a tabela acima aponta para esses atributos PID. A página de dados de um passaporte traz a MRZ em duas linhas no layout TD3; a página de formatos TD1, TD2 e TD3 mostra os layouts lado a lado.
Repare em authenticity.overall: "not_checked". Uma leitura como essa é reconhecimento: ela lê o que está impresso e confere os dígitos verificadores da MRZ. Não é detecção de fraude, e não dá a mesma garantia que a apresentação assinada de uma carteira. Se o seu processo precisa de um nível de garantia mais alto no caminho da leitura, isso tem de vir de outra parte do seu fluxo. Se você está escolhendo um fornecedor para a alternativa, a nossa comparação de APIs de OCR de passaporte apresenta as opções, inclusive algumas que fazem mais do que reconhecimento.
O que acompanhar a seguir
- 24 de dezembro de 2026 – prazo das carteiras. Art. 5a(1) do Reg. (UE) 2024/1183, contado a partir da entrada em vigor dos atos de execução, como mostrado acima.
- 24 de dezembro de 2027 – partes utilizadoras privadas. O art. 5f(2) diz que as partes utilizadoras privadas obrigadas a usar autenticação forte do usuário para identificação online, por lei ou por contrato, "devem, o mais tardar 36 meses a contar da data de entrada em vigor dos atos de execução referidos no artigo 5a(23) e no artigo 5c(6), e apenas mediante pedido voluntário do usuário, aceitar também as carteiras europeias de identidade digital". O texto cita transporte, energia, bancos, serviços financeiros, segurança social, saúde, água potável, serviços postais, infraestrutura digital, educação e telecomunicações, e exclui as microempresas e as pequenas empresas.
- Plataformas online de muito grande dimensão. O art. 5f(3) as obriga a aceitar carteiras para a autenticação de usuários, de novo apenas mediante pedido voluntário do usuário e para os dados mínimos necessários.
- Mudanças nos atos de execução. O considerando 4 do Reg. de Execução (UE) 2024/2979 diz que a Comissão "deverá revê-lo e atualizá-lo" quando necessário. Confira as tabelas de atributos do 2024/2977 antes de congelar um mapeamento.
A conclusão prática: construa o caminho da carteira quando os países dos seus usuários lançarem as suas carteiras, mantenha o caminho do documento e mapeie os dois para um único registro desde o primeiro dia. A documentação da API de OCR para passaportes e documentos de identidade cobre o lado da leitura por completo.
Este é um resumo técnico, não aconselhamento jurídico.