API de Credenciais Digitais (2026): Suporte Ativo no Chrome e Safari

Última atualização: 26 de Março de 2026

Uma visão rápida do suporte à API de Credenciais Digitais nos principais navegadores:

O mundo das credenciais digitais está se movendo rápido. Aqui está um resumo dos principais desenvolvimentos e projeções:

Want to experience digital credentials in action?

Try Digital Credentials

O que Mudou Desde Outubro de 2025?

• Mudança na governança de protocolos: O W3C FedID WG eliminou o registro aberto de protocolos na TPAC (Nov 2025) e agora define protocolos suportados diretamente na especificação (hardcoded): OpenID4VP, OpenID4VCI e ISO 18013-7 Anexo C. A API não é mais apenas um "canal neutro".
• Emissão chegando: O Chrome 143 lançou um Origin Trial para emissão de credenciais via navigator.credentials.create(), expandindo a API para além da apresentação.
• Firefox implementando: Apesar de manter sua posição negativa sobre o padrão, a Mozilla adicionou código base da API no Firefox 149, com trabalho de UX em andamento.
• Mandato condicional da UE: O Framework de Referência de Arquitetura da EUDI (Tópico F) agora exige condicionalmente o suporte à API para todas as wallets dos estados membros.
• Adoção no mundo real: O DMV da Califórnia adicionou suporte à API à sua plataforma OpenCred (Fev 2026).

Credenciais digitais são o assunto do momento no espaço de identidade. À medida que nossas vidas se tornam cada vez mais conectadas ao mundo digital, a necessidade de formas seguras, centradas no usuário e que preservem a privacidade para afirmar nossa identidade e qualificações online nunca foi tão crítica. Métodos tradicionais estão mostrando sinais de envelhecimento, e a demanda por soluções mais robustas é palpável.

Neste artigo, vamos discutir o estado atual da API de Credenciais Digitais, um desenvolvimento importante que promete remodelar como interagimos com informações de identidade na web. Exploraremos seus mecanismos subjacentes, os protocolos suportados, a adoção atual pelos navegadores e ofereceremos recomendações tanto para Relying Parties quanto para emissores de wallets navegarem neste cenário em rápida evolução.

Provar a identidade de forma confiável e segura tem sido um desafio persistente na arquitetura da web por muitos anos. Embora a internet tenha facilitado uma conectividade e troca de informações sem precedentes, ela também abriu novos caminhos para deturpação e fraude.

Em alguns países, surgiram soluções, impulsionadas principalmente por consórcios bancários iniciais que desenvolveram serviços para aproveitar relacionamentos de confiança existentes para identificação online. Governos também entraram em cena, aplicando ou fornecendo carteiras digitais e serviços nacionais de identidade digital. No entanto, essas soluções eram frequentemente isoladas, limitadas geograficamente e não universalmente interoperáveis.

O recurso padrão para verificação de identidade em muitas regiões envolvia tradicionalmente processos de alta fricção. A verificação física em uma agência dos correios, por exemplo, introduz atrasos e inconveniências significativas. Chamadas de vídeo combinadas com uploads de documentos tornaram-se uma alternativa mais digital, seguidas pela ascensão mais recente de verificação automatizada de documentos e testes de vivacidade (liveness checks). Apesar de seus avanços, esses métodos têm desvantagens significativas. Podem ser demorados, propensos a erro humano ou viés, e têm sido frequentemente expostos como vulneráveis a falsificações sofisticadas.

O desafio está aumentando dramaticamente com o advento de deepfakes, técnicas avançadas de representação por IA e ataques de phishing cada vez mais sofisticados. Essas tecnologias podem criar evidências de vídeo, áudio e documentos altamente realistas, mas inteiramente fabricadas, tornando incrivelmente difícil para sistemas tradicionais, e até mesmo ferramentas de verificação baseadas em IA, distinguir usuários genuínos de fraudulentos. O potencial para criar identidades sintéticas ou manipular dados biométricos para contornar verificações é uma ameaça severa, particularmente para instituições financeiras e qualquer serviço que exija processos robustos de Conheça Seu Cliente (KYC). Esse cenário de ameaças crescentes ressalta a necessidade urgente de mecanismos de identidade online e verificação mais seguros e verificáveis criptograficamente.

Want to experience digital credentials in action?

Try Digital Credentials

Entender como as credenciais digitais operam envolve olhar para os principais atores envolvidos e as diferentes camadas tecnológicas que permitem sua funcionalidade.

Em sua essência, o conceito de credenciais digitais, especialmente no contexto das novas APIs da web, gira em torno de um modelo de três partes:

1. Emissor (Issuer): Uma entidade (ex: governo, universidade, empregador) que tem autoridade sobre certas informações sobre um sujeito e pode emitir uma credencial digital atestando essa informação.
2. Titular (Holder): O sujeito da informação (ou seja, o usuário) que recebe a credencial do emissor e a armazena em uma carteira digital. O titular controla quando e quais informações da credencial são compartilhadas.
3. Verificador (ou Relying Party): Uma entidade (ex: um site, um serviço online) que precisa verificar certas informações sobre o titular para conceder acesso a um serviço ou recurso. O verificador solicita as informações necessárias ao titular.

Esse modelo de três partes é importante porque visa colocar o usuário (titular) no controle de seus próprios dados. Ao contrário dos sistemas de identidade tradicionais, onde os dados podem ser armazenados centralmente ou compartilhados entre partes sem a intermediação direta do usuário, este modelo enfatiza o consentimento do usuário e a divulgação seletiva. O titular decide quais pedaços de informação compartilhar de uma credencial para uma transação específica, em vez de revelar a credencial inteira.

Um aspecto fundamental desses sistemas é o envolvimento de pares de chaves criptográficas. O emissor assina digitalmente a credencial, garantindo sua autenticidade e integridade. O titular, por sua vez, usa sua chave privada, muitas vezes protegida dentro de sua carteira digital (que é protegida pelo hardware do dispositivo), para provar o controle sobre a credencial e autorizar sua apresentação a um verificador. Isso geralmente envolve o verificador apresentando um desafio (um dado aleatório) que a carteira do titular assina usando a chave privada associada à credencial. O verificador pode então usar a chave pública correspondente para confirmar a assinatura, autenticando assim a apresentação.

Esta explicação é neutra em relação ao protocolo, pois os princípios fundamentais de emissão, posse e verificação através de desafios criptográficos são comuns em diferentes tecnologias subjacentes.

Este artigo concentra-se na verificação de credenciais digitais e no princípio da divulgação seletiva, permitindo que os usuários provem atributos específicos (ex: "tenho mais de 18 anos", "possuo uma carteira de motorista válida") sem revelar todo o documento de origem. Embora os sistemas subjacentes para credenciais digitais possam suportar recursos como Assinaturas Eletrônicas Qualificadas (QES) e capacidades de assinatura remota (como visto em soluções abrangentes como a Carteira de Identidade Digital da UE para assinaturas juridicamente vinculativas), o foco aqui, particularmente para a API de Credenciais Digitais, é na afirmação de identidade e verificação de atributos para interações online, não primariamente nessas funcionalidades de assinatura mais amplas.

Para entender como as credenciais digitais funcionam, é útil visualizar um modelo em camadas. Cada camada aborda um aspecto diferente do ecossistema, desde o formato dos dados em si até como ele é apresentado a um usuário em um navegador da web. Este artigo foca principalmente na API de Credenciais Digitais, que opera na camada de apresentação.

Terminologia Principal:

• Credencial Digital: Qualquer credencial legível por máquina (PDF com código de barras, ISO mDL, W3C VC, SD-JWT, etc.). "Digital" não diz nada sobre verificabilidade criptográfica.
• Credencial Verificável (Verifiable Credential - VC): Um tipo de credencial digital, definido pelo Modelo de Dados W3C VC. Adiciona evidência de violação e prova criptográfica, e sempre vive em um mundo de três partes: emissor → titular → verificador.
• API de Credencial Verificável (VC API): Uma interface de serviço REST/HTTP para emitir, armazenar, apresentar e verificar VCs entre sistemas de back-end (emissores, carteiras, verificadores).
• API de Credenciais Digitais (DC API): Uma API de navegador/sistema operacional (JavaScript + encanamento nativo) que permite a um site solicitar à carteira no dispositivo do usuário que apresente qualquer credencial digital suportada (VC, ISO mDoc, SD-JWT…) de uma maneira que respeite a privacidade.

Pense nas VCs como um modelo de dados, na VC API como uma especificação de back-end e na DC API como a implementação de front-end que apresenta credenciais para a Web. Tudo acima da camada 1 (camada de modelo de dados) é agnóstico ao formato; tudo abaixo depende do formato da credencial.

Fluxo ponta a ponta (exemplo: verificação de idade online):

O diagrama a seguir ilustra como essas camadas trabalham juntas em um cenário do mundo real.

Observe como os dados são uma VC, o transporte na Web é a DC API, o protocolo de troca por baixo é o OpenID4VP, e a verificação do lado do servidor usa a VC API.

Por que a divisão existe:

• Modelo de dados interoperável (provas criptográficas, divulgação seletiva): Resolvido pelo Modelo de Dados VC (e outros formatos).
• Endpoints REST padrão para sistemas de back-end: Resolvido pela VC API.
• Handshake Carteira ↔ Site que preserva a privacidade: Resolvido pela DC API.
• Diferentes níveis de confiança / tipos de documentos (ID do governo vs. certificado de curso): Resolvido usando o formato certo (ISO mDoc para IDs de alta garantia; W3C VC para alegações gerais) sob a DC API.

Principais lições:

1. "Credencial Digital" é o termo guarda-chuva.
2. Credencial Verificável é um tipo de credencial digital com verificabilidade criptográfica embutida.
3. VC API é o encanamento servidor-a-servidor para operações de ciclo de vida em VCs.
4. API de Credenciais Digitais é a ponte navegador-a-carteira que finalmente permite que essas credenciais fluam suavemente para Web-apps, qualquer que seja o formato concreto em que estejam.
5. As três peças são complementares, não concorrentes — elas ficam em diferentes camadas da mesma pilha e juntas permitem identidade segura e centrada no usuário na Web aberta.

Tendo explorado os participantes e a arquitetura geral em camadas das credenciais digitais, este artigo agora se aprofundará na camada de apresentação, focando especificamente na API de Credenciais Digitais e seu estado atual.

Como o componente crucial na camada de apresentação, a API de Credenciais Digitais é um padrão web atualmente sendo desenvolvido para fornecer uma maneira segura e padronizada para sites solicitarem e receberem informações de identidade digital das carteiras digitais dos usuários. Este esforço está hospedado principalmente no Grupo de Trabalho de Identidade Federada do W3C (FedID WG), tendo migrado do Grupo Comunitário FedID em Abril de 2025. O rascunho oficial da especificação pode ser encontrado aqui: https://w3c-fedid.github.io/digital-credentials/.

Em Outubro de 2025, a API foi lançada em versões estáveis tanto no Chrome 141 (30 de Set, 2025) quanto no Safari 26 (15 de Set, 2025). A implementação do Chrome suporta tanto OpenID4VP quanto ISO 18013-7 Anexo C, enquanto o Safari suporta exclusivamente o protocolo org-iso-mdoc.

Importante (Atualização de Março de 2026): A relação da API com protocolos mudou fundamentalmente. Na TPAC em Novembro de 2025, o W3C FedID WG chegou a um consenso para eliminar o registro aberto de protocolos e, em vez disso, codificar uma lista finita de protocolos suportados diretamente na especificação: openid4vp-v1-unsigned, openid4vp-v1-signed, openid4vp-v1-multisigned, org-iso-mdoc (para apresentação) e openid4vci-v1 (para emissão). Espera-se que os agentes de usuário (browsers) rejeitem protocolos não listados. Isso torna o Grupo de Trabalho um guardião de facto para futuras adições de protocolos — uma troca deliberada para permitir uma revisão holística de segurança e privacidade de tudo o que flui pela API (veja o Rascunho de Trabalho atual).

A especificação agora também cobre a emissão de credenciais via navigator.credentials.create(). O Chrome 143 lançou um Origin Trial para isso, permitindo que sites acionem fluxos de provisionamento de carteira usando OpenID4VCI. No entanto, uma vulnerabilidade de vinculação de seleção de carteira — onde um aplicativo de carteira malicioso pode interceptar códigos de pré-autorização de emissão — permanece uma preocupação em aberto. Emissores governamentais indicaram que não adotarão a emissão mediada por navegador até que isso seja resolvido.

O Chrome suporta apresentação nativamente no Android através de seu sistema Gerenciador de Credenciais e também suporta a API de Credenciais Digitais Cross-Device no desktop via canal CTAP/BLE com QR code (handoff).

A API estende a Credential Management API existente, permitindo solicitações de credenciais digitais através de navigator.credentials.get(). De acordo com o Explainer de Credenciais Digitais do W3C FedID WG (https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md), a API reverteu para usar essa interface estabelecida em vez da navigator.identity proposta anteriormente. Um site solicita uma credencial digital chamando navigator.credentials.get() com parâmetros específicos para credenciais digitais.

Aqui está um exemplo ilustrativo de como um site pode chamar a API para solicitar uma credencial usando o OpenID4VP:

async function requestCredential() {
    // Verifica o suporte à API de Credenciais Digitais
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // Esses parâmetros são tipicamente obtidos do backend.
            // Definidos estaticamente aqui para fins de ilustração de extensibilidade de protocolo.
            const oid4vp = {
                protocol: "oid4vp", // Um exemplo de solicitação OpenID4VP para carteiras. // Baseado em https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        // Requisição Presentation Exchange, omitida por brevidade
                    },
                },
            };
 
            // cria um Abort Controller
            const controller = new AbortController();
 
            // Chama a API de Credenciais Digitais usando a solicitação de apresentação do backend
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Envia a resposta criptografada para o backend para descriptografia e verificação
            // Omitido por brevidade
        } catch (error) {
            console.error("Erro:", error);
        }
    } else {
        // cenário de fallback, apenas ilustrativo
        alert("A API de Credenciais Digitais não é suportada neste navegador.");
    }
}

Este exemplo foi retirado daqui.

A API de Credenciais Digitais atua essencialmente como um wrapper ou intermediário seguro. Ela permite que o navegador medie a solicitação de informações de identidade, aproveitando as capacidades do sistema operacional subjacente para descobrir carteiras disponíveis e credenciais que correspondam à solicitação. O navegador e o SO podem então apresentar uma interface de usuário consistente para selecionar a credencial e autorizar sua liberação, aumentando a segurança e a privacidade ao garantir o consentimento do usuário e impedir que sites acessem dados sensíveis silenciosamente. A intenção é que os dados reais da credencial na resposta sejam opacos (criptografados) para o próprio navegador, com a descriptografia e interpretação tratadas pela Relying Party e pela carteira/titular.

A API de Credenciais Digitais foi originalmente projetada para ser totalmente agnóstica em relação ao protocolo, atuando como um "canal neutro" com um registro aberto para qualquer protocolo se registrar. No entanto, a partir de Janeiro de 2026, a especificação agora nomeia explicitamente os protocolos que suporta — espera-se que os agentes de usuário rejeitem os não listados. As duas principais famílias de protocolos atualmente codificadas na especificação são: org.iso.mdoc (derivado da ISO 18013-5 e sua extensão ISO 18013-7 "Anexo C") e as especificações da OpenID Foundation para OpenID for Verifiable Presentations (OpenID4VP) e OpenID for Verifiable Credential Issuance (OpenID4VCI).

• Origem e Padronização: org.iso.mdoc refere-se ao formato de dados e modelo de interação para documentos móveis, principalmente Carteiras de Motorista Móveis (mDLs), padronizados pela Organização Internacional para Padronização (ISO) e pela Comissão Eletrotécnica Internacional (IEC). O padrão fundamental é o ISO/IEC 18013-5, que define o aplicativo mDL, estrutura de dados e protocolos para apresentação presencial (proximidade) usando tecnologias como NFC, Bluetooth ou códigos QR. A ISO/IEC 18013-7 estende isso para permitir a apresentação online/remota de mDLs. A string de protocolo "org.iso.mdoc" é definida especificamente na ISO/IEC TS 18013-7 (Anexo C) para uso com APIs como a API de Credenciais Digitais.

• Modelo de Dados: mdocs têm uma estrutura de dados estritamente definida baseada em CBOR (Concise Binary Object Representation) para compacidade e eficiência. Ela especifica namespaces e elementos de dados para atributos comuns de carteira de motorista e suporta recursos de segurança criptográfica fortes, incluindo autenticação do emissor, vinculação ao dispositivo, autenticação do titular (via retrato), criptografia de sessão e divulgação seletiva.

• Casos de Uso Típicos: Principalmente documentos de identidade emitidos pelo governo, como carteiras de motorista e identidades nacionais. É projetado para cenários de alta garantia, tanto presenciais (ex: blitz de trânsito, verificação de idade para bens restritos) quanto online (ex: acesso a serviços do governo, verificação de identidade remota para abertura de conta bancária).

• Origem e Padronização: OpenID4VP (para apresentação) e OpenID4VCI (para emissão) são especificações desenvolvidas pela OpenID Foundation. Elas estendem o OAuth 2.0 para suportar a troca de credenciais verificáveis. São padrões abertos voltados para ampla interoperabilidade para vários tipos de credenciais, não apenas governamentais. No início de 2025, o OpenID4VP está em estágios avançados de rascunho (ex: rascunho 28 em Abril). OpenID4VCI também está amadurecendo.
• Modelo de Dados: OpenID4VP/VCI são projetados para serem agnósticos ao formato da credencial. Eles podem transportar Credenciais Verificáveis (VCs) do W3C em formatos JSON/JSON-LD ou JWT, mdocs, SD-JWTs e outros formatos. O modelo de interação envolve uma Solicitação de Autorização do Verificador (RP) e uma resposta da Carteira do Titular contendo um vp_token (Token de Apresentação Verificável). A divulgação seletiva é tipicamente gerenciada usando linguagens de consulta como Presentation Exchange (DIF PE) ou a mais nova Digital Credentials Query Language (DCQL).
• Casos de Uso Típicos: Ampla gama de aplicações, incluindo verificação de identidade, fornecimento de prova de qualificações (ex: diplomas educacionais, certificações profissionais), atestados de associação e muito mais. Eles são bem adequados para interações online onde uma Relying Party precisa verificar reivindicações de vários emissores.

É importante reconhecer que eles nem sempre são mutuamente exclusivos. O OpenID4VP pode, por exemplo, ser usado para solicitar e transportar um [org.iso.mdoc]. A escolha muitas vezes depende do caso de uso específico, do tipo de credencial e dos participantes do ecossistema.

A Carteira de Identidade Digital da União Europeia (EUDI) é uma grande iniciativa que visa fornecer a todos os cidadãos e residentes da UE uma carteira digital segura para documentos de identidade e atestados. A arquitetura e o framework de referência da EUDI Wallet planejam explicitamente suportar tanto mdoc (particularmente para Carteiras de Motorista Móveis) quanto Credenciais Verificáveis do W3C, utilizando OpenID4VP e OpenID4VCI para fluxos de apresentação e emissão. A implementação de referência inclui suporte para OpenID4VP transferindo mDocs e OpenID4VCI para emitir PIDs e mDLs em formatos mDoc e SD-JWT-VC. Esse suporte duplo por um projeto de larga escala destaca a importância de ambas as famílias de protocolos.

Atualização de Março de 2026: O compromisso da UE com a API de Credenciais Digitais tornou-se mais concreto. O Tópico F do Framework de Referência de Arquitetura (ARF) da EUDI agora exige condicionalmente que Unidades de Wallet da EUDI e Relying Parties suportem a DC API para apresentação remota e fluxos de emissão de atestados. As condições incluem que a DC API alcance o status de Recomendação do W3C e atenda às expectativas em torno de funcionalidade, neutralidade de navegador/SO, privacidade e proteção contra negação de serviço. O Consórcio Europeu de Wallets (EWC) incorporou casos de teste da DC API em seu programa de testes de conformidade, e o consórcio NOBID completou pilotos de pagamento usando OpenID4VP — o mesmo protocolo que a DC API agora transporta.

No entanto, essa direção não é isenta de críticas, pois alguns observadores notam que a API de Credenciais Digitais, fortemente influenciada por "Big Techs dos EUA", pode se tornar profundamente incorporada às especificações finais da EUDI Wallet. Preocupações foram levantadas sobre a influência potencial de entidades não pertencentes à UE em uma peça crítica da infraestrutura da UE, como discutido em fóruns da comunidade como nesta discussão no GitHub. Separadamente, a decisão de codificar a referência ISO 18013-7 na especificação gerou uma objeção da Ping Identity, argumentando que referenciar normativamente uma especificação paga conflita com os princípios da web aberta — uma preocupação que pode surgir como uma objeção formal quando a especificação transitar para Recomendação Candidata.

O cenário dos navegadores para a API de Credenciais Digitais agora tomou forma, com Chrome 141 e Safari 26 lançando suporte estável em Setembro de 2025. Existem diferenças notáveis na abordagem e nos níveis de suporte entre os navegadores.

O Chrome lançou a API de Credenciais Digitais no Chrome 141 (30 de Set, 2025). A implementação do Chrome é agnóstica a protocolos: compatível com OpenID4VP e ISO 18013-7 Anexo C (mdoc online). O desktop suporta apresentação cross-device de wallets móveis via um canal apoiado por CTAP/BLE (handoff por QR code), com a resposta opaca para o navegador. A forma da API mudou para navigator.credentials.get(); parâmetros renomeados: providers → requests, request → data.

Detecção de Recurso:

if (typeof DigitalCredential !== "undefined") {
    // API de Credenciais Digitais suportada
}

O Gerenciador de Credenciais do Android suporta nativamente OpenID4VP para apresentação e OpenID4VCI para emissão, permitindo que aplicativos Android atuem como titulares de credenciais e verificadores usando esses padrões. O Google observa um suporte crescente de wallets; Google Wallet é um adotante inicial, com Samsung Wallet e 1Password anunciados.

Em versões anteriores deste artigo, previmos que a abordagem da Apple divergiria da do Google focando no protocolo org.iso.mdoc. Para contexto histórico, nosso raciocínio foi o seguinte:

Como antecipamos corretamente, a WWDC25 confirmou essa estratégia. O Safari 26 (iOS/iPadOS/macOS) foi lançado em 15 de Set, 2025 com suporte à API de Credenciais Digitais, confirmando que sua implementação suporta exclusivamente o protocolo org-iso-mdoc para apresentação.

Isso foi detalhado na sessão da WWDC25 Verificar documentos de identidade na web. A API permite que sites solicitem informações verificáveis de documentos de identidade, como uma carteira de motorista, armazenados na Apple Wallet ou em aplicativos provedores de documentos de terceiros.

Principais pontos da implementação da Apple:

• Apenas MDOC: A API usa exclusivamente a string de protocolo "org-iso-mdoc", baseada no padrão ISO/IEC 18013-7 Anexo C. Não há suporte para OpenID4VP na implementação do Safari da API de Credenciais Digitais.
• Apenas Apresentação: A API é para apresentação (verificação) de credenciais existentes. A emissão para a Apple Wallet ou outros aplicativos permanece um processo separado, fora do navegador.
• Centrado no Usuário e Seguro: O fluxo é iniciado por um gesto do usuário e aproveita um mecanismo de "solicitação parcial", onde o SO primeiro analisa e valida a solicitação em um sandbox antes de passá-la para o aplicativo da carteira, aumentando a segurança.
• Extensível a Apps: Além da Apple Wallet, aplicativos de terceiros podem atuar como provedores de documentos implementando o novo framework IdentityDocumentServices e uma extensão de aplicativo.
• Suporte Cross-Device: A apresentação cross-device de plataformas não-Apple usa CTAP para proximidade após um handoff via código QR; a resposta JS permanece criptografada/opaca para o navegador.

A Apple forneceu um exemplo de código claro de como uma relying party usaria a API:

async function verifyIdentity() {
    try {
        // O servidor gera e assina criptograficamente os dados da solicitação.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // A solicitação especifica o protocolo 'org-iso-mdoc'.
        const request = {
            protocol: "org-iso-mdoc",
            // data contém a solicitação mdoc assinada criptograficamente.
            data,
        };
 
        // A API deve ser chamada de dentro de um gesto do usuário.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Envia a resposta criptografada da carteira para o servidor para descriptografia e validação.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Exibe os detalhes verificados...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Lida com erros, ex: cancelamento do usuário.
    }
}

Esta confirmação solidifica as estratégias divergentes no mercado de navegadores. Enquanto o Chrome constrói sobre a camada de transporte flexível OpenID4VP, a Apple está aproveitando seu profundo investimento no ecossistema ISO mdoc para fornecer uma solução altamente integrada e segura, embora menos flexível, adaptada para documentos de identidade oficiais.

A Mozilla expressou originalmente uma posição negativa sobre o padrão da API de Credenciais Digitais. Suas preocupações, documentadas em detalhes, são abrangentes e enraizadas em sua missão de proteger a privacidade do usuário, a agência e garantir uma web aberta e equitativa.

As principais preocupações levantadas pela Mozilla incluem:

• Riscos de Privacidade: Potencial para aumento do compartilhamento de dados pessoais e redução do anonimato online se as solicitações de credenciais digitais se tornarem comuns para interações triviais.
• Exclusão de Usuários: Risco de que indivíduos que não podem ou optam por não usar credenciais digitais possam ser excluídos de serviços e comunidades online. Credenciais emitidas pelo governo, um caso de uso primário, podem não se alinhar com a escolha de apresentação de identidade de um indivíduo.
• Problemas de Interoperabilidade: Preocupações sobre a proliferação de formatos de credenciais levando a um ecossistema fragmentado em vez de um universalmente interoperável.
• Divulgação Seletiva: Receios de que os benefícios de privacidade da divulgação seletiva possam ser prejudicados se não implementados com fortes garantias de desvinculação, ou se os usuários não entenderem completamente o que está sendo compartilhado.
• Centralização da Confiança e Agência do Usuário: Medos de que a API possa levar ao aumento da centralização da confiança e a uma redução na agência do usuário, perpetuando desequilíbrios de poder social existentes.

Embora um Conselho do W3C tenha anulado uma objeção formal relacionada a essas preocupações (para permitir que o trabalho prossiga dentro do W3C em vez de locais potencialmente menos transparentes), o Conselho recomendou que o Grupo de Trabalho trabalhe ativamente para mitigar esses danos potenciais.

Atualização de Março de 2026 — Implementação em andamento: Apesar da posição negativa formal permanecer tecnicamente inalterada, a Mozilla começou a implementar ativamente a API de Credenciais Digitais. No 1º trimestre de 2026, o suporte base à DC API chegou ao Firefox 149 (atrás de uma flag de preferência), rastreado sob o meta bug 2004828. O código fonte está no mozilla-central, incluindo DigitalCredential.cpp, bindings WebIDL e encanamento IPC. O trabalho em prompts de permissão para desktop e Android (bug 2010091, bug 2010093) está em andamento.

Três engenheiros da Mozilla — John Schanck, Martin Thomson e Benjamin VanderSloot — são membros ativos do Grupo de Trabalho FedID do W3C, e Schanck tem fornecido feedback substantivo informado pela implementação em PRs chave da especificação, incluindo o algoritmo de apresentação de credencial e o algoritmo de preparação de solicitação.

Este é um desenvolvimento significativo: embora a Mozilla mantenha suas preocupações sobre o potencial de mau uso da API, ela está evidentemente escolhendo moldar a API de dentro — através tanto do trabalho na especificação quanto da implementação — em vez de ceder o design a outros fornecedores de navegadores. Isso sinaliza que a API de Credenciais Digitais provavelmente está no caminho para o suporte em três navegadores, embora com a Mozilla pressionando por proteções de privacidade mais fortes (incluindo uma proposta de log de transparência para solicitações de credenciais).

Tabela 1: Suporte do Navegador para API de Credenciais Digitais e Protocolos (Março de 2026)

Para organizações (Relying Parties ou RPs) que pretendem solicitar e verificar credenciais digitais de usuários, o cenário atual requer um planejamento estratégico cuidadoso.

Dado que o Safari (lançado em 15 de Set, 2025) suporta exclusivamente interações org-iso-mdoc diretas (ISO 18013-7 Anexo C) através da API de Credenciais Digitais, e o Chrome (lançado em 30 de Set, 2025) é agnóstico a protocolos suportando tanto OpenID4VP quanto ISO 18013-7 Anexo C (mdoc), RPs que visam o maior alcance possível devem se preparar para suportar interações baseadas em ambas as abordagens.

Isso significa arquitetar sistemas que possam lidar com ambos os caminhos de protocolo, conforme mostrado abaixo.

Embora isso adicione complexidade, tentar forçar todos os usuários a seguir um único caminho de protocolo provavelmente excluirá uma parte substancial da base de usuários, sejam aqueles no iOS ou aqueles no Chrome/Android, dependendo do caminho escolhido. Uma abordagem pragmática, embora mais intensiva em desenvolvimento, é construir flexibilidade para lidar com ambos.

As Relying Parties devem estar cientes de que, mesmo ao solicitar a mesma peça lógica de informação (ex: "o usuário tem mais de 21 anos?"), como isso é definido em uma solicitação e como é retornado em uma resposta pode diferir significativamente entre uma consulta direta mdoc e uma consulta OpenID4VP (que pode usar Presentation Exchange ou DCQL).

• Divulgação Seletiva mdoc: org.iso.mdoc tem seus próprios mecanismos para divulgação seletiva, tipicamente envolvendo o emissor criando hashes com salt de elementos de dados individuais. A carteira do titular então revela apenas os elementos solicitados juntamente com seus salts, permitindo que o verificador os confirme contra os hashes sem ver outros dados. A solicitação para elementos específicos está ligada a namespaces predefinidos e identificadores de elementos de dados dentro do padrão mdoc.
• Divulgação Seletiva OpenID4VP: OpenID4VP tipicamente usa uma linguagem de consulta como Presentation Exchange (DIF PE) ou a mais nova Digital Credentials Query Language (DCQL) embutida na presentation_definition da solicitação. Isso permite que RPs especifiquem os tipos de credenciais e reivindicações individuais que precisam. A carteira então constrói uma Apresentação Verificável contendo apenas as informações solicitadas, se suportado pelo formato da credencial e pela carteira.

RPs precisam mapear seus requisitos de dados específicos para essas estruturas de protocolo variadas. É crucial entender as nuances de como a divulgação seletiva é implementada e solicitada em cada protocolo para garantir que apenas os dados mínimos necessários sejam solicitados e processados, aderindo assim às melhores práticas de privacidade e princípios de minimização de dados. O formato e a estrutura dos dados divulgados retornados pela carteira também podem diferir, exigindo lógica de análise e validação distinta no backend da RP.

Para entidades que buscam emitir credenciais digitais e fornecer aplicativos de carteira para titulares, o ambiente do sistema operacional desempenha um papel crucial.

Emissores de carteiras enfrentam cenários distintamente diferentes no iOS e Android no que diz respeito à criação de carteiras, integração do sistema e interação com a API de Credenciais Digitais.

• Android: Geralmente oferece um ecossistema mais aberto. O Gerenciador de Credenciais do Android inclui uma API de Titular (Holder API) que permite que aplicativos nativos de terceiros se registrem como titulares de credenciais. Esses apps titulares registrados podem então participar de fluxos de apresentação de credenciais mediados pelo sistema, respondendo a solicitações da API de Credenciais Digitais (via Chrome) ou verificadores de app nativo. O Android também suporta explicitamente OpenID4VCI para emissão de credenciais, permitindo que os usuários escolham uma carteira de terceiros compatível para receber credenciais recém-emitidas. Embora apps nativos sejam o foco principal para capacidades completas de titular de credenciais, o sistema é projetado para uma participação mais ampla.

• iOS: A Apple mantém um controle mais rígido sobre seu ecossistema. Embora aplicativos de carteira de terceiros possam existir na App Store, sua capacidade de se integrar profundamente como titulares de credenciais em nível de sistema para credenciais de alta garantia (como mDLs destinadas à Apple Wallet) está frequentemente sujeita aos processos e direitos específicos da Apple. Adicionar um ID à Apple Wallet, por exemplo, é um fluxo controlado envolvendo autoridades emissoras estaduais e a verificação da Apple. Para a API de Credenciais Digitais no Safari, as interações provavelmente serão gerenciadas de perto, com um foco primário em org.iso.mdoc apresentado de fontes autorizadas, nomeadamente a própria Apple Wallet e aplicativos provedores de documentos de terceiros registrados.

A abordagem de "jardim murado" da Apple é bem estabelecida, e sua implementação de credenciais digitais não é exceção. No entanto, a WWDC25 esclareceu o caminho para a participação de terceiros.

Embora a Apple Wallet seja o provedor principal integrado para credenciais como mDLs estaduais, a Apple introduziu o framework IdentityDocumentServices para apps nativos iOS. Isso permite que desenvolvedores terceiros criem aplicativos que possam provisionar e apresentar seus próprios documentos de identidade.

Para participar do fluxo web, um app nativo deve:

1. Registrar Documentos: Usar o IdentityDocumentProviderRegistrationStore para registrar os mdocs que o app gerencia com o sistema operacional. Este registro inclui o tipo de documento e as autoridades de certificação confiáveis para assinatura de solicitação.
2. Implementar uma Extensão de App: Adicionar uma Extensão de App de UI "Identity Document Provider" ao projeto. Esta extensão é responsável por exibir a UI de autorização ao usuário quando o app é selecionado durante um fluxo de verificação baseado na web.

Isso significa que, embora criar uma carteira totalmente integrada no iOS exija a construção de um aplicativo nativo e o uso de frameworks específicos da Apple — não tecnologias web como PWAs — existe um mecanismo claro, embora rigidamente controlado, para apps de terceiros atuarem como provedores de documentos ao lado da Apple Wallet. Isso confirma que a interação com a API de Credenciais Digitais no Safari é gerenciada pelo SO, que então despacha solicitações para a Apple Wallet ou qualquer outro aplicativo provedor de documentos registrado e autorizado.

A API de Credenciais Digitais representa um avanço significativo no espaço de identidade digital, oferecendo uma abordagem mais segura, centrada no usuário e preservadora da privacidade para verificação de identidade e apresentação de credenciais. Com Chrome 141 (30 de Set, 2025) e Safari 26 (15 de Set, 2025) lançando suporte estável à apresentação, e Firefox 149 agora trazendo código de implementação base, a API está a caminho de uma cobertura nos três navegadores. Manteremos este artigo atualizado à medida que o cenário mudar.

O período desde Outubro de 2025 foi definido pelo amadurecimento da API de canal experimental para padrão governado. A eliminação do registro aberto de protocolos na TPAC (Novembro 2025) é o sinal mais claro: o W3C FedID WG agora nomeia e governa explicitamente os protocolos que a API suporta. Isso permite uma revisão abrangente de segurança e privacidade, mas também torna o Grupo de Trabalho um guardião — uma troca deliberada com a qual nem todos os participantes estão confortáveis (notavelmente, a objeção de paywall da ISO da Ping Identity permanece não resolvida).

Enquanto isso, a API está se expandindo da apresentação para o ciclo de vida completo: o Origin Trial de emissão do Chrome 143 via navigator.credentials.create() permite que sites acionem o provisionamento de carteiras. Mas uma vulnerabilidade de vinculação de seleção de carteira — onde apps de carteira maliciosos podem interceptar códigos de emissão — está bloqueando a adoção governamental desse recurso.

Na frente regulatória, o Tópico F do ARF da UE requer condicionalmente o suporte à DC API para todas as wallets dos estados membros da EUDI, aguardando que a especificação alcance a Recomendação W3C. A adoção no mundo real está acelerando: o DMV da Califórnia adicionou suporte à DC API, e suítes de teste de conformidade estão sendo desenvolvidas pelo Consórcio Europeu de Wallets.

Desafios permanecem. A realidade de protocolo duplo (suporte multiprotocolo do Chrome versus foco apenas mdoc do Safari) persiste para relying parties. A questão de se os navegadores devem suportar todos os protocolos listados ou apenas um não está resolvida — diretamente ligada às restrições da plataforma da Apple. E considerações de privacidade permanecem a maior lacuna única impedindo o progresso em direção à Recomendação Candidata, com requisitos normativos para critérios de inclusão de protocolo ainda não escritos. Estima-se que a especificação esteja a 1–2 anos da Recomendação W3C.

O Safari 26 usa exclusivamente a string de protocolo org-iso-mdoc, enquanto o Chrome 141 suporta tanto OpenID4VP quanto ISO 18013-7 Anexo C. As Relying Parties devem detectar o navegador e rotear para o caminho de protocolo apropriado. A divulgação seletiva também difere: o mdoc usa hashes com salt em namespaces predefinidos, enquanto o OpenID4VP usa linguagens de consulta como Presentation Exchange ou DCQL.

A Mozilla implementou o código base da DC API no Firefox 149 (1º tri 2026), embora sua posição formal negativa permaneça tecnicamente inalterada. A Mozilla está escolhendo moldar a API de dentro em vez de ceder o design a outros fornecedores. Três engenheiros da Mozilla são membros ativos do Grupo de Trabalho FedID do W3C, fornecendo feedback informado pela implementação em pull requests chave da especificação.

Uma vulnerabilidade de vinculação de seleção de carteira permite que apps de carteira maliciosos interceptem códigos de pré-autorização de emissão durante fluxos acionados por navigator.credentials.create(). Emissores governamentais declararam que não adotarão a emissão mediada por navegador até que isso seja resolvido. O Chrome 143 lançou um Origin Trial para emissão via OpenID4VCI, mas a vulnerabilidade permanece aberta no início de 2026.

As condições do Tópico F do ARF da EUDI incluem que a DC API alcance o status de Recomendação W3C e atenda às expectativas em torno de funcionalidade, neutralidade de navegador/SO, privacidade e proteção contra negação de serviço. O Consórcio Europeu de Wallets incorporou casos de teste da DC API em seu programa de testes de conformidade. Estima-se atualmente que a especificação esteja a 1 a 2 anos da Recomendação W3C.

O Grupo de Trabalho FedID do W3C codificou cinco identificadores de protocolo: openid4vp-v1-unsigned, openid4vp-v1-signed, openid4vp-v1-multisigned e org-iso-mdoc para apresentação, além de openid4vci-v1 para emissão. Espera-se que os agentes de usuário rejeitem qualquer protocolo que não esteja nesta lista. A Ping Identity levantou uma objeção formal à inclusão da ISO 18013-7, citando preocupações sobre referenciar normativamente uma especificação paga.