--- url: 'https://www.corbado.com/pt/blog/credenciais-digitais-passkeys' title: 'Credenciais Digitais e Passkeys: Semelhanças e Diferenças' description: 'Entenda como as passkeys e as credenciais digitais se complementam, criando identidades digitais confiáveis e resistentes a phishing.' lang: 'pt' author: 'Vincent Delitz' date: '2025-07-25T07:02:10.166Z' lastModified: '2026-09-03T09:05:03.232Z' keywords: 'credenciais digitais vs. passkeys, passkeys, credenciais digitais, identidade digital' category: 'Passkeys Strategy' --- # Credenciais Digitais e Passkeys: Semelhanças e Diferenças ## Resumo Rápido: Passkeys vs. Credenciais Digitais - 🔑 **Passkeys: Para Logins Seguros.** Elas provam _quem_ você é (autenticação) e combatem o [phishing](https://www.corbado.com/glossary/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](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve) 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](https://www.corbado.com/pt/blog/digital-credentials-api) são para _fornecer informações verificadas_ sobre você. | | **Passkeys** | **Credenciais Digitais** | | :----------- | :------------------------------------ | :------------------------------------------------------ | | **Ação** | 👤 Fazer login em sites/apps | 📜 Apresentar informações verificadas (ID, habilidades) | | **Phishing** | ✅ Forte (Chaves específicas do site) | ⚠️ Varia (A apresentação é fundamental) | | **Status** | 👍 Amplamente Adotadas e Padronizadas | 💡 Emergentes e em Evolução | ## 1 Introdução 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](https://www.corbado.com/glossary/phishing) e deepfakes gerados por [IA](https://www.corbado.com/pt/blog/o-papel-da-ia-na-deteccao-de-ameacas-ciberneticas) 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](https://www.corbado.com/pt/blog/digital-credentials-api), 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. ### 1.1 Por que as passkeys tiveram um grande aumento de uso em 2023-24 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](https://www.corbado.com/glossary/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](https://www.corbado.com/pt/blog/webauthn-pubkeycredparams-credentialpublickey). Nela, uma chave privada, armazenada com [segurança](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve) no dispositivo do usuário, assina desafios da [relying party](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve) e os perigos do [credential stuffing](https://www.corbado.com/glossary/credential-stuffing) após vazamentos de dados. Além da [segurança](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve), 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](https://www.corbado.com/faq/is-face-id-passkey) 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. ### 1.2 Credenciais Digitais Ao mesmo tempo, as [credenciais digitais](https://www.corbado.com/pt/blog/digital-credentials-api), muitas vezes guardadas em wallets de [identidade digital](https://www.corbado.com/pt/blog/digital-credentials-api), tornaram-se muito mais comentadas. A [Wallet](https://www.corbado.com/blog/digital-wallet-assurance) de [Identidade Digital](https://www.corbado.com/pt/blog/digital-credentials-api) da UE (EUDI [Wallet](https://www.corbado.com/blog/digital-wallet-assurance)) é 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](https://www.corbado.com/blog/eudi-wallet-2026-deadline-rollout-eic-2026) (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](https://www.corbado.com/pt/blog/garantia-carteiras-digitais) 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](https://www.corbado.com/pt/blog/webauthn-relying-party-id-rpid-passkeys). 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](https://www.corbado.com/pt/blog/digital-credentials-api). ### 1.3 Questão central: Como essas duas tecnologias se encontram nos fluxos do mundo real? 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](https://www.corbado.com/glossary/step-up-authentication) e migração de dispositivos. Também abordaremos como os padrões de navegador emergentes, como a [Digital Credentials](https://www.corbado.com/blog/digital-credentials-api) 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](https://www.corbado.com/blog/digital-credentials-api) API já disponível. ## 2 Passkeys e Credenciais Digitais em Uma Imagem 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. ### 2.1 Tabela comparativa — propósito, primitivas criptográficas, UX A tabela a seguir fornece uma comparação de alto nível: | Característica | Passkeys | Credenciais Digitais | | :-------------------------------------------------- | :---------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Propósito Principal** | Autenticação (Provar _quem_ você é, demonstrando controle de uma chave privada) | Atestado/Autorização (Provar _o que_ é verdade sobre você por meio de alegações assinadas; também pode ser usado para autenticação) | | **Tecnologia Principal** | Padrões FIDO2 | W3C Verifiable Credentials, ISO mdocs (ex: 18013-5, 18013-7), OpenID4VC (OID4VP/OID4VCI) | | **Dados Transmitidos** | Prova criptográfica de posse da chave (Assertion) | Alegações/Atributos Assinados (ex: Nome, Data de Nascimento, Endereço, Qualificação, Maior de 18 anos) | | **Interação Típica** | Login / Entrar / Autenticação | Apresentar Prova / Compartilhar Dados (ex: Verificação de idade, checagem KYC, mostrar uma licença, provar uma qualificação) | | **Criptografia Chave** | 🔑 Par de Chaves Assimétricas: A chave privada assina os desafios de autenticação. | 🔑 Pares de Chaves Assimétricas: A chave privada do Emissor assina os VCs; a chave privada do Titular assina as apresentações. | | **Objetivo da Experiência do Usuário** | ✅ Login rápido, frequente e de baixo atrito | ✅ Compartilhamento de dados seguro, seletivo e baseado em consentimento | | **Vínculo com o Dispositivo** | ❌ majoritariamente sincronizadas (em andamento) | ✅ Controlado pelo emissor (chaves sensíveis vinculadas ao dispositivo) | | **Resistência a Phishing** | ✅ Alta (Credenciais vinculadas à origem impedem o uso em sites falsos) | ❌ Variável (O fluxo de apresentação importa; os dados do VC são verificáveis, mas o contexto da apresentação pode ser alvo de phishing se não houver cuidado. O design do protocolo (ex: vinculação à origem em APIs) visa mitigar isso). | | **Âncora de Confiança / Fonte da Verdade** | ✅ Vínculo da identidade à chave pública pela RP durante o registro; Segurança do autenticador. | ✅ Autoridade e assinatura criptográfica do Emissor; Infraestrutura de chave pública do Emissor. | | **Maturidade da Padronização / Interoperabilidade** | ✅ Alta (WebAuthn/CTAP2 bem adotados) | ❌ Mista (Modelo de dados de VC estável; Protocolos de Apresentação/Emissão/API em evolução, existe fragmentação) | | **Capacidade Offline** | ❌ Nenhuma | ✅ Sim (Projetado para apresentação offline, ex: mDL via NFC/BLE) | | **Mecanismo de Revogação** | ✅ A RP exclui o registro da chave pública; O usuário remove do autenticador. | ✅ O Emissor publica o status (ex: listas de status); O Verificador checa o status; O Titular exclui o VC. | | **Atrito no Cadastro** | ✅ Baixo (Frequentemente integrado ao login/cadastro) | ❌ Alto (Configuração de wallet separada) | | **Taxa de Adoção (Maio 2025)** | ✅ 95 %+ | ❌ < 1 % | 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](https://www.corbado.com/pt/blog/webauthn-relying-party-id-rpid-passkeys) frequente e segura, enquanto as credenciais digitais se destacam no fornecimento de atributos verificáveis com o consentimento do usuário. ### 2.2 Camada WebAuthn (CTAP 2 e Sinais de Confiança Avançados) As passkeys são viabilizadas pela interação de vários padrões-chave: - **WebAuthn (Web Authentication):** Este [padrão do W3C](https://www.w3.org/TR/webauthn-3/) 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](https://www.corbado.com/glossary/relying-party) e o navegador ou sistema operacional do usuário. O WebAuthn estende a [API de Gerenciamento de Credenciais](https://www.w3.org/TR/credential-management-1/) geral do W3C. - **[CTAP (Client to Authenticator Protocol)](https://fidoalliance.org/specs/fido-v2.2-ps-20250228/fido-client-to-authenticator-protocol-v2.2-ps-20250228.html):** Definido pela [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance), o [CTAP](https://www.corbado.com/blog/passkeys-explained-clearly) 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](https://www.corbado.com/glossary/secure-enclave)) ou um autenticador móvel como uma [chave de segurança](https://www.corbado.com/pt/blog/melhores-fido2-chaves-de-seguranca-hardware) USB ou até mesmo um telefone atuando como autenticador para outro dispositivo. O [CTAP2](https://www.corbado.com/pt/glossary/ctap) é a versão alinhada com o [FIDO2](https://www.corbado.com/glossary/fido2) e as passkeys, suportando vários transportes como USB, NFC e Bluetooth Low [Energy](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/pt/blog/webauthn-relying-party-id-rpid-passkeys) 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](https://www.corbado.com/glossary/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](https://www.corbado.com/faq/sca-psd2-importance) (SCA). ![camada de webauthentication](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/webauthentication_layer_5d44167576.png) ### 2.3 Camada de Credenciais Digitais (OpenID 4 VP/VCI, ISO 18013-7) 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](https://github.com/WICG/digital-credentials) que [visa](https://www.corbado.com/blog/visa-passkeys) estender a API navigator.credentials.get() para permitir que aplicações web solicitem [Verifiable Credentials](https://www.corbado.com/blog/eudi-wallet-2026-deadline-rollout-eic-2026) da [wallet](https://www.corbado.com/blog/digital-wallet-assurance) 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](https://www.corbado.com/glossary/oauth2), 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](https://www.corbado.com/glossary/verifiable-presentation) de volta para o Verificador. - **OpenID for Verifiable Credential Issuance (OpenID4VCI):** Complementando o [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp), este padrão padroniza como um Emissor entrega VCs à Wallet de um Titular, novamente usando mecanismos do [OAuth 2.0](https://www.corbado.com/glossary/oauth2). 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](https://www.corbado.com/glossary/iso-18013-5) define a estrutura de dados principal da [mDL](https://www.corbado.com/blog/mobile-drivers-license) e a apresentação offline (NFC, BLE), enquanto a [ISO 18013-7](https://www.corbado.com/glossary/iso-18013-7) e a 23220 especificam mecanismos de apresentação online, incluindo APIs REST e perfis de integração com [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp) (Anexo B da 18013-7). Plataformas como [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay) e [Apple Wallet](https://www.corbado.com/pt/blog/credenciais-digitais-pagamentos) utilizam esses padrões ISO. ![Camadas de credenciais digitais](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/digital_credential_layers_new_94dff37b9e.png) ### 2.4 Blocos de construção compartilhados (chaves públicas/privadas, Secure Enclave, StrongBox) 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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/glossary/secure-enclave), Keystore com suporte de hardware do [Android](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/glossary/secure-enclave) da Apple) para proteger fortemente tanto as credenciais de autenticação (passkeys) quanto as credenciais de [atestado](https://www.corbado.com/pt/glossary/attestation) (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](https://www.corbado.com/blog/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](https://www.corbado.com/blog/passkeys-explained-clearly), OID4VP e ISO, simplificando as coisas para desenvolvedores e usuários. ## 3 Visão da Relying Party: Integrando Passkeys e Credenciais Digitais Do ponto de vista de uma [Relying Party](https://www.corbado.com/glossary/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. ### 3.1 Comparação de Cenários de Ecossistema 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** | Cenário | Objetivo | Papel da Passkey | Papel do VC | Atrito Tolerado | Vínculo com Dispositivo? | | :--------------------------------- | :--------------------------------------- | :-------------------------------- | :----------------------------------------------------------------------------- | :------------------------- | :------------------------- | | **E-Commerce / Geral** | Velocidade e Segurança Básica | ✅ Login Principal (2FA) | nenhum | 🟢 Baixo | ❌ Não | | **Alta Garantia / MFA** | Autenticação Forte e Prova de ID | ✅ Login Principal (2FA) | 🆔 KYC / Onboarding / Recuperação | 🟡 Médio | ❌ Não | | **Autenticação de Pagamento** | Confirmação de Pagamento Rápida e Segura | ✅ Login Principal (2FA) | 🆔 KYC / Onboarding / Recuperação | 🟢 Muito Baixo | ❌ Não | | **Bancário (Fora do SCA)** | Alta Segurança / Redução de Fraude | ✅ Login Principal (2FA) | 🆔 KYC / Onboarding / Recuperação | 🟡 Médio | ❓ Opcional | | **Conformidade com SCA da UE** | Conformidade Regulatória | ✅ Fator Central do SCA | 🆔 KYC / Onboarding / Recuperação | 🔴 Mais Alto (Obrigatório) | ✅ Sim | | **Mandato da EUDI Wallet da UE**\* | Conformidade Regulatória e Privacidade | ✅ Chave de Pseudônimo (WebAuthn) | 🆔 PID (Dados de Identificação Pessoal) / Atributos Qualificados (Sob Demanda) | 🟡 Médio | ✅ Sim (Atestado por WSCD) | **Legenda:** - **Papel do VC 🆔:** Descreve o papel durante a _interação principal_, reconhecendo que os VCs são frequentemente usados para o onboarding/[KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) 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](https://www.corbado.com/glossary/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. ### 3.2 Cenários de Fator Único (ex: E-Commerce, Serviços Gerais) - **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](https://www.corbado.com/pt/blog/biometria-confirmacao-pagador)/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. ### 3.3 Autenticação Multifator (MFA) e Cenários de Verificação de Identidade (ex: Governo, Seguros, Fundos) - **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](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication) quando a verificação do usuário (PIN/[biometria](https://www.corbado.com/pt/blog/biometria-confirmacao-pagador)) 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](https://www.corbado.com/pt/blog/biometria-confirmacao-pagador). Isso torna o login com passkey em si um método de [MFA](https://www.corbado.com/pt/blog/vazamento-de-dados-medibank) forte e [resistente a phishing](https://www.corbado.com/pt/blog/como-eliminar-senhas-por-completo), suficiente para muitos cenários de alta garantia sem a necessidade de um segundo passo separado apenas para alcançar o [2FA](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication). - **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](https://www.corbado.com/pt/blog/como-eliminar-senhas-por-completo). 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](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication)/[MFA](https://www.corbado.com/pt/blog/vazamento-de-dados-medibank) 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](https://www.corbado.com/pt/blog/como-eliminar-senhas-por-completo). ### 3.4 Cenários de Pagamento (Baixo Atrito) - **Objetivo:** Checkout ou iniciação de [pagamento](https://www.corbado.com/passkeys-for-payment) 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](https://www.corbado.com/pt/blog/passkeys-provedores-pagamento-sdk-terceiros) (PSP) (por exemplo, [PayPal](https://www.corbado.com/blog/paypal-passkeys)) ou diretamente no fluxo de checkout do comerciante. Isso substitui senhas e fornece uma confirmação rápida e segura para iniciar o [pagamento](https://www.corbado.com/passkeys-for-payment). - **Onboarding/KYC:** Os VCs continuam cruciais durante a fase de _onboarding_ ou configuração da conta com o [PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) ou comerciante, fornecendo informações de identidade verificadas (verificações [KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding)/AML) necessárias para habilitar as capacidades de [pagamento](https://www.corbado.com/passkeys-for-payment) em primeiro lugar. - **Preocupações com o Atrito na Transação:** Introduzir um passo de apresentação de [Verifiable Credential](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) 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.) ### 3.5 Cenários de Instituições Financeiras (Fora do SCA) - **Objetivo:** Acesso [bancário](https://www.corbado.com/passkeys-for-banking) 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](https://www.corbado.com/pt/blog/como-eliminar-senhas-por-completo) 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](https://www.corbado.com/pt/blog/como-eliminar-senhas-por-completo) 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](https://www.corbado.com/passkeys-for-banking). - **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. ### 3.6 Cenário do Mandato da EUDI Wallet da UE (Requisito Futuro) - **Objetivo:** Cumprir as regulamentações do [eIDAS](https://www.corbado.com/glossary/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](https://www.corbado.com/pt/blog/webauthn-resident-key-discoverable-credentials-passkeys) 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](https://www.corbado.com/pt/blog/psd2-passkeys) (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](https://www.corbado.com/blog/psd2-passkeys), AML, registro de [telecomunicações](https://www.corbado.com/passkeys-for-telecom)) para exigir verificação de identidade ou atributos específicos, ela inicia um segundo passo. A RP solicita uma apresentação (via [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp)) dos Dados de Identificação Pessoal (PID) ou [Atestado](https://www.corbado.com/pt/glossary/attestation) 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](https://www.corbado.com/passkeys-for-critical-infrastructure) 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. ## 4 Considerações Estratégicas para RPs Navegar neste cenário em evolução requer planejamento estratégico. Aqui estão as principais considerações para as Relying Parties (RPs) ### 4.1 Continue a adotar passkeys 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](https://www.corbado.com/pt/blog/vazamento-de-dados-medibank) inseguros como OTPs por SMS. Também pode reduzir os custos de suporte com redefinições de senha e [recuperação de conta](https://www.corbado.com/pt/blog/como-eliminar-senhas-por-completo). 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. ### 4.2 Abordando Lacunas de Conformidade com o SCA: O Exemplo do PayPal 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](https://www.corbado.com/faq/sca-psd2-importance) (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](https://www.corbado.com/pt/blog/psd2-passkeys) 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](https://www.corbado.com/blog/paypal-passkeys). O [PayPal](https://www.corbado.com/blog/paypal-passkeys), por exemplo, permite que os usuários marquem um dispositivo como 'lembrado', conforme descrito em sua [página de ajuda](https://www.paypal.com/is/cshelp/article/what-are-the-payment-services-directives-strong-customer-authentication-and-remembered-device-help718): > "Um dispositivo lembrado é um navegador web ou móvel pessoal, ou dispositivo móvel usado > para acessar sua conta do PayPal que lembramos após confirmarmos sua identidade com > sucesso. Isso facilita o login, o pagamento e a realização de outras ações com sua conta > do PayPal, porque o dispositivo funciona como um dos dois fatores necessários para o > [SCA](https://www.corbado.com/pt/blog/psd2-passkeys)." 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](https://www.corbado.com/glossary/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. ### 4.3 Acompanhe os Sucessores das Extensões WebAuthn Descontinuadas para um Vínculo de Dispositivo Mais Forte 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](https://www.corbado.com/blog/nist-passkeys)) oferecem a maior conveniência e a melhor chance de adoção, vitais para aplicativos de consumo. As passkeys vinculadas ao dispositivo (possivelmente [AAL3](https://www.corbado.com/blog/nist-passkeys)) 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. ### 4.4 Credenciais Digitais: Uma Consideração da RP para Vínculo de Dispositivo e Transição de Wallet 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](https://www.corbado.com/passkeys-for-banking), [seguros](https://www.corbado.com/passkeys-for-insurance) 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. ## 5 Apresentando Credenciais Digitais via Wallets para Atestado de Identidade 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](https://www.corbado.com/pt/blog/credenciais-digitais-pagamentos), [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay)) ou aplicativos de terceiros (como a EUDI Wallet), estão evoluindo para usar padrões de navegador emergentes como a [Digital Credentials API](https://www.corbado.com/blog/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](https://www.corbado.com/glossary/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](https://www.corbado.com/pt/glossary/attestation) 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](https://www.corbado.com/pt/blog/credenciais-digitais-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. ## 6 Conclusão 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. ### 6.1 Itens de ação: 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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/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. ### 6.2 Perspectiva de longo prazo — transferência de dispositivo para dispositivo e APIs de navegador consolidadas 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](https://www.corbado.com/blog/passkeys-explained-clearly) 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.