API de Credenciais Digitais (2025): Chrome e Safari (WWDC25)

Última atualização: 15 de julho de 2025 (pós-WWDC25)

Uma visão geral rápida 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:

As credenciais digitais são um tema do momento no espaço da identidade. À 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 a informação de identidade na web. Vamos explorar os seus mecanismos subjacentes, os protocolos que suporta, a adoção atual nos navegadores e oferecer recomendações tanto para relying parties como para issuers de wallet 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 identificação online. Os Governos também intervieram, impondo ou fornecendo wallets e serviços de identidade digital nacionais. No entanto, estas soluções eram frequentemente isoladas, geograficamente limitadas e não universalmente interoperáveis.

O recurso para 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, seguida pelo surgimento mais recente da digitalização automatizada de documentos e liveness checks. 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 dos deepfakes, técnicas avançadas de personificação impulsionadas por IA e ataques de phishing cada vez mais sofisticados. Estas tecnologias podem criar evidências 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 alimentadas por 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 severa, 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 try digital credentials yourself in a demo?

Try Digital Credentials

Compreender como as credenciais digitais operam envolve olhar para os principais intervenientes envolvidos 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 é autoritativa para certas informações sobre um sujeito e pode emitir uma credencial digital que atesta essa informação.
2. Titular: O sujeito da informação (ou seja, o utilizador) que recebe a credencial do issuer e a armazena numa wallet digital. O titular controla quando e que informação da credencial é partilhada.
3. Verificador (ou Relying Party): Uma entidade (ex: um website, 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 partes sem a intermediação direta do utilizador, este modelo enfatiza o consentimento do utilizador e a divulgação seletiva. O titular decide que pedaços de 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 issuer 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 wallet 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 normalmente envolve o verificador apresentar um desafio (um pedaço de dados aleatório) que a wallet 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 termos de protocolo, pois 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 que os utilizadores provem 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 funcionalidades 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, está na assertion de identidade e verificação de atributos para interações online, e não primariamente nestas 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 formato dos dados em si 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 um código de barras, ISO mDL, W3C VC, SD-JWT, etc.). "Digital" não diz nada sobre a verificabilidade criptográfica.
• Verifiable Credential: Um tipo de credencial digital, definido pelo W3C VC Data Model. Adiciona evidência de adulteração e prova criptográfica, e vive sempre num mundo de três partes: emissor → titular → verificador.
• API de Credencial Verificável: Uma interface de serviço REST/HTTP para emitir, armazenar, apresentar e verificar VCs entre sistemas de back-end (issuers, wallets, verificadores).
• API de Credenciais Digitais (DC API): Uma API de navegador / sistema operativo (JavaScript + canalização nativa) que permite a um website pedir à wallet do dispositivo do utilizador para apresentar qualquer credencial digital suportada (VC, ISO mDoc, SD-JWT...) de uma forma que respeita a privacidade.

Pense nas VCs como um modelo de dados, na API de VC como uma especificação de back-end, e na DC API como a implementação de front-end que apresenta as 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 de VC - emissor ↔ wallet): O Departamento de Trânsito do estado emite uma Verifiable Credential que diz "O Titular tem mais de 18 anos".
2. Armazenar (App de Wallet - SO): A credencial fica na wallet do utilizador com a sua prova criptográfica.
3. Pedir (navigator.credentials.get() via DC API - website → navegador): O website da loja de cervejas pergunta: "Mostre-me uma prova de que o utilizador tem ≥18 anos."
4. Apresentar (DC API envia para a wallet → OpenID4VP (protocolo) → payload de VC): A wallet mostra uma interface de consentimento, o utilizador aprova, a wallet envia uma verifiable presentation de volta.
5. Verificar (API de VC - back-end da loja de cervejas): O back-end do site verifica a assinatura e o DID/chave pública do issuer; concede acesso.

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

Porque existe a divisão:

• Modelo de dados interoperável (provas criptográficas, divulgação seletiva): Resolvido pelo VC Data Model (e outros formatos).
• Endpoints REST padrão para sistemas de back-end: Resolvido pela API de VC.
• Handshake entre Wallet e Website que preserva a privacidade: Resolvido pela DC API.
• Diferentes níveis de confiança / tipos de documento (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.

Pontos-chave:

1. "Credencial digital" é o termo genérico.
2. Verifiable Credential é um tipo de credencial digital com verificabilidade criptográfica incorporada.
3. A API de VC é a canalização servidor-a-servidor para operações de ciclo de vida em VCs.
4. A API de Credenciais Digitais é a ponte navegador-para-wallet que finalmente permite que essas credenciais fluam suavemente para as aplicações Web, qualquer que seja 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 o 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 websites solicitarem e receberem informações de identidade digital das wallets 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 preliminar oficial pode ser encontrada aqui: https://w3c-fedid.github.io/digital-credentials/.

Até 2025, a API ainda é descrita como estando a passar por mudanças significativas. Isto destaca a sua fase de desenvolvimento ativo. Apesar disso, o seu potencial é significativo. O Chrome foi o primeiro a lançar algo público, com o seu Origin Trial, permitindo que os programadores experimentem as suas capacidades. O Chrome também suporta isto nativamente no Android através do seu sistema Credential Manager e publicou recentemente também suporte para o uso da API de Credenciais Digitais Cross-Device no desktop.

A API estende a API de Gestão de Credenciais existente, permitindo pedidos de credenciais digitais através de navigator.credentials.get(). De acordo com o W3C FedID WG Digital Credentials Explainer (https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md), a API reverteu para o uso desta interface estabelecida em vez da anteriormente proposta navigator.identity. Um website solicita uma credencial digital chamando navigator.credentials.get() com parâmetros específicos para credenciais digitais.

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

async function requestCredential() {
    // Check for Digital Credentials API support
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // These parameters are typically fetched from the backend.
            // Statically defined here for protocol extensibility illustration purposes.
            const oid4vp = {
                protocol: "oid4vp", // An example of an OpenID4VP request to wallets. // Based on https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Presentation Exchange request, omitted for brevity
                    },
                },
            };
 
            // create an Abort Controller
            const controller = new AbortController();
 
            // Call the Digital Credentials API using the presentation request from the backend
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Send the encrypted response to the backend for decryption and verification
            // Ommitted for brevity
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // fallback scenario, illustrative only
        alert("The Digital Credentials API is not supported in this browser.");
    }
}

Este exemplo foi retirado daqui.

A API de Credenciais Digitais atua essencialmente como um invólucro ou intermediário seguro. Permite que o navegador medie o pedido de informação de identidade, aproveitando as capacidades do sistema operativo subjacente para descobrir wallets e credenciais disponíveis que correspondam ao pedido. 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 websites acedam silenciosamente a dados sensíveis. Os dados da credencial na resposta destinam-se a ser opacos (encriptados) para o próprio navegador, com a desencriptação e interpretação a serem tratadas pela Relying Party e pela wallet/titular.

A API de Credenciais Digitais foi projetada para ser agnóstica em relação ao protocolo, o que significa que pode suportar vários protocolos subjacentes para a exchange 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 Normalizaçã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), normalizados pela Organização Internacional de Normalização (ISO) e pela Comissão Eletrotécnica Internacional (IEC). A norma fundamental é a 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 funcionalidades de segurança criptográfica, incluindo autenticação do issuer, vinculação ao dispositivo, autenticação do titular (via retrato), encriptação de 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: paragens de trânsito, verificação de idade para bens restritos) como online (ex: acesso a serviços governamentais, verificação remota de identidade para abertura de conta bancária).

• Origem e Normalizaçã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 normas abertas que visam uma ampla interoperabilidade para vários tipos de credenciais, não apenas governamentais. No início de 2025, o OpenID4VP está em fases avançadas de rascunho (ex: rascunho 28 em abril). O OpenID4VCI também está a amadurecer.
• Modelo de Dados: O OpenID4VP/VCI foi projetado para ser agnóstico 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), attestations de associação e mais. São adequados para interações online onde uma Relying Party precisa de verificar alegações de vários issuers.

É 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 frequentemente 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 wallet digital segura para documentos de identidade e attestations. 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 do 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 para emitir PIDs e mDLs em formatos mDoc e SD-JWT-VC. Este suporte duplo 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-UE numa peça crítica da infraestrutura da UE, como discutido em fóruns da comunidade, como esta discussão no GitHub.

O panorama dos navegadores para a API de Credenciais Digitais ainda está a tomar forma, com diferenças notáveis na abordagem e nos níveis de suporte.

O Google Chrome, particularmente no Android, tem sido um dos primeiros a adotar e implementar a API de Credenciais Digitais. Eles realizaram Origin Trials e integraram-na com o Credential Manager nativo do Android. A implementação do Chrome utiliza principalmente o OpenID4VP como o protocolo para solicitar credenciais através da chamada à API navigator.credentials.get(). Embora o OpenID4VP seja agnóstico ao formato e possa transportar org.iso.mdoc ou Credenciais Verificáveis do W3C como payloads, a ênfase prática da Google parece estar no fluxo OpenID4VP como o mecanismo de transporte. O Credential Manager do Android também suporta nativamente o OpenID4VP para apresentação e o OpenID4VCI para emissão. Isto permite que as aplicações Android atuem como detentores e verificadores de credenciais usando estas normas.

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 antecipámos corretamente, a WWDC25 confirmou esta estratégia. Na conferência, a Apple anunciou oficialmente o suporte para a API no Safari 26 (a ser lançado com o iOS 26 e outras atualizações de SO no outono de 2025), confirmando que a sua implementação suporta exclusivamente o protocolo org.iso.mdoc para apresentação.

Isto foi detalhado na sessão da WWDC25 Verify identity documents on the web. A API permite que os websites 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 utiliza exclusivamente a string de protocolo "org-iso-mdoc", baseada na norma 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 "pedido parcial", onde o SO primeiro analisa e valida o pedido numa sandbox antes de o passar para a aplicação da wallet, aumentando a segurança.
• Extensível a Aplicações: Além da Apple Wallet, aplicações de terceiros podem atuar como fornecedores de documentos implementando o novo framework IdentityDocumentServices e uma extensão de aplicação.

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

async function verifyIdentity() {
    try {
        // Server generates and cryptographically signs the request data.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // The request specifies the 'org-iso-mdoc' protocol.
        const request = {
            protocol: "org-iso-mdoc",
            // data contains the cryptographically signed mdoc request.
            data,
        };
 
        // The API must be called from within a user gesture.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Send the encrypted response from the wallet to the server for decryption and validation.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Display the verified details...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Handle errors, e.g., user cancellation.
    }
}

Esta confirmação solidifica as estratégias divergentes no mercado de navegadores. Enquanto o Chrome se baseia na camada de transporte flexível do 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 a proposta da API de Credenciais Digitais como está atualmente. As suas preocupações são abrangentes e enraizadas na sua missão de proteger a privacidade do utilizador, a sua agência e garantir uma web aberta e equitativa.

As principais preocupações levantadas pela Mozilla incluem:

• Riscos de Privacidade: Potencial para um aumento da partilha de dados pessoais e uma redução do anonimato online se os pedidos 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 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 uma proliferação de formatos de credenciais que leva a um ecossistema fragmentado em vez de um universalmente interoperável.
• Divulgação Seletiva: Preocupações 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 compreenderem totalmente o que está a ser partilhado.
• Centralização da Confiança e Agência do Utilizador: Receios de que a API possa levar a uma maior centralização da confiança e a uma redução da agência 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 as novas funcionalidades da plataforma web devem demonstrar que tornam a web melhor no geral e priorizam os interesses dos utilizadores. Embora um Conselho do W3C tenha anulado uma objeção formal relacionada com estas 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 trabalhasse ativamente para mitigar estes potenciais danos.

Tabela 1: Suporte de Navegadores para a API de Credenciais Digitais e Protocolos

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, com a sua significativa quota de mercado, provavelmente priorizará interações diretas com org.iso.mdoc através da API de Credenciais Digitais, e o Chrome/Android estão a enfatizar o OpenID4VP (que pode transportar mdocs ou outros formatos de Credenciais Verificáveis), 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 pedidos de credenciais através da API navigator.credentials.get(), especificando potencialmente diferentes parâmetros de protocolo ("org.iso.mdoc" ou "openid4vp") com base na deteção do navegador ou nas capacidades do user agent.
2. Processar respostas que podem vir diretamente num formato mdoc ou como um vp_token via OpenID4VP, que depois precisa de ser analisado para extrair a credencial subjacente (que pode ser ela própria um mdoc ou outro formato de VC).

Embora isto adicione complexidade, tentar forçar todos os utilizadores por um único caminho de protocolo provavelmente excluirá uma porção substancial da base de utilizadores, seja os do iOS ou os do Android/Chrome, dependendo do caminho escolhido. Uma abordagem pragmática, embora mais intensiva em desenvolvimento, é construir flexibilidade para lidar com ambos.

As Relying Parties devem estar extremamente 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 num pedido e como é devolvido numa resposta pode diferir significativamente entre uma consulta direta a um mdoc e uma consulta OpenID4VP (que pode usar Presentation Exchange ou DCQL).

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

As RPs precisam de mapear os seus requisitos de dados específicos para estas estruturas de protocolo variáveis. É crucial compreender 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 wallet 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 wallet para os titulares, o ambiente do sistema operativo desempenha um papel crucial.

Os issuers de wallet enfrentam cenários distintamente diferentes no iOS e no Android no que diz respeito à criação de wallets, 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 detentores de credenciais. Estas aplicações de detentor registadas podem então participar em fluxos de apresentação de credenciais mediados pelo sistema, respondendo a pedidos da API de Credenciais Digitais (via Chrome) ou de verificadores de aplicação nativa. O Android também suporta explicitamente o OpenID4VCI para emissão de credenciais, permitindo que os utilizadores escolham uma wallet 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 projetado para uma participação mais ampla.

• iOS: A Apple mantém um controlo mais apertado sobre o seu ecossistema. Embora as aplicações de wallet de terceiros possam existir 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á frequentemente sujeita aos processos e entitlements específicos da Apple. Adicionar um ID à 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 mDLs estatais, a Apple introduziu o framework IdentityDocumentServices para aplicações nativas iOS. Isto permite que programadores 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 o 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 pedidos.
2. Implementar uma Extensão de Aplicação: Adicionar uma Extensão de Aplicação de UI "Identity Document Provider" ao projeto. Esta extensão é responsável por exibir a UI 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 wallet totalmente integrada no iOS exija a construção de uma aplicação nativa e o uso dos frameworks específicos da Apple — não tecnologias web como PWAs — existe um mecanismo claro, embora rigidamente controlado, para que 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 envia os pedidos para a Apple Wallet ou qualquer outra aplicação de fornecedor 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. À medida que o ecossistema evolui, é crucial que tanto as relying parties como os wallet issuers 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 wallet é uma tarefa significativa. Abordar as preocupações válidas levantadas por organizações como a Mozilla em relação à privacidade, exclusão e agência do utilizador é fundamental para garantir que estas tecnologias sirvam a humanidade. A atual fragmentação no suporte dos navegadores e na ênfase dos protocolos significa que as relying parties e os wallet issuers devem navegar por um cenário complexo por enquanto.