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

Última atualização: 30 de outubro de 2025

Um resumo rápido do suporte à API de Credenciais Digitais nos principais navegadores:

O mundo das credenciais digitais está a evoluir rapidamente. Aqui está um resumo dos principais desenvolvimentos e projeções:

Want to experience digital credentials in action?

Try Digital Credentials

O que mudou desde julho de 2025?

• Lançado: Chrome 141 (30 de setembro de 2025) e Safari 26 (15 de setembro de 2025).
• Chrome: Agnóstico a protocolos (OpenID4VP e ISO 18013-7 Anexo C), cross-device em desktop via CTAP.
• Safari: Apenas mdoc (org-iso-mdoc), fluxo cross-device via CTAP.
• Formato da API: navigator.credentials.get(); nomenclatura requests/data; deteção de recurso DigitalCredential.

As credenciais digitais são um tema quente no espaço da identidade atualmente. À medida que as nossas vidas se tornam cada vez mais conectadas com o mundo digital, a necessidade de formas seguras, centradas no utilizador e que preservem a privacidade para afirmar a nossa identidade e qualificações online nunca foi tão crítica. Os métodos tradicionais estão a mostrar a sua idade, e a procura 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 a forma como interagimos com as informações de identidade na web. Exploraremos os seus mecanismos subjacentes, os protocolos que suporta, a adoção atual pelos navegadores e ofereceremos recomendações tanto para as relying parties como para os emissores de wallets que navegam neste cenário em rápida evolução.

Provar a identidade de forma fiá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, também abriu novos caminhos para a falsificação de identidade e fraude.

Em alguns países, surgiram soluções, impulsionadas principalmente por consórcios bancários pioneiros que desenvolveram serviços para alavancar relações de confiança existentes para a identificação online. Os governos também intervieram, aplicando ou fornecendo carteiras e serviços de identidade digital nacionais. No entanto, essas soluções eram muitas vezes isoladas, geograficamente limitadas e não universalmente interoperáveis.

O recurso para a verificação de identidade em muitas regiões tem sido tradicionalmente processos de alta fricção. A verificação física numa estação de correios, por exemplo, introduz atrasos e inconvenientes significativos. As videochamadas combinadas com o upload de documentos tornaram-se uma alternativa mais digital, seguidas pelo surgimento mais recente da digitalização automatizada de documentos e verificações de prova de vida. Apesar dos seus avanços, estes métodos têm desvantagens significativas. Podem ser demorados, propensos a erro humano ou preconceito, e foram frequentemente expostos como vulneráveis a falsificações sofisticadas.

O desafio está a escalar drasticamente com o advento de deepfakes, técnicas avançadas de personificação impulsionadas por IA e ataques de phishing cada vez mais sofisticados. Estas tecnologias podem criar provas de vídeo, áudio e documentos altamente realistas, mas totalmente fabricadas, tornando incrivelmente difícil para os sistemas tradicionais, e até mesmo para as ferramentas de verificação baseadas em IA, distinguir utilizadores genuínos de fraudulentos. O potencial para criar identidades sintéticas ou manipular dados biométricos para contornar as verificações é uma ameaça séria, particularmente para instituições financeiras e qualquer serviço que exija processos robustos de Know Your Customer (KYC). Este cenário de ameaças crescente sublinha a necessidade urgente de mecanismos de identidade e verificação online mais seguros e criptograficamente verificáveis.

Want to experience digital credentials in action?

Try Digital Credentials

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

Na 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: Uma entidade (ex: governo, universidade, empregador) que tem autoridade sobre certas informações de um sujeito e pode emitir uma credencial digital que ateste essa informação.
2. Titular: O sujeito da informação (ou seja, o utilizador) que recebe a credencial do emissor e a armazena numa carteira digital. O titular controla quando e que informação da credencial é partilhada.
3. Verificador (ou Relying Party): Uma entidade (ex: um site, um serviço online) que precisa de verificar certas informações sobre o titular para conceder acesso a um serviço ou recurso. O verificador solicita a informação necessária ao titular.

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

Um aspeto fundamental destes sistemas é o envolvimento de pares de chaves criptográficas. O emissor assina digitalmente a credencial, garantindo a sua autenticidade e integridade. O titular, por sua vez, usa a sua chave privada, muitas vezes protegida dentro da sua carteira digital (que é protegida pelo hardware do dispositivo), para provar o controlo sobre a credencial e para autorizar a sua apresentação a um verificador. Isto geralmente envolve o verificador apresentar 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, uma vez que os princípios centrais de emissão, posse e verificação através de desafios criptográficos são comuns a diferentes tecnologias subjacentes.

Este artigo concentra-se na verificação de credenciais digitais e no princípio da divulgação seletiva, permitindo aos utilizadores provar atributos específicos (ex: "tenho mais de 18 anos", "possuo uma carta de condução válida") sem revelar o documento de origem completo. 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 asserçã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 aspeto diferente do ecossistema, desde o próprio formato dos dados até à forma como são apresentados a um utilizador num navegador web. Este artigo foca-se principalmente na API de Credenciais Digitais, que opera na camada de apresentação.

Terminologia Essencial:

• 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 a verificabilidade criptográfica.
• Credencial Verificável: Um tipo de credencial digital, definida pelo Modelo de Dados W3C VC. Adiciona evidência de adulteração e prova criptográfica, e vive sempre num mundo de três partes: emissor → titular → verificador.
• API de Credenciais Verificáveis: 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 (API DC): Uma API de navegador / sistema operativo (JavaScript + implementação nativa) que permite a um site pedir à carteira do lado do dispositivo do utilizador para apresentar qualquer credencial digital suportada (VC, ISO mDoc, SD-JWT…) de uma forma que respeite a privacidade.

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

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

1. Emitir (API VC - emissor ↔ carteira): A Direção-Geral de Viação emite uma Credencial Verificável que diz "O titular tem mais de 18 anos".
2. Armazenar (App da Carteira - SO): A credencial fica na carteira do utilizador com a sua prova criptográfica.
3. Solicitar (navigator.credentials.get() via API DC - site → navegador): O site da loja de cervejas pergunta: "Mostre-me uma prova de que o utilizador tem ≥18 anos."
4. Apresentar (API DC encaminha para a carteira → OpenID4VP (protocolo) → payload VC): A carteira mostra uma interface de consentimento, o utilizador aprova, a carteira envia de volta uma apresentação verificável.
5. Verificar (API VC - back-end da loja de cervejas): O back-end do site verifica a assinatura e a DID/chave pública do emissor; concede acesso.

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

Porque existe esta divisão:

• 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 API VC.
• Handshake entre Carteira e site que preserva a privacidade: Resolvido pela API DC.
• Diferentes níveis de confiança / tipos de documentos (documento de identidade governamental vs. certificado de curso): Resolvido usando o formato certo (ISO mDoc para identificações de alta garantia; W3C VC para alegações gerais) por baixo da API DC.

Pontos-chave:

1. "Credencial digital" é o termo abrangente.
2. Credencial Verificável é um tipo de credencial digital com verificabilidade criptográfica incorporada.
3. A API VC é a infraestrutura de servidor para servidor para operações de ciclo de vida em VCs.
4. A API de Credenciais Digitais é a ponte entre o navegador e a carteira que finalmente permite que essas credenciais fluam suavemente para as aplicações Web, seja qual for o formato concreto em que estejam.
5. As três peças são complementares, não concorrentes — situam-se em diferentes camadas da mesma pilha e, juntas, permitem uma identidade segura e centrada no utilizador na Web aberta.

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

Como componente crucial na camada de apresentação, a API de Credenciais Digitais é um padrão web atualmente em desenvolvimento para fornecer uma forma segura e padronizada para os sites solicitarem e receberem informações de identidade digital das carteiras digitais dos utilizadores. Este esforço está principalmente alojado no Federated Identity Working Group (FedID WG) do W3C, tendo migrado do FedID Community Group em abril de 2025. A especificação oficial preliminar pode ser encontrada aqui: https://w3c-fedid.github.io/digital-credentials/.

Até outubro de 2025, a API foi lançada em versões estáveis tanto do Chrome 141 (30 de setembro de 2025) como do Safari 26 (15 de setembro de 2025). A implementação do Chrome é agnóstica a protocolos, suportando tanto OpenID4VP como ISO 18013-7 Anexo C, enquanto o Safari suporta exclusivamente o protocolo org-iso-mdoc. O Chrome suporta isto nativamente no Android através do seu sistema Credential Manager e também suporta a API de Credenciais Digitais Cross-Device no desktop via um handoff por QR code com suporte de CTAP/BLE.

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

Eis 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 {
            // Estes parâmetros são tipicamente obtidos do backend.
            // Definidos estaticamente aqui para fins de ilustração da extensibilidade do protocolo.
            const oid4vp = {
                protocol: "oid4vp", // Um exemplo de uma solicitação OpenID4VP para wallets. // Baseado em https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Solicitação de Presentation Exchange, omitida para 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 encriptada para o backend para decifragem e verificação
            // Omitido para brevidade
        } catch (error) {
            console.error("Erro:", error);
        }
    } else {
        // cenário alternativo, apenas ilustrativo
        alert("A API de Credenciais Digitais não é suportada neste navegador.");
    }
}

Este exemplo foi retirado de aqui.

A API de Credenciais Digitais atua essencialmente como um invólucro ou intermediário seguro. Permite que o navegador medeie a solicitação de informação de identidade, aproveitando as capacidades do sistema operativo subjacente para descobrir carteiras e credenciais disponíveis que correspondam à solicitação. O navegador e o SO podem então apresentar uma interface de utilizador consistente para selecionar a credencial e autorizar a sua libertação, melhorando a segurança e a privacidade ao garantir o consentimento do utilizador e impedindo que os sites acedam silenciosamente a dados sensíveis. Os dados reais da credencial na resposta destinam-se a ser opacos (encriptados) para o próprio navegador, com a decifragem e interpretação a serem tratadas pela relying party e pela carteira/titular.

A API de Credenciais Digitais foi concebida para ser agnóstica a protocolos, o que significa que pode suportar vários protocolos subjacentes para a troca de credenciais. No entanto, duas famílias principais de protocolos são centrais para as implementações e discussões atuais: org.iso.mdoc (derivado da ISO 18013-5 e da sua extensão ISO 18013-7 "Anexo C") e as especificações OpenID for Verifiable Presentations (OpenID4VP) e OpenID for Verifiable Credential Issuance (OpenID4VCI) da OpenID Foundation.

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

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

• Casos de Uso Típicos: Principalmente documentos de identidade emitidos pelo governo, como cartas de condução e bilhetes de identidade nacionais. É projetado para cenários de alta garantia, tanto presenciais (ex: operações stop, verificação de idade para produtos restritos) como online (ex: aceder a serviços governamentais, 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. Estes são padrões abertos que visam uma 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). O OpenID4VCI também está a amadurecer.
• 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 um Pedido de Autorização do Verificador (RP) e uma resposta da Wallet do Titular contendo um vp_token (Token de Apresentação Verificável). A divulgação seletiva é tipicamente gerida usando linguagens de consulta como Presentation Exchange (DIF PE) ou a mais recente Digital Credentials Query Language (DCQL).
• Casos de Uso Típicos: Vasta gama de aplicações, incluindo verificação de identidade, fornecimento de prova de qualificações (ex: diplomas educacionais, certificações profissionais), atestados de filiação e mais. São adequados para interações online onde uma relying party precisa verificar alegações de vários emissores.

É importante reconhecer que estes não são sempre mutuamente exclusivos. O OpenID4VP pode, por exemplo, ser usado para solicitar e transportar um [org.iso.mdoc]. A escolha depende muitas vezes 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 quadro de referência da EUDI Wallet planeiam explicitamente suportar tanto mdoc (particularmente para Cartas de Condução Móveis) como Credenciais Verificáveis W3C, utilizando OpenID4VP e OpenID4VCI para os fluxos de apresentação e emissão. A implementação de referência inclui suporte para OpenID4VP a transferir mDocs e OpenID4VCI a emitir PIDs e mDLs em formatos mDoc e SD-JWT-VC formats. Este duplo suporte por um projeto de tão grande escala sublinha a importância de ambas as famílias de protocolos. No entanto, esta direção não está isenta de críticas, pois alguns observadores notam que a API de Credenciais Digitais, fortemente influenciada por empresas "Bigtech dos EUA", pode tornar-se profundamente incorporada nas especificações finais da EUDI Wallet. Foram levantadas preocupações sobre a potencial influência de entidades não pertencentes à UE numa peça crítica da infraestrutura da UE, conforme discutido em fóruns comunitários como esta discussão no GitHub.

O panorama dos navegadores para a API de Credenciais Digitais já tomou forma, com o Chrome 141 e o Safari 26 a lançarem 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 setembro de 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 a apresentação cross-device a partir de carteiras móveis através de um canal suportado por CTAP/BLE (handoff por QR), com a resposta a ser opaca para o navegador. O formato da API mudou para navigator.credentials.get(); parâmetros renomeados: providers → requests, request → data.

Deteção de Recurso:

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

O Credential Manager do Android suporta nativamente OpenID4VP para apresentação e OpenID4VCI para emissão, permitindo que aplicações Android atuem como detentoras e verificadoras de credenciais usando estes padrões. A Google nota um crescente suporte de carteiras; a Google Wallet é uma das primeiras a adotar, com a Samsung Wallet e o 1Password anunciados.

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

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

Isto foi detalhado na sessão da WWDC25 Verify identity documents on the web. A API permite que os sites solicitem informações verificáveis de documentos de identidade, como uma carta de condução, armazenados na Apple Wallet ou em aplicações de fornecedores de documentos de terceiros.

Principais conclusões 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 da API de Credenciais Digitais do Safari.
• Apenas Apresentação: A API é para apresentação (verificação) de credenciais existentes. A emissão para a Apple Wallet ou outras aplicações permanece um processo separado, fora do navegador.
• Centrado no Utilizador e Seguro: O fluxo é iniciado por um gesto do utilizador e utiliza um mecanismo de "solicitação parcial", onde o SO primeiro analisa e valida a solicitação numa sandbox antes de a passar para a aplicação da carteira, melhorando a segurança.
• Extensível a Aplicações: Além da Apple Wallet, aplicações de terceiros podem atuar como fornecedores de documentos implementando a nova framework IdentityDocumentServices e uma extensão de aplicação.
• Suporte Cross-Device: A apresentação cross-device a partir de plataformas não-Apple usa CTAP para proximidade após um handoff por código QR; a resposta JS permanece encriptada/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 a partir de um gesto do utilizador.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Envia a resposta encriptada da carteira para o servidor para decifragem e validação.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Apresenta os detalhes verificados...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Trata erros, ex: cancelamento pelo utilizador.
    }
}

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

A Mozilla expressou formalmente uma posição negativa sobre os padrões da API de Credenciais Digitais, na sua forma atual. As suas preocupações são abrangentes e estão enraizadas na sua missão de proteger a privacidade do utilizador, a sua autonomia e garantir uma web aberta e equitativa.

As principais preocupações levantadas pela Mozilla incluem:

• Riscos de Privacidade: Potencial para um aumento na partilha de dados pessoais e uma redução no anonimato online se as solicitações de credenciais digitais se tornarem comuns para interações triviais.
• Exclusão de Utilizadores: 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. As credenciais emitidas pelo governo, um caso de uso principal, podem não estar alinhadas com a escolha de apresentação de identidade de um indivíduo.
• Problemas de Interoperabilidade: Preocupações sobre uma proliferação de formatos de credenciais que leva 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 minados se não forem implementados com fortes garantias de desvinculação, ou se os utilizadores não entenderem completamente o que está a ser partilhado.
• Centralização da Confiança e Autonomia do Utilizador: Medo de que a API possa levar a uma maior centralização da confiança e a uma redução na autonomia do utilizador, perpetuando os desequilíbrios de poder sociais existentes.

A Mozilla reconhece que tal API poderia oferecer utilidade sobre os métodos ad-hoc existentes para apresentação de credenciais, mas enfatiza que os novos recursos da plataforma web devem demonstrar que melhoram a web em geral e priorizam os interesses dos utilizadores. Embora um Conselho do W3C tenha rejeitado uma objeção formal relacionada a estas preocupações (para permitir que o trabalho prossiga dentro do W3C em vez de em locais potencialmente menos transparentes), o Conselho recomendou que o Grupo de Trabalho trabalhasse ativamente para mitigar estes potenciais danos.

Tabela 1: Suporte do Navegador para a API de Credenciais Digitais e Protocolos (Out 2025)

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

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

Isto significa arquitetar sistemas que possam:

1. Iniciar solicitações de credenciais através da API navigator.credentials.get(), especificando diferentes parâmetros de protocolo ("org-iso-mdoc" para o Safari ou "openid4vp" para fluxos Chrome/OID4VP) com base na deteção do navegador ou nas capacidades do user agent.
2. Processar respostas que podem vir diretamente num formato mdoc (ISO 18013-7 Anexo C) ou como um vp_token via OpenID4VP, que depois precisa de ser analisado para extrair a credencial subjacente (que poderia ser ela própria um mdoc ou outro formato VC).

Embora isto adicione complexidade, tentar forçar todos os utilizadores a seguir um único caminho de protocolo provavelmente excluirá uma parte substancial da base de utilizadores, seja os que estão no iOS ou os que estão 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 perfeitamente cientes de que, mesmo ao solicitar a mesma peça lógica de informação (ex: "o utilizador tem mais de 21 anos?"), a forma como isto é definido numa solicitação e como é devolvido numa resposta pode diferir significativamente entre uma consulta mdoc direta e uma consulta OpenID4VP (que pode usar Presentation Exchange ou DCQL).

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

As RPs precisam de mapear os seus requisitos de dados específicos para estas estruturas de protocolo variáveis. É 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 são solicitados e processados, aderindo assim às melhores práticas de privacidade e aos princípios de minimização de dados. O formato e a estrutura dos dados divulgados devolvidos pela carteira também podem diferir, exigindo lógica de análise e validação distintas no backend da RP.

Para entidades que procuram emitir credenciais digitais e fornecer aplicações de carteira para os titulares, o ambiente do sistema operativo desempenha um papel crucial.

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

• Android: Geralmente oferece um ecossistema mais aberto. O Android Credential Manager inclui uma Holder API que permite que aplicações nativas de terceiros se registem como detentoras de credenciais. Estas aplicações detentoras registadas podem então participar em fluxos de apresentação de credenciais mediados pelo sistema, respondendo a solicitações da API de Credenciais Digitais (via Chrome) ou de verificadores de aplicações nativas. O Android também suporta explicitamente OpenID4VCI para emissão de credenciais, permitindo que os utilizadores escolham uma carteira de terceiros compatível para receber credenciais recém-emitidas. Embora as aplicações nativas sejam o foco principal para capacidades completas de detentor de credenciais, o sistema foi concebido para uma participação mais ampla.

• iOS: A Apple mantém um controlo mais rigoroso sobre o seu ecossistema. Embora possam existir aplicações de carteira de terceiros na App Store, a sua capacidade de se integrarem profundamente como detentores de credenciais ao nível do sistema para credenciais de alta garantia (como mDLs destinadas à Apple Wallet) está muitas vezes sujeita aos processos e autorizações específicas da Apple. Adicionar um documento de identidade à Apple Wallet, por exemplo, é um fluxo controlado que envolve as autoridades emissoras estatais e a verificação da Apple. Para a API de Credenciais Digitais no Safari, as interações serão provavelmente geridas de perto, com um foco principal em org.iso.mdoc apresentado a partir de fontes autorizadas, nomeadamente a própria Apple Wallet e aplicações de fornecedores de documentos de terceiros registadas.

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

Embora a Apple Wallet seja o fornecedor principal e integrado para credenciais como as mDLs estatais, a Apple introduziu a framework IdentityDocumentServices para aplicações nativas do iOS. Isto permite que desenvolvedores de terceiros construam aplicações que podem provisionar e apresentar os seus próprios documentos de identidade.

Para participar no fluxo web, uma aplicação nativa deve:

1. Registar Documentos: Usar a IdentityDocumentProviderRegistrationStore para registar os mdocs que a aplicação gere com o sistema operativo. Este registo inclui o tipo de documento e as autoridades de certificação confiáveis para a assinatura de solicitações.
2. Implementar uma App Extension: Adicionar uma App Extension de UI "Identity Document Provider" ao projeto. Esta extensão é responsável por exibir a interface de autorização ao utilizador quando a aplicação é selecionada durante um fluxo de verificação baseado na web.

Isto significa que, embora a criação de uma carteira totalmente integrada no iOS exija a construção de uma aplicação nativa e o uso das frameworks específicas da Apple — não de tecnologias web como PWAs — existe um mecanismo claro, embora rigorosamente controlado, para que as aplicações de terceiros atuem como fornecedores de documentos ao lado da Apple Wallet. Isto confirma que a interação com a API de Credenciais Digitais no Safari é gerida pelo SO, que depois encaminha as solicitações para a Apple Wallet ou qualquer outra aplicação fornecedora de documentos registada e autorizada.

A API de Credenciais Digitais representa um avanço significativo no espaço da identidade digital, oferecendo uma abordagem mais segura, centrada no utilizador e que preserva a privacidade para a verificação de identidade e apresentação de credenciais. Com o Chrome 141 (30 de setembro de 2025) e o Safari 26 (15 de setembro de 2025) a oferecerem agora suporte estável, a API passou de experimental para pronta para produção. À medida que o ecossistema continua a evoluir, é crucial que tanto as relying parties como os emissores de carteiras se adaptem e abracem o potencial desta nova tecnologia. Manteremos este artigo atualizado à medida que o cenário muda.

No entanto, os desafios permanecem. Alcançar uma verdadeira interoperabilidade global entre diferentes formatos de credenciais, protocolos e implementações de carteiras é uma tarefa significativa. Abordar as preocupações válidas levantadas por organizações como a Mozilla em relação à privacidade, exclusão e autonomia do utilizador é fundamental para garantir que estas tecnologias servem a humanidade. As abordagens divergentes — a implementação agnóstica a protocolos do Chrome versus o foco exclusivo em mdoc do Safari — significam que as relying parties e os emissores de carteiras devem navegar num cenário de protocolo duplo no futuro próximo.