Credenciais Digitais e Passkeys: Semelhanças e Diferenças

• 🔑 Passkeys: Para Logins Seguros. Elas provam quem você é (autenticação) e combatem o phishing de forma eficaz.
• 📄 Credenciais Digitais: Para Provas Verificáveis. Elas provam fatos sobre você (atestado, por exemplo, sua identidade, habilidades), e você controla o que é compartilhado.
• 🤝 Como se Alinham: Ambas usam criptografia forte para maior segurança e uma experiência de usuário mais fluida em comparação com senhas.
• 🎯 Como se Diferenciam: Passkeys são principalmente para acessar serviços. Credenciais Digitais são para fornecer informações verificadas sobre você.

O cenário digital está mudando rapidamente. Essa mudança não está acontecendo apenas porque as senhas tradicionais e os segredos compartilhados continuam a falhar, mas também porque ataques como phishing e deepfakes gerados por IA estão se tornando muito melhores e mais difíceis de detectar. Essas ameaças avançadas podem enganar até mesmo usuários cuidadosos e tornar os métodos antigos de verificação de identidade pouco confiáveis. Isso mostra claramente que a prova criptográfica digital é a única forma verdadeiramente segura de confirmar a identidade de alguém. Neste cenário desafiador, precisamos urgentemente de maneiras mais seguras, fáceis de usar e criptograficamente verificáveis para interagir online. Essa necessidade tornou duas tecnologias-chave importantes: as passkeys, que já são amplamente utilizadas, e as credenciais digitais, que estão apenas começando. Essas tecnologias não dependem de alegações verificadas por humanos — que são cada vez mais fáceis de falsificar — mas, em vez disso, usam provas criptográficas verificáveis por máquina para construir confiança real.

As passkeys tiveram um grande aumento de uso entre 2023 e 2025, graças ao forte apoio de grandes empresas como Apple, Google e Microsoft, além da FIDO Alliance. Baseadas no sólido padrão W3C WebAuthn, as passkeys representam uma mudança fundamental em relação aos segredos fracos e compartilhados. Em vez de senhas, elas usam criptografia de chave pública. Nela, uma chave privada, armazenada com segurança no dispositivo do usuário, assina desafios da relying party (RP). Isso prova que o usuário possui a chave sem revelá-la.

Essa criptografia torna as passkeys muito difíceis de serem alvo de phishing — uma grande vantagem, já que os ataques de phishing se tornam mais sofisticados, às vezes usando deepfakes para parecerem mais reais. Como uma passkey está vinculada ao site ou aplicativo específico para o qual foi criada, os usuários não podem usá-la acidentalmente em sites falsos. Este é um problema comum com métodos de login mais antigos, que são vulneráveis a esses truques avançados. As passkeys também impedem a reutilização de senhas e os perigos do credential stuffing após vazamentos de dados. Além da segurança, as passkeys melhoram muito a experiência de login: é mais rápido, muitas vezes necessitando apenas de uma verificação biométrica (como Face ID ou impressão digital), para que os usuários não precisem lembrar ou digitar senhas longas. Essa combinação de maior segurança e facilidade de uso as tornou populares rapidamente.

Ao mesmo tempo, as credenciais digitais, muitas vezes guardadas em wallets de identidade digital, tornaram-se muito mais comentadas. A Wallet de Identidade Digital da UE (EUDI Wallet) é um bom exemplo dessa tendência.

Diferente das passkeys, que são principalmente para autenticação (provar quem você é mostrando que controla uma chave privada), as credenciais digitais (baseadas em padrões como W3C Verifiable Credentials (VCs) ou ISO mdocs) tratam de atestados criptograficamente verificáveis (provar o que é verdade sobre você com alegações assinadas digitalmente). Ser capaz de verificar fortemente essas alegações é importante, especialmente agora que deepfakes podem criar falsificações convincentes de evidências tradicionais. Sem verificações criptográficas, até mesmo especialistas podem ter dificuldade em distinguir o que é real. Elas permitem que as pessoas carreguem e apresentem digitalmente informações verificadas – como nome, data de nascimento, carteira de motorista, formação educacional ou certificados de trabalho – de uma forma que é criptograficamente segura, respeita a privacidade (permitindo que os usuários compartilhem apenas o necessário) e pode ser verificada por máquinas.

O surgimento de ambas as tecnologias não é uma coincidência. Mostra um movimento mais amplo na indústria, afastando-se de sistemas de identidade centralizados e baseados em senhas para um modelo mais descentralizado e focado no usuário, construído sobre confiança criptográfica. As senhas são um ponto fraco conhecido na segurança online. As formas antigas de compartilhar detalhes de identidade são muitas vezes pouco práticas, inseguras ou compartilham dados em excesso, prejudicando a privacidade do usuário. As passkeys corrigem diretamente a fraqueza da autenticação. As credenciais digitais lidam com o compartilhamento de atributos de forma segura e com o controle do usuário. Ambas usam criptografia semelhante e dependem cada vez mais da integração de plataformas e de hardware seguro, mostrando um esforço conjunto para melhorar muito nossos sistemas de identidade digital.

Enquanto as passkeys cuidam do 'login' e as credenciais digitais de 'provar atributos', elas usam fundamentos criptográficos semelhantes e desempenham papéis complementares no estabelecimento de interações digitais confiáveis. Isso é algo de que realmente precisamos, já que ameaças atuais como phishing sofisticado e deepfakes tornam os métodos mais antigos e não criptográficos de verificação de identidade inseguros. Isso nos leva à questão principal: Como as passkeys e as credenciais digitais se conectam, e como podem funcionar juntas em situações cotidianas do usuário?

Este artigo explora essa sinergia. Vamos examinar suas diferenças e semelhanças, os protocolos que as viabilizam, sua dependência compartilhada de hardware seguro e como podem se interligar em cenários como onboarding de usuários, login com step-up authentication e migração de dispositivos. Também abordaremos como os padrões de navegador emergentes, como a Digital Credentials API, visam unir esses mundos. Este artigo foca especificamente na interação entre essas tecnologias, complementando a exploração técnica mais aprofundada da Digital Credentials API já disponível.

Para entender como as passkeys e as credenciais digitais podem funcionar juntas, é essencial primeiro compreender suas características distintas e as camadas tecnológicas que as sustentam.

A tabela a seguir fornece uma comparação de alto nível:

Essa comparação destaca que, embora ambas utilizem criptografia para gerar confiança, suas funções primárias e padrões de uso típicos diferem significativamente. As passkeys são otimizadas para autenticação frequente e segura, enquanto as credenciais digitais se destacam no fornecimento de atributos verificáveis com o consentimento do usuário.

As passkeys são viabilizadas pela interação de vários padrões-chave:

• WebAuthn (Web Authentication): Este padrão do W3C define a API JavaScript que as aplicações web usam para interagir com autenticadores para registrar (navigator.credentials.create()) e autenticar (navigator.credentials.get()) passkeys. Ele atua como a ponte entre a aplicação web da Relying Party e o navegador ou sistema operacional do usuário. O WebAuthn estende a API de Gerenciamento de Credenciais geral do W3C.

• CTAP (Client to Authenticator Protocol): Definido pela FIDO Alliance, o CTAP especifica como o cliente (navegador ou SO) se comunica com o dispositivo autenticador. Este pode ser um autenticador de plataforma integrado ao dispositivo (usando hardware seguro como um TPM ou Secure Enclave) ou um autenticador móvel como uma chave de segurança USB ou até mesmo um telefone atuando como autenticador para outro dispositivo. O CTAP2 é a versão alinhada com o FIDO2 e as passkeys, suportando vários transportes como USB, NFC e Bluetooth Low Energy (BLE).

• Sinais de Confiança Avançados e Vínculo com o Dispositivo (Considerações para Passkeys Sincronizadas): À medida que as passkeys evoluíram para se tornarem sincronizáveis entre dispositivos ('credenciais multidispositivo'), as Relying Parties (RPs) às vezes precisavam identificar o dispositivo físico específico usado durante a autenticação para avaliação de risco. Ideias iniciais, como as extensões devicePubKey e supplementalPubKeys, tentaram resolver isso, mas foram posteriormente descartadas. O grupo de trabalho de sinais de confiança da FIDO Alliance está agora desenvolvendo substitutos. A ideia principal aqui é que um autenticador com uma passkey sincronizada poderia também criar e usar um segundo par de chaves vinculado ao dispositivo. Durante a autenticação, o autenticador poderia então fornecer assinaturas tanto da chave principal sincronizada quanto desta segunda chave vinculada ao dispositivo. Isso permitiria que as RPs reconhecessem um dispositivo confiável específico. Isso poderia significar menos atrito (por exemplo, pular desafios extras) mesmo que a passkey principal seja sincronizada em muitos dispositivos, tudo sem perder o principal benefício das passkeys sincronizadas: a usabilidade entre dispositivos. Embora ainda não haja um padrão final para isso, tal recurso atenderia a uma necessidade chave para RPs que exigem alta garantia, permitindo-lhes detectar melhor o uso de novos dispositivos ou cumprir regras internas de Strong Customer Authentication (SCA).

Da mesma forma, o ecossistema de credenciais digitais depende de um conjunto de protocolos e APIs emergentes para funcionar:

• Digital Credentials API: Este é um esforço de especificação emergente do W3C que visa estender a API navigator.credentials.get() para permitir que aplicações web solicitem Verifiable Credentials da wallet digital de um usuário de forma padronizada. Ele serve a um propósito semelhante ao WebAuthn, mas foca em VCs em vez de passkeys.
• OpenID for Verifiable Presentations (OpenID4VP): Define um protocolo, construído sobre o OAuth 2.0, para como um Verificador (a RP que solicita credenciais) pode solicitar VCs da Wallet de um Titular. Elementos-chave incluem a presentation_definition (especificando credenciais e alegações necessárias), a Wallet atuando como um servidor de autorização e o vp_token carregando a Verifiable Presentation de volta para o Verificador.
• OpenID for Verifiable Credential Issuance (OpenID4VCI): Complementando o OpenID4VP, este padrão padroniza como um Emissor entrega VCs à Wallet de um Titular, novamente usando mecanismos do OAuth 2.0. Envolve conceitos como Ofertas de Credenciais, fluxos de código de autorização ou pré-autorizados, e endpoints de credenciais dedicados.
• Padrões ISO (ex: ISO/IEC 18013-7, ISO/IEC 23220): Esses padrões internacionais são particularmente significativos para carteiras de motorista móveis (mDLs) e outros tipos de documentos móveis (mdoc). A ISO 18013-5 define a estrutura de dados principal da mDL e a apresentação offline (NFC, BLE), enquanto a ISO 18013-7 e a 23220 especificam mecanismos de apresentação online, incluindo APIs REST e perfis de integração com OpenID4VP (Anexo B da 18013-7). Plataformas como Google Wallet e Apple Wallet utilizam esses padrões ISO.

Apesar de seus diferentes propósitos e protocolos, as passkeys e as credenciais digitais compartilham blocos de construção fundamentais:

• Criptografia Assimétrica: Ambas dependem fortemente de pares de chaves pública-privada. As passkeys usam a chave privada para provar posse durante a autenticação. As credenciais digitais usam a chave privada do emissor para assinar a credencial, garantindo sua autenticidade e integridade, e o titular pode usar sua chave privada para assinar uma apresentação contendo a credencial.
• Hardware Seguro: Proteger as chaves privadas é primordial. Ambas as tecnologias se beneficiam imensamente de componentes de hardware seguro integrados em dispositivos modernos:
  • TPM (Trusted Platform Module): Um chip dedicado frequentemente encontrado em laptops e desktops, que fornece geração segura de chaves, armazenamento e operações criptográficas. É comumente usado por autenticadores de plataforma como o Windows Hello.
  • Secure Enclave: O gerenciador de chaves baseado em hardware da Apple, isolado do processador principal em iPhones, iPads e Macs, usado para proteger dados sensíveis, incluindo as chaves privadas das passkeys.
  • Android Keystore System / StrongBox Keymaster: O Android fornece um Keystore com suporte de hardware, muitas vezes implementado usando um processador seguro dedicado (StrongBox Keymaster), oferecendo forte proteção para chaves criptográficas em dispositivos Android. Embora alguns gerenciadores de senhas usem o nome 'Strongbox', o elemento de hardware seguro subjacente fornecido pelo SO é o principal facilitador aqui.

O uso dos mesmos elementos de hardware seguro (TPM, Secure Enclave, Keystore com suporte de hardware do Android) tanto para operações de passkey quanto, potencialmente, para proteger as chaves privadas dentro de wallets digitais cria uma sinergia significativa. As plataformas não precisam de chips seguros separados para cada função. Em vez disso, podem usar uma única e forte base de hardware e APIs do sistema operacional relacionadas (como as do Keystore do Android ou do Secure Enclave da Apple) para proteger fortemente tanto as credenciais de autenticação (passkeys) quanto as credenciais de atestado (VCs). Isso facilita o desenvolvimento, melhora a consistência da segurança e utiliza bem os investimentos existentes na plataforma.

Além disso, a API de Gerenciamento de Credenciais do navegador (navigator.credentials) é uma camada organizadora chave. Primeiramente estendida pelo WebAuthn para passkeys, agora está sendo estendida pela Digital Credentials API para VCs. Isso aponta para um plano claro: dar às RPs uma maneira principal de solicitar diferentes credenciais e dar aos usuários uma forma familiar de escolhê-las (como através do gerenciador de credenciais do Android ou dos gerenciadores de senhas integrados ao navegador). Isso ocultaria os detalhes técnicos complexos de protocolos como CTAP, OID4VP e ISO, simplificando as coisas para desenvolvedores e usuários.

Do ponto de vista de uma Relying Party (RP), entender como integrar e aproveitar passkeys e credenciais digitais de forma eficaz é crucial para aumentar a segurança, melhorar a experiência do usuário e atender aos requisitos regulatórios. Esta seção analisa como as RPs podem implantar essas tecnologias em diferentes cenários e ecossistemas comuns.

A estratégia de integração ideal para passkeys e credenciais digitais varia significativamente com base no caso de uso específico e seu perfil de risco e requisitos associados. A tabela a seguir fornece uma comparação de alto nível entre cenários comuns:

Comparação de Cenários de Ecossistema

Legenda:

• Papel do VC 🆔: Descreve o papel durante a interação principal, reconhecendo que os VCs são frequentemente usados para o onboarding/KYC inicial em todos os cenários.
• Vínculo com Dispositivo? 🔗: Refere-se à necessidade de vinculação explícita do dispositivo além da vinculação de origem padrão da passkey, particularmente relevante para passkeys sincronizadas.
• Mandato da EUDI Wallet da UE*: Este cenário reflete os requisitos sob a futura regulamentação eIDAS 2, que deve ser aplicada ~36 meses após a entrada em vigor dos atos de implementação finais (provavelmente no final da década de 2020).

Essa comparação fornece uma visão geral rápida; as seções a seguir aprofundam as especificidades de cada cenário da perspectiva de integração da RP.

• Objetivo: Acesso rápido e de baixo atrito com boa segurança de base.
• Fluxo Provável:
  • Autenticação Primária: As passkeys dominarão. Sua resistência a phishing e UX fluida (muitas vezes apenas uma biometria/PIN) as tornam ideais para substituir senhas em cenários de login frequente.
  • Papel das Credenciais Digitais: Mínimo para o login principal. Os VCs podem ser usados opcionalmente após o login para ações específicas como verificação de idade (por exemplo, compra de produtos restritos), personalização com base em atributos verificados (por exemplo, status de fidelidade) ou preenchimento acelerado do perfil durante o cadastro inicial.
• Interação: A passkey cuida do login principal; os VCs são reservados para interações opcionais baseadas em atributos.

• Objetivo: Login de alta garantia e, quando necessário, asserção de identidade verificada.
• Fluxo Provável:
  • Passkeys como 2FA/MFA Autossuficiente: As passkeys inerentemente cumprem os requisitos de autenticação de dois fatores quando a verificação do usuário (PIN/biometria) ocorre durante a cerimônia de login. Elas combinam:
    • Posse: Prova de controle sobre a chave privada.
    • Conhecimento/Inerência: Verificação do usuário via PIN ou biometria. Isso torna o login com passkey em si um método de MFA forte e resistente a phishing, suficiente para muitos cenários de alta garantia sem a necessidade de um segundo passo separado apenas para alcançar o 2FA.
  • Step-Up para Verificação de Identidade (Única): A principal necessidade de um passo extra com Credenciais Digitais surge quando o serviço precisa verificar explicitamente a identidade além de apenas autenticar um usuário que retorna. Esse tipo de verificação forte e criptográfica é vital quando deepfakes podem forjar de forma convincente IDs visuais ou baseados em documentos. Apenas a prova criptográfica digital de uma fonte confiável pode então confirmar um atributo de forma confiável. Isso pode ser necessário:
    • Durante o onboarding inicial.
    • Para ações específicas de alto risco que exigem atributos de identidade confirmados. Nesses casos, a RP solicita uma apresentação de Verifiable Credential específica (por exemplo, um PID, credencial de identidade nacional) da wallet do usuário após o login com passkey.
  • Identidade para Recuperação: Uma vez que a identidade de um usuário tenha sido fortemente verificada (por exemplo, via um step-up de apresentação de VC), essa informação de identidade verificada poderia ser potencialmente aproveitada em fluxos seguros de recuperação de conta. Por exemplo, se um usuário perder todos os seus autenticadores de passkey, apresentar uma credencial de identidade de alta garantia poderia fazer parte de um processo para recuperar o acesso e registrar novas passkeys.
• Interação: As passkeys fornecem 2FA/MFA robusto e autossuficiente para autenticação. Os VCs são usados estrategicamente para verificação explícita de identidade quando necessário, e essa identidade verificada também pode apoiar mecanismos seguros de recuperação de conta.

• Objetivo: Checkout ou iniciação de pagamento simplificado e seguro, minimizando o atrito do usuário.
• Fluxo Provável:
  • Autenticação para Pagamento: As passkeys são ideais para autenticar o usuário na sua conta do Provedor de Serviços de Pagamento (PSP) (por exemplo, PayPal) ou diretamente no fluxo de checkout do comerciante. Isso substitui senhas e fornece uma confirmação rápida e segura para iniciar o pagamento.
  • Onboarding/KYC: Os VCs continuam cruciais durante a fase de onboarding ou configuração da conta com o PSP ou comerciante, fornecendo informações de identidade verificadas (verificações KYC/AML) necessárias para habilitar as capacidades de pagamento em primeiro lugar.
  • Preocupações com o Atrito na Transação: Introduzir um passo de apresentação de Verifiable Credential separado durante o fluxo principal de autorização de pagamento (exigindo interação com uma wallet de identidade digital) adicionaria um atrito significativo em comparação com um passo de confirmação de passkey fluido. Essa interrupção na experiência do usuário provavelmente prejudicaria as taxas de conversão e, portanto, é inadequada para cenários de pagamento típicos de baixo atrito.
• Interação: A passkey protege a autenticação para o ato de pagamento em si. Os VCs cuidam da necessária, e muitas vezes única, prova de identidade/KYC necessária para estabelecer a conta de pagamento, mas são mantidos fora do passo crítico e sensível ao atrito da confirmação do pagamento. (O tópico complexo de usar credenciais digitais diretamente como instrumentos de pagamento, incluindo como diferentes tipos de wallet e APIs de navegador emergentes podem habilitar ou interagir com tais VCs específicos de pagamento, é explorado em detalhes em nosso próximo artigo complementar: Credenciais Digitais e Pagamento.)

• Objetivo: Acesso bancário seguro com uma redução significativa de fraudes, particularmente as relacionadas a phishing, ao atualizar métodos de autenticação legados.
• Fluxo Provável:
  • Substituindo MFA Legado: Muitas instituições financeiras atualmente dependem de senhas combinadas com segundos fatores vulneráveis a phishing, como OTPs por SMS. As passkeys oferecem uma alternativa vastamente superior, fornecendo autenticação forte que é inerentemente resistente a phishing em um único gesto do usuário.
  • Login Principal com Passkeys: Adotar passkeys para o login principal melhora imediatamente a segurança devido à sua resistência a phishing. A natureza criptográfica das passkeys mitiga os vetores de ataque mais comuns que afetam as credenciais tradicionais.
  • Step-Up Baseado em Risco - Consideração Cuidadosa dos Sinais do Dispositivo: Para operações de maior risco (por exemplo, grandes transferências, alteração de detalhes de contato), as instituições financeiras podem considerar a verificação de step-up. Embora os sinais de vinculação de dispositivo associados às passkeys sejam uma opção, sua necessidade deve ser cuidadosamente avaliada. A resistência a phishing da autenticação primária com passkey já mitiga fortemente muitos riscos.
  • Segurança Baseada em Resultados e Redução de Fraude: A redução significativa no risco de phishing alcançada pelas passkeys é um fator crítico. Uma abordagem de segurança baseada em resultados, focada na força e na resistência a phishing do método de autenticação, pode levar a uma redução substancial de fraudes. O peso de um fator resistente a phishing como uma passkey é consideravelmente maior do que adicionar mais fatores vulneráveis a phishing. Isso deve ser central na estratégia de uma instituição financeira ao migrar de métodos mais antigos.
  • VCs para Onboarding/Prova de Identidade: Como em outros cenários, os VCs permanecem essenciais para um robusto KYC/AML inicial e para atualizar com segurança os atributos de identidade do cliente usando informações verificadas, estabelecendo uma base confiável para o relacionamento bancário.
• Interação: As passkeys servem como um método de autenticação primário poderoso e resistente a phishing, reduzindo drasticamente o risco de fraude de sistemas legados. Sinais de dispositivo para step-up são uma opção tática. A força inerente das passkeys deve informar uma postura de segurança baseada em risco, potencialmente reduzindo a dependência excessiva de fatores adicionais e menos resistentes a phishing. Os VCs fornecem a garantia de identidade fundamental.

• Objetivo: Cumprir as regulamentações do eIDAS 2 (Art 5f) que exigem a aceitação da Wallet de Identidade Digital da UE por Relying Parties específicas (órgãos públicos, grandes entidades privadas em setores regulados, VLOPs), permitindo tanto o login com pseudônimo que preserva a privacidade quanto a verificação de identidade/atributos de alta garantia quando legalmente exigido.
• Fluxo Provável:
  • Login com Pseudônimo (Padrão): O usuário inicia o login. A RP solicita autenticação via EUDI Wallet. A wallet usa sua 'chave de pseudônimo' integrada – uma chave residente WebAuthn vinculada ao hardware, com escopo para a RP e armazenada no elemento seguro certificado do dispositivo (WSCD) – para autenticar o usuário. Isso fornece autenticação forte e compatível com SCA (posse + verificação do usuário) enquanto mantém a identidade civil do usuário pseudônima por padrão.
  • Step-Up para Identidade/Atributos (Legalmente Exigido): Se, e somente se, a RP tiver uma base legal específica sob a lei da União ou nacional (por exemplo, PSD2, AML, registro de telecomunicações) para exigir verificação de identidade ou atributos específicos, ela inicia um segundo passo. A RP solicita uma apresentação (via OpenID4VP) dos Dados de Identificação Pessoal (PID) ou Atestado Qualificado de Atributos (QAA) necessários da wallet. O usuário deve consentir explicitamente em compartilhar esses dados identificados.
  • Autenticação da Wallet e da RP: O fluxo envolve autenticação mútua. A RP se autentica para a wallet (com base em seu registro oficial), e a wallet atesta sua autenticidade e a validade da credencial para a RP, aproveitando o hardware seguro (WSCD) e a infraestrutura de certificação associada.
• Interação: A EUDI Wallet atua como um autenticador unificado. Sua passkey WebAuthn integrada (chave de pseudônimo) cuida do login padrão, oferecendo autenticação forte e que preserva a privacidade. As capacidades de VC da wallet são invocadas seletivamente para divulgação explícita de identidade ou atributos legalmente mandatada, garantindo a minimização de dados por padrão.

Navegar neste cenário em evolução requer planejamento estratégico. Aqui estão as principais considerações para as Relying Parties (RPs)

Para as RPs, a principal ação hoje deve ser habilitar e incentivar o uso de passkeys para autenticação. As passkeys são padronizadas, amplamente suportadas por plataformas e oferecem benefícios imediatos e significativos em segurança (resistência a phishing) e experiência do usuário (logins mais rápidos e fáceis). Isso significa menos dependência de senhas e métodos de MFA inseguros como OTPs por SMS. Também pode reduzir os custos de suporte com redefinições de senha e recuperação de conta. Visar o uso amplo de passkeys estabelece uma base moderna e segura para a autenticação do usuário. Embora a adoção possa ser lenta no início, educar os usuários sobre os benefícios antecipadamente e facilitar o cadastro pode ajudar a iniciá-los.

Embora as próprias passkeys ofereçam um passo significativo em direção à autenticação robusta e possam atender aos requisitos de Strong Customer Authentication (SCA), algumas organizações podem ter estruturas de conformidade internas com interpretações ainda mais rigorosas ou preocupações específicas, particularmente em relação às passkeys sincronizadas. Para as Relying Parties (RPs) que enfrentam tais cenários, onde os departamentos de conformidade buscam garantias adicionais, é útil saber que medidas adicionais podem complementar as implementações de passkeys. Elas podem ajudar a resolver lacunas percebidas no SCA ou satisfazer esses requisitos internos elevados. Uma estratégia comum é aproveitar os sinais de confiança do dispositivo, uma abordagem adotada por serviços como o PayPal.

O PayPal, por exemplo, permite que os usuários marquem um dispositivo como 'lembrado', conforme descrito em sua página de ajuda:

Isso significa que, se um usuário fizer login com sua senha (algo que ele sabe) de um dispositivo lembrado (algo que ele tem), o PayPal pode considerar isso suficiente para o SCA em muitos casos. No entanto, eles também afirmam: 'Pode haver casos em que ainda peçamos outra verificação para garantir que sua conta esteja segura.' Isso pode envolver o envio de um código de acesso único via SMS ou a solicitação de confirmação pelo aplicativo do PayPal.

Essa abordagem permite uma experiência de usuário mais fluida em dispositivos confiáveis, ao mesmo tempo em que fornece mecanismos para step-up authentication quando os riscos são maiores ou as regulamentações exigem. As RPs podem considerar modelos semelhantes, onde uma combinação de autenticação primária (como uma passkey) e confiança no dispositivo (potencialmente gerenciada fora dos mecanismos diretos do WebAuthn, se necessário) pode ajudar a preencher as lacunas de conformidade do SCA. No entanto, para uma abordagem mais integrada e padronizada aos sinais de confiança específicos do dispositivo dentro do próprio framework WebAuthn, a atenção se volta para os desenvolvimentos contínuos nessa área.

Em relação a tais abordagens integradas ao WebAuthn para uma confiança mais forte no dispositivo, as RPs em ambientes de alta segurança devem entender o histórico e a direção futura. Propostas de extensão WebAuthn anteriores, como devicePubKey e supplementalPubKeys, visavam fornecer esses sinais de confiança específicos do dispositivo. Eram tentativas de abordar as considerações de segurança das passkeys sincronizadas, que, embora ofereçam usabilidade crucial para adoção em massa, introduzem perfis de risco diferentes (por exemplo, dependência da recuperação de contas na nuvem) em comparação com chaves vinculadas ao dispositivo. A ideia por trás de tais extensões era permitir que as RPs obtivessem uma camada extra de garantia, verificando uma assinatura de uma chave especificamente vinculada ao dispositivo físico em uso, mesmo quando a própria passkey principal é sincronizada.

Embora essas extensões específicas (devicePubKey e supplementalPubKeys) tenham sido descontinuadas, o desafio de obter sinais de vinculação de dispositivo mais fortes para passkeys sincronizadas persiste. As RPs devem, portanto, monitorar o desenvolvimento e a padronização de soluções sucessoras nesta área. Tais soluções poderiam ajudar as RPs a avaliar melhor o risco (por exemplo, distinguir um login de um dispositivo conhecido e confiável de um recém-sincronizado) sem forçar todos os usuários a usar passkeys vinculadas ao dispositivo, que são menos convenientes. Este contexto apresenta às RPs uma escolha mais complexa do que apenas 'sincronizada vs. vinculada ao dispositivo'. As passkeys sincronizadas (geralmente compatíveis com AAL2) oferecem a maior conveniência e a melhor chance de adoção, vitais para aplicativos de consumo. As passkeys vinculadas ao dispositivo (possivelmente AAL3) fornecem a mais alta garantia, mas podem ser mais difíceis de usar. O objetivo das extensões descontinuadas era encontrar um meio-termo — melhorar a segurança para chaves sincronizadas adicionando de volta um sinal de confiança específico do dispositivo. Isso poderia ajudar a reduzir alguns riscos se a sincronização na nuvem for comprometida, sem perder toda a conveniência da sincronização. As RPs devem, portanto, procurar por soluções sucessoras que visem fazer isso. A melhor estratégia dependerá da tolerância ao risco específica de uma RP, de sua base de usuários e da maturidade de quaisquer novos padrões.

Além dos mecanismos específicos dentro do WebAuthn para confiança no dispositivo, algumas Relying Parties (RPs) — particularmente aquelas em setores como bancário, seguros e serviços de pagamento — estão começando a avaliar as credenciais digitais (Verifiable Credentials, ou VCs) como um componente complementar, ou até mesmo um próximo passo, em suas estratégias de identidade e segurança.

Um fator significativo que impulsiona esse interesse é a robusta vinculação ao dispositivo frequentemente associada às credenciais digitais, especialmente quando gerenciadas em wallets de identidade digital seguras. Essas wallets podem aproveitar a segurança baseada em hardware (como Secure Enclaves ou TPMs) para proteger as credenciais e as chaves privadas usadas para apresentá-las. Emissores e provedores de wallet também podem impor políticas que tornam certas credenciais de alto valor inerentemente vinculadas ao dispositivo, oferecendo um nível de controle que é atraente para cenários de alta garantia.

É crucial reconhecer que, embora essa capacidade aprimorada de vinculação ao dispositivo seja uma característica convincente para essas RPs, o propósito principal das credenciais digitais (atestado de atributos e alegações) é distinto do das passkeys (autenticação do usuário). As passkeys confirmam quem é o usuário, enquanto as credenciais digitais confirmam o que é verdade sobre o usuário. Apesar dessa diferença fundamental de propósito, as fortes características de segurança dos VCs mantidos em wallets os tornam uma área de consideração ativa para RPs que buscam adicionar camadas adicionais de garantia. Isso naturalmente leva a discussão para os provedores dessas wallets de identidade digital e o ecossistema que permite a emissão, armazenamento e apresentação de tais credenciais.

Enquanto as passkeys oferecem autenticação direta, as credenciais digitais (VCs) são gerenciadas e apresentadas às Relying Parties por meio de wallets de identidade digital. Essas wallets, sejam soluções nativas de plataforma (como Apple Wallet, Google Wallet) ou aplicativos de terceiros (como a EUDI Wallet), estão evoluindo para usar padrões de navegador emergentes como a Digital Credentials API para uma verificação de identidade online mais fluida (por exemplo, verificações de idade, compartilhamento de atributos de ID digital).

A mecânica detalhada de diferentes tipos de wallet, estratégias específicas de plataforma para integração de VCs (incluindo o foco da Apple em mDoc para interações de navegador versus o suporte mais amplo do Android ao OpenID4VP via seu Credential Manager), como essas wallets facilitam o atestado de atributos e as considerações totalmente separadas para quaisquer funcionalidades de pagamento são tópicos complexos. Estes são explorados em profundidade em nosso próximo artigo complementar: Credenciais Digitais e Pagamentos.

Este artigo atual mantém seu foco na interação fundamental entre passkeys para autenticação e o papel geral das credenciais digitais para atestar atributos.

As passkeys e as credenciais digitais, embora diferentes em seu propósito principal, representam dois pilares de um futuro de identidade digital moderno, mais seguro e focado no usuário. Entender como elas se relacionam e podem se apoiar mutuamente é fundamental para construir a próxima onda de serviços online.

Com base no estado atual e na trajetória dessas tecnologias, duas ações principais se destacam para as Relying Parties:

• Implemente passkeys em todos os lugares hoje: Os padrões são maduros, o suporte da plataforma é amplo e os benefícios sobre as senhas são claros e substanciais. Torne as passkeys o alvo padrão para a autenticação do usuário para aumentar a segurança e a usabilidade imediatamente.
• Adicione o step-up de wallet onde AML/KYC for importante: Para processos que exigem maior garantia ou atributos verificados específicos – como cumprir regulamentações de Prevenção à Lavagem de Dinheiro (AML) / Conheça Seu Cliente (KYC), realizar verificação de idade confiável ou confirmar qualificações profissionais – integre fluxos de apresentação de Verifiable Credential para obter atributos criptograficamente verificáveis, que são indispensáveis para confiar na identidade e nas alegações em uma era de falsificações digitais sofisticadas e deepfakes. Use a Digital Credentials API sempre que possível, mas implemente fallbacks robustos de QR/deep link para garantir o alcance multiplataforma até que a API se estabilize. Isso fornece alta garantia direcionada sem sobrecarregar cada login.

Olhando para o futuro, podemos esperar mais convergência e melhorias:

• Portabilidade de Credenciais Aprimorada: Os métodos de transferência de dispositivo para dispositivo provavelmente melhorarão. Isso pode ir além da autenticação entre dispositivos do CTAP 2.2 para passkeys para incluir maneiras mais fluidas de mover VCs entre wallets, embora a padronização aqui não esteja tão avançada.
• APIs de Navegador Consolidadas: A Digital Credentials API provavelmente amadurecerá e será suportada de forma mais consistente entre os navegadores. Isso oferecerá às RPs uma maneira mais padrão de solicitar tanto passkeys quanto VCs através do navigator.credentials.
• Experiência do Usuário Unificada: Em última análise, os usuários devem ver menos diferença técnica entre autenticar com uma passkey e apresentar atributos com um VC. Os gerenciadores de credenciais de plataforma e as wallets provavelmente gerenciarão essas interações de forma fluida nos bastidores. Eles usarão ferramentas criptográficas compartilhadas e hardware seguro, permitindo que os usuários simplesmente aprovem solicitações com prompts biométricos ou de PIN familiares, não importa se uma passkey ou um VC for usado. Além disso, conceitos como Autenticação Passiva Contínua (CPA), que verifica constantemente os usuários em segundo plano usando biometria comportamental e outros sinais, poderiam aprimorar ainda mais essa segurança contínua, potencialmente trabalhando ao lado de autenticadores ativos como as passkeys.

Chegar a este futuro integrado exigirá mais trabalho em padrões, em como as plataformas os suportam e em como os aplicativos os utilizam. Ao usar passkeys agora e adicionar criteriosamente credenciais digitais, as organizações podem se preparar para essa mudança para um mundo digital sem senhas e que dá aos usuários mais controle sobre seus dados.