--- url: 'https://www.corbado.com/it/blog/credenziali-digitali-passkey-confronto' title: 'Credenziali Digitali e Passkey: Somiglianze e Differenze' description: 'Scopri come le passkey e le credenziali digitali si completano a vicenda, creando identità digitali affidabili e a prova di phishing.' lang: 'it' author: 'Vincent Delitz' date: '2025-07-25T07:00:36.910Z' lastModified: '2026-03-25T10:47:00.539Z' keywords: 'credenziali digitali vs passkey, confronto passkey credenziali digitali' category: 'Passkeys Strategy' --- # Credenziali Digitali e Passkey: Somiglianze e Differenze ## Riepilogo: Passkey vs. Credenziali Digitali - 🔑 **Passkey: per accessi sicuri.** Dimostrano _chi_ sei (autenticazione) e combattono efficacemente il [phishing](https://www.corbado.com/glossary/phishing). - 📄 **Credenziali Digitali: per prove verificabili.** Dimostrano _fatti che ti riguardano_ (attestazione, ad es. la tua identità, le tue competenze) e ti permettono di controllare cosa viene condiviso. - 🤝 **Punti in comune:** Entrambe utilizzano una crittografia robusta per una maggiore [sicurezza](https://www.corbado.com/it/blog/come-abilitare-passkey-su-android) e una user experience più fluida rispetto alle password. - 🎯 **Differenze:** Le passkey servono principalmente per _accedere_ ai servizi. Le [Credenziali Digitali](https://www.corbado.com/it/blog/digital-credentials-api) servono per _fornire informazioni verificate_ su di te. | | **Passkey** | **Credenziali Digitali** | | :----------- | :-------------------------------------- | :--------------------------------------------------- | | **Azione** | 👤 Accesso a siti/app | 📜 Mostrare informazioni verificate (ID, competenze) | | **Phishing** | ✅ Elevata (chiavi specifiche per sito) | ⚠️ Variabile (la presentazione è fondamentale) | | **Stato** | 👍 Ampiamente adottate e standardizzate | 💡 Emergenti e in evoluzione | ## 1. Introduzione Il panorama digitale sta cambiando rapidamente. Questo cambiamento non è dovuto solo al continuo fallimento delle password tradizionali e dei segreti condivisi, ma anche al fatto che attacchi come il [phishing](https://www.corbado.com/glossary/phishing) e i deepfake basati sull'IA stanno diventando molto più efficaci e difficili da individuare. Queste minacce avanzate possono ingannare anche gli utenti più attenti e rendere inaffidabili i vecchi metodi di verifica dell'identità. Ciò dimostra chiaramente che la prova crittografica digitale è l'unico modo veramente sicuro per confermare l'identità di una persona. In questa situazione difficile, abbiamo urgente bisogno di metodi più sicuri, facili da usare e _verificabili crittograficamente_ per interagire online. Questa esigenza ha reso importanti due tecnologie chiave: le passkey, già ampiamente utilizzate, e le [credenziali digitali](https://www.corbado.com/it/blog/digital-credentials-api), che sono solo all'inizio. Queste tecnologie non si basano su affermazioni verificate da esseri umani, che sono sempre più facili da falsificare, ma utilizzano invece prove crittografiche verificabili da macchine per costruire una fiducia reale. ### 1.1 Perché le passkey sono esplose nel 2023-24 Le passkey hanno visto un'enorme crescita nell'adozione tra il 2023 e il 2025, grazie al forte supporto di grandi aziende come Apple, Google e Microsoft, oltre alla [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance). Basate sul solido standard W3C WebAuthn, le passkey rappresentano un cambiamento fondamentale rispetto ai deboli segreti condivisi. Invece delle password, utilizzano la crittografia a chiave pubblica. In questo sistema, una chiave privata, conservata in modo sicuro sul dispositivo dell'utente, firma le challenge provenienti dal [relying party](https://www.corbado.com/glossary/relying-party) (RP). Questo dimostra che l'utente possiede la chiave senza rivelarla. Questa crittografia rende le passkey molto difficili da intercettare con il [phishing](https://www.corbado.com/glossary/phishing), un grande vantaggio, dato che gli attacchi di phishing diventano sempre più sofisticati, a volte utilizzando deepfake per sembrare più reali. Poiché una passkey è legata al sito web o all'app specifica per cui è stata creata, gli utenti non possono utilizzarla accidentalmente su siti falsi. Questo è un problema comune con i metodi di login più vecchi, che sono vulnerabili a tali trucchi avanzati. Le passkey impediscono anche il riutilizzo delle password e i pericoli del [credential stuffing](https://www.corbado.com/glossary/credential-stuffing) dopo le violazioni dei dati. Oltre alla [sicurezza](https://www.corbado.com/it/blog/come-abilitare-passkey-su-android), le passkey migliorano notevolmente l'esperienza di accesso: è più veloce, spesso richiede solo una scansione biometrica (come [Face ID](https://www.corbado.com/faq/is-face-id-passkey) o impronta digitale), quindi gli utenti non devono ricordare o digitare lunghe password. Questo mix di maggiore [sicurezza](https://www.corbado.com/it/blog/come-abilitare-passkey-su-android) e facilità d'uso le ha rese rapidamente popolari. ### 1.2 Credenziali Digitali Allo stesso tempo, le [credenziali digitali](https://www.corbado.com/it/blog/digital-credentials-api), spesso conservate in [wallet](https://www.corbado.com/blog/digital-wallet-assurance) di identità digitale, sono diventate un argomento molto più discusso. Il [Wallet](https://www.corbado.com/blog/digital-wallet-assurance) di Identità Digitale dell'UE (EUDI [Wallet](https://www.corbado.com/blog/digital-wallet-assurance)) è un buon esempio di questa tendenza. A differenza delle passkey, che servono principalmente per l'_autenticazione_ (dimostrare _chi_ sei mostrando di avere il controllo di una chiave privata), le credenziali digitali (basate su standard come W3C [Verifiable Credentials](https://www.corbado.com/glossary/microcredentials) (VCs) o ISO mdocs) riguardano l'_attestazione crittograficamente verificabile_ (dimostrare _cosa_ è vero su di te con affermazioni firmate digitalmente). Essere in grado di verificare con forza queste affermazioni è importante, specialmente ora che i deepfake possono creare falsi convincenti di prove tradizionali. Senza controlli crittografici, anche gli esperti possono avere difficoltà a distinguere ciò che è reale. Permettono alle persone di portare e mostrare digitalmente informazioni verificate – come nome, data di nascita, patente di guida, istruzione o certificati di lavoro – in un modo che è crittograficamente sicuro, rispetta la privacy (consentendo agli utenti di condividere solo ciò che è necessario) e può essere verificato da macchine. L'ascesa di entrambe queste tecnologie non è una coincidenza. Mostra un più ampio spostamento del settore dai sistemi di identità centralizzati e basati su password a un modello più decentralizzato e incentrato sull'utente, basato sulla fiducia crittografica. Le password sono un noto punto debole nella sicurezza online. I vecchi modi di condividere i dettagli dell'identità sono spesso macchinosi, insicuri o condividono troppi dati, danneggiando la privacy dell'utente. Le passkey risolvono direttamente la debolezza dell'[autenticazione](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-passwordless). Le credenziali digitali gestiscono la condivisione di attributi in modo sicuro e con il controllo dell'utente. Entrambe utilizzano una crittografia simile e dipendono sempre più dall'integrazione della piattaforma e dall'hardware sicuro, mostrando uno sforzo congiunto per migliorare notevolmente i nostri sistemi di identità digitale. ### 1.3 Domanda centrale: come si incontrano le due tecnologie nei flussi del mondo reale? Mentre le passkey gestiscono il "login" e le credenziali digitali gestiscono la "prova degli attributi", utilizzano basi crittografiche simili e svolgono ruoli complementari nella creazione di interazioni digitali affidabili. Questo è qualcosa di cui abbiamo davvero bisogno, poiché le minacce attuali come il phishing sofisticato e i deepfake rendono insicuri i vecchi metodi non crittografici di verifica dell'identità. Questo ci porta alla domanda principale: come si collegano le passkey e le credenziali digitali, e come possono lavorare insieme nelle situazioni quotidiane degli utenti? Questo articolo esplora questa sinergia. Esamineremo le loro differenze e somiglianze, i protocolli che le abilitano, la loro dipendenza condivisa dall'hardware sicuro e come possono intrecciarsi in scenari come l'onboarding degli utenti, il login con [step-up authentication](https://www.corbado.com/glossary/step-up-authentication) e la migrazione dei dispositivi. Toccheremo anche come gli standard emergenti dei browser, come la Digital Credentials API, mirino a colmare il divario tra questi due mondi. Questo pezzo si concentra specificamente sull'_interazione_ tra queste tecnologie, completando l'esplorazione tecnica più approfondita della [Digital Credentials API](https://www.corbado.com/blog/digital-credentials-api) già disponibile. ## 2. Passkey e Credenziali Digitali in un'unica immagine Per capire come le passkey e le credenziali digitali possano lavorare insieme, è essenziale prima comprendere le loro caratteristiche distintive e i livelli tecnologici che le supportano. ### 2.1 Tabella di confronto: scopo, primitive crittografiche, UX La seguente tabella fornisce un confronto di alto livello: | Caratteristica | Passkey | Credenziali Digitali | | :------------------------------------------------------ | :--------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Scopo Principale** | Autenticazione (Dimostrare _chi_ sei dimostrando il controllo di una chiave privata) | Attestazione/Autorizzazione (Dimostrare _cosa_ è vero su di te tramite claim firmati; può essere usata anche per l'autenticazione) | | **Tecnologia di Base** | Standard FIDO2 | W3C Verifiable Credentials, ISO mdocs (es. 18013-5, 18013-7), OpenID4VC (OID4VP/OID4VCI) | | **Dati Trasportati** | Prova crittografica del possesso della chiave (Assertion) | Claim/Attributi firmati (es. Nome, Data di Nascita, Indirizzo, Qualifica, Età superiore a 18 anni) | | **Interazione Tipica** | Login / Accesso / Autenticazione | Presentazione di prove / Condivisione di dati (es. verifica dell'età, controllo KYC, mostrare una licenza, provare una qualifica) | | **Crittografia Chiave** | 🔑 Coppia di chiavi asimmetriche: la chiave privata firma le challenge di autenticazione. | 🔑 Coppie di chiavi asimmetriche: la chiave privata dell'Issuer firma i VC; la chiave privata dell'Holder firma le presentazioni. | | **Obiettivo User Experience** | ✅ Login rapido, frequente e a basso attrito | ✅ Condivisione dei dati sicura, selettiva e basata sul consenso | | **Binding al Dispositivo** | ❌ Prevalentemente sincronizzate (in corso) | ✅ Controllato dall'issuer (chiavi sensibili legate al dispositivo) | | **Resistenza al Phishing** | ✅ Elevata (Le credenziali legate all'origine ne impediscono l'uso su siti falsi) | ❌ Variabile (Il flusso di presentazione è importante; i dati VC sono verificabili, ma il contesto di presentazione può essere oggetto di phishing se non si presta attenzione. Il design del protocollo (es. origin binding nelle API) mira a mitigare questo rischio). | | **Trust Anchor / Fonte di Verità** | ✅ Binding dell'identità alla chiave pubblica da parte dell'RP durante la registrazione; sicurezza dell'Authenticator. | ✅ Autorità e firma crittografica dell'Issuer; infrastruttura a chiave pubblica dell'Issuer. | | **Maturità della Standardizzazione / Interoperabilità** | ✅ Elevata (WebAuthn/CTAP2 ben adottati) | ❌ Mista (Modello dati VC stabile; protocolli di presentazione/emissione/API in evoluzione, esiste frammentazione) | | **Capacità Offline** | ❌ Nessuna | ✅ Sì (Progettate per la presentazione offline, es. mDL tramite NFC/BLE) | | **Meccanismo di Revoca** | ✅ L'RP elimina il record della chiave pubblica; l'utente la rimuove dall'authenticator. | ✅ L'Issuer pubblica lo stato (es. status list); il Verifier controlla lo stato; l'Holder elimina il VC. | | **Attrito nell'Enrollment** | ✅ Basso (Spesso integrato nel login/signup) | ❌ Alto (Configurazione separata del wallet) | | **Tasso di Adozione (Maggio 2025)** | ✅ 95 %+ | ❌ < 1 % | Questo confronto evidenzia che, sebbene entrambe sfruttino la crittografia per la fiducia, le loro funzioni primarie e i modelli di utilizzo tipici differiscono in modo significativo. Le passkey sono ottimizzate per un'[autenticazione](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-passwordless) frequente e sicura, mentre le credenziali digitali eccellono nel fornire attributi verificabili con il consenso dell'utente. ### 2.2 Livello WebAuthn (CTAP 2 e Segnali di Fiducia Avanzati) Le passkey prendono vita attraverso l'interazione di diversi standard chiave: - **WebAuthn (Web Authentication):** Questo [standard W3C](https://www.w3.org/TR/webauthn-3/) definisce l'API JavaScript che le applicazioni web utilizzano per interagire con gli [authenticator](https://www.corbado.com/glossary/authenticator) per registrare (navigator.credentials.create()) e autenticare (navigator.credentials.get()) le passkey. Agisce come ponte tra l'applicazione web del [Relying Party](https://www.corbado.com/glossary/relying-party) e il browser o il sistema operativo dell'utente. WebAuthn estende la [Credential Management API](https://www.w3.org/TR/credential-management-1/) generale del 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):** Definito dalla [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance), [CTAP](https://www.corbado.com/it/glossary/ctap) specifica come il client (browser o SO) comunica con il dispositivo [authenticator](https://www.corbado.com/glossary/authenticator). Questo potrebbe essere un [authenticator](https://www.corbado.com/glossary/authenticator) di piattaforma integrato nel dispositivo (utilizzando hardware sicuro come un TPM o un [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)) o un authenticator roaming come una [security key](https://www.corbado.com/glossary/security-key) USB o persino un telefono che funge da authenticator per un altro dispositivo. CTAP2 è la versione allineata con [FIDO2](https://www.corbado.com/glossary/fido2) e le passkey, supportando vari trasporti come USB, NFC e Bluetooth Low [Energy](https://www.corbado.com/passkeys-for-energy) (BLE). - **Segnali di Fiducia Avanzati e Binding al Dispositivo (Considerazioni per le Passkey Sincronizzate):** Man mano che le passkey si sono evolute per diventare sincronizzabili tra dispositivi ("multi-device credentials"), i [Relying Party](https://www.corbado.com/glossary/relying-party) (RP) a volte hanno avuto bisogno di identificare il dispositivo fisico specifico utilizzato durante l'[autenticazione](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-passwordless) per la valutazione del rischio. Le prime idee, come le estensioni `devicePubKey` e `supplementalPubKeys`, hanno cercato di risolvere questo problema ma sono state successivamente abbandonate. Il gruppo di lavoro sui segnali di fiducia della [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance) sta ora sviluppando delle alternative. L'idea principale è che un authenticator con una passkey sincronizzata potrebbe _anche_ creare e utilizzare una seconda coppia di chiavi legata al dispositivo. Durante l'autenticazione, l'authenticator potrebbe quindi fornire firme sia dalla chiave sincronizzata principale che da questa seconda chiave legata al dispositivo. Ciò consentirebbe agli RP di riconoscere un dispositivo fidato specifico. Questo potrebbe significare meno attrito (ad es. saltando challenge extra) anche se la passkey principale è sincronizzata su molti dispositivi, il tutto senza perdere il vantaggio principale delle passkey sincronizzate: l'usabilità su più dispositivi. Sebbene non esista ancora uno standard definitivo per questo, una tale funzionalità soddisferebbe un'esigenza chiave per gli RP che richiedono un'alta garanzia, consentendo loro di individuare meglio l'uso di nuovi dispositivi o di soddisfare le regole interne di [Strong Customer Authentication](https://www.corbado.com/faq/sca-psd2-importance) (SCA). ![webauthentication layer](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/webauthentication_layer_5d44167576.png) ### 2.3 Livello Credenziali Digitali (OpenID 4 VP/VCI, ISO 18013-7) Allo stesso modo, l'ecosistema delle credenziali digitali si basa su un insieme di protocolli e API emergenti per funzionare: - **Digital Credentials API:** Si tratta di uno [sforzo di specifica emergente del W3C](https://github.com/WICG/digital-credentials) che mira a estendere l'API navigator.credentials.get() per consentire alle applicazioni web di richiedere [Credenziali Verificabili](https://www.corbado.com/it/glossary/open-id-4-vp) dal wallet digitale di un utente in modo standardizzato. Svolge uno scopo simile a WebAuthn ma si concentra sui VC invece che sulle passkey. - **OpenID for Verifiable Presentations (OpenID4VP):** Definisce un protocollo, basato su [OAuth 2.0](https://www.corbado.com/glossary/oauth2), su come un Verifier (l'RP che richiede le credenziali) può richiedere VC dal Wallet di un Holder. Gli elementi chiave includono la presentation_definition (che specifica le credenziali e i claim richiesti), il Wallet che agisce come un server di autorizzazione e il vp_token che trasporta la [Verifiable Presentation](https://www.corbado.com/glossary/verifiable-presentation) al Verifier. - **OpenID for Verifiable Credential Issuance (OpenID4VCI):** A complemento di [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp), questo standardizza come un [Issuer](https://www.corbado.com/glossary/issuer) consegna i VC al Wallet di un Holder, utilizzando nuovamente i meccanismi di [OAuth 2.0](https://www.corbado.com/glossary/oauth2). Coinvolge concetti come Credential Offers, flussi pre-autorizzati o con codice di autorizzazione e endpoint di credenziali dedicati. - **Standard ISO (es. ISO/IEC 18013-7, ISO/IEC 23220):** Questi standard internazionali sono particolarmente significativi per le patenti di guida mobili (mDL) e altri tipi di documenti mobili (mdoc). [ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5) definisce la struttura dati principale della [mDL](https://www.corbado.com/blog/mobile-drivers-license) e la presentazione offline (NFC, BLE), mentre [ISO 18013-7](https://www.corbado.com/glossary/iso-18013-7) e 23220 specificano i meccanismi di presentazione online, incluse le API REST e i profili di integrazione con [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp) (Allegato B di 18013-7). Piattaforme come [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay) e [Apple Wallet](https://www.corbado.com/it/blog/credenziali-digitali-pagamenti-apple-vs-google-wallet) sfruttano questi standard ISO. ![Layers digital credentials](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/digital_credential_layers_new_94dff37b9e.png) ### 2.4 Elementi costitutivi condivisi (chiavi pubbliche/private, Secure Enclave, StrongBox) Nonostante i loro diversi scopi e protocolli, le passkey e le credenziali digitali condividono elementi costitutivi fondamentali: - **Crittografia Asimmetrica:** Entrambe si basano pesantemente su coppie di chiavi pubbliche-private. Le passkey utilizzano la chiave privata per dimostrare il possesso durante l'autenticazione. Le credenziali digitali utilizzano la chiave privata dell'[issuer](https://www.corbado.com/glossary/issuer) per firmare la credenziale, garantendone l'autenticità e l'integrità, e il titolare potrebbe utilizzare la propria chiave privata per firmare una presentazione contenente la credenziale. - **Hardware Sicuro:** La protezione delle chiavi private è fondamentale. Entrambe le tecnologie beneficiano immensamente dei componenti hardware sicuri integrati nei dispositivi moderni: - **TPM (Trusted Platform Module):** Un chip dedicato spesso presente in laptop e desktop, che fornisce generazione sicura di chiavi, archiviazione e operazioni crittografiche. È comunemente utilizzato da authenticator di piattaforma come [Windows Hello](https://www.corbado.com/glossary/windows-hello). - **Secure Enclave:** Il gestore di chiavi basato su hardware di Apple, isolato dal processore principale su iPhone, iPad e Mac, utilizzato per proteggere dati sensibili, comprese le chiavi private delle passkey. - **Android Keystore System / StrongBox Keymaster:** [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) fornisce un Keystore supportato da hardware, spesso implementato utilizzando un processore sicuro dedicato (StrongBox Keymaster), che offre una forte protezione per le chiavi crittografiche sui dispositivi [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android). Sebbene alcuni gestori di password utilizzino il nome "Strongbox", l'elemento hardware sicuro sottostante fornito dal sistema operativo è l'abilitatore chiave. L'uso degli _stessi_ elementi hardware sicuri (TPM, [Secure Enclave](https://www.corbado.com/glossary/secure-enclave), Keystore supportato da hardware di [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)) sia per le operazioni con le passkey che potenzialmente per la protezione delle chiavi private all'interno dei wallet digitali crea una sinergia significativa. Le piattaforme non necessitano di chip sicuri separati per ogni funzione. Invece, possono utilizzare un'unica base hardware robusta e le relative API del sistema operativo (come quelle per il Keystore di Android o il [Secure Enclave](https://www.corbado.com/glossary/secure-enclave) di Apple) per proteggere con forza sia le credenziali di autenticazione (passkey) che le credenziali di [attestazione](https://www.corbado.com/it/glossary/attestation) (VC). Ciò semplifica lo sviluppo, migliora la coerenza della sicurezza e sfrutta bene gli investimenti esistenti sulla piattaforma. Inoltre, la Credential Management API del browser (navigator.credentials) è un livello organizzativo chiave. Prima estesa da WebAuthn per le passkey, ora viene ulteriormente estesa dalla [Digital Credentials API](https://www.corbado.com/blog/digital-credentials-api) per i VC. Ciò indica un piano chiaro: fornire agli RP un modo principale per richiedere diverse credenziali e offrire agli utenti un modo familiare per selezionarle (come tramite il gestore di credenziali di Android o i gestori di password integrati nel browser). Questo nasconderebbe i complessi dettagli tecnici di protocolli come [CTAP](https://www.corbado.com/it/glossary/ctap), OID4VP e ISO, semplificando le [cose](https://www.corbado.com/blog/webauthn-pubkeycredparams-credentialpublickey) per sviluppatori e utenti. ## 3. Vista del Relying Party: Integrazione di Passkey e Credenziali Digitali Dal punto di vista di un Relying Party (RP), capire come integrare e sfruttare efficacemente le passkey e le credenziali digitali è cruciale per migliorare la sicurezza, l'esperienza utente e soddisfare i requisiti normativi. Questa sezione analizza come gli RP possono implementare queste tecnologie in diversi scenari ed ecosistemi comuni. ### 3.1 Confronto degli Scenari dell'Ecosistema La strategia di integrazione ottimale per passkey e credenziali digitali varia in modo significativo in base al caso d'uso specifico e al profilo di rischio e ai requisiti associati. La seguente tabella fornisce un confronto di alto livello tra scenari comuni: **Confronto degli Scenari dell'Ecosistema** | Scenario | Obiettivo | Ruolo della Passkey | Ruolo del VC | Attrito Tollerato | Binding al Dispositivo? | | :--------------------------- | :--------------------------------- | :------------------------------ | :-------------------------------------------------------------- | :------------------------- | :---------------------- | | **E-commerce / Generico** | Velocità e Sicurezza di Base | ✅ Login Primario (2FA) | nessuno | 🟢 Basso | ❌ No | | **Alta Sicurezza / MFA** | Autenticazione Forte e Prova ID | ✅ Login Primario (2FA) | 🆔 KYC / Onboard / Recupero | 🟡 Medio | ❌ No | | **Autenticazione Pagamenti** | Conferma Pagamento Veloce e Sicura | ✅ Login Primario (2FA) | 🆔 KYC / Onboard / Recupero | 🟢 Molto Basso | ❌ No | | **Bancario (Non-SCA)** | Alta Sicurezza / Riduzione Frodi | ✅ Login Primario (2FA) | 🆔 KYC / Onboard / Recupero | 🟡 Medio | ❓ Opzionale | | **Conformità SCA UE** | Conformità Normativa | ✅ Fattore SCA Core | 🆔 KYC / Onboard / Recupero | 🔴 Più Alto (Obbligatorio) | ✅ Sì | | **Obbligo Wallet EUDI UE**\* | Conformità Normativa e Privacy | ✅ Chiave Pseudonima (WebAuthn) | 🆔 PID (Dati ID Persona) / Attributi Qualificati (Su Richiesta) | 🟡 Medio | ✅ Sì (Attestato WSCD) | **Legenda:** - **Ruolo del VC 🆔:** Descrive il ruolo durante l'_interazione principale_, riconoscendo che i VC sono spesso utilizzati per l'onboarding iniziale/[KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) in tutti gli scenari. - **Binding al Dispositivo? 🔗:** Si riferisce alla necessità di un binding esplicito al dispositivo oltre al binding di origine standard delle passkey, particolarmente rilevante per le passkey sincronizzate. - **Obbligo Wallet EUDI UE**\*: Questo scenario riflette i requisiti del prossimo regolamento [eIDAS](https://www.corbado.com/glossary/eidas) 2, che dovrebbe applicarsi circa 36 mesi dopo l'entrata in vigore degli atti di esecuzione finali (probabilmente alla fine degli anni 2020\). Questo confronto fornisce una rapida panoramica; le sezioni seguenti approfondiscono le specificità di ogni scenario dal punto di vista dell'integrazione dell'RP. ### 3.2 Scenari a Fattore Singolo (es. E-commerce, Servizi Generali) - **Obiettivo:** Accesso rapido e a basso attrito con una buona sicurezza di base. - **Flusso Probabile:** - **Autenticazione Primaria:** Le passkey domineranno. La loro resistenza al phishing e l'UX fluida (spesso solo un dato biometrico/PIN) le rendono ideali per sostituire le password negli scenari di login frequenti. - **Ruolo delle Credenziali Digitali:** Minimo per il login principale. I VC potrebbero essere utilizzati _opzionalmente_ dopo il login per azioni specifiche come la verifica dell'età (ad es. acquisto di beni soggetti a restrizioni), la personalizzazione basata su attributi verificati (ad es. stato fedeltà) o il completamento rapido del profilo durante la registrazione iniziale. - **Interazione:** La passkey gestisce il login principale; i VC sono riservati a interazioni opzionali basate su attributi. ### 3.3 Scenari di Autenticazione a Più Fattori (MFA) e Verifica dell'Identità (es. Governo, Assicurazioni, Fondi) - **Obiettivo:** Login ad alta sicurezza e, dove necessario, [assertion](https://www.corbado.com/glossary/assertion) di identità verificata. - **Flusso Probabile:** - **Passkey come 2FA/MFA Autonoma:** Le passkey soddisfano intrinsecamente i requisiti di [autenticazione a due fattori](https://www.corbado.com/it/faq/cosa-sono-le-passkey) quando la user verification (PIN/biometrica) avviene durante la cerimonia di login. Combinano: - **Possesso:** Prova del controllo sulla chiave privata. - **Conoscenza/Inerenza:** [User verification](https://www.corbado.com/blog/webauthn-user-verification) tramite PIN o dati biometrici. Questo rende il [login con passkey](https://www.corbado.com/it/blog/migliori-pratiche-adozione-passkey-login) stesso un metodo [MFA](https://www.corbado.com/it/blog/psd2-passkey) forte e resistente al phishing, sufficiente per molti scenari ad alta sicurezza senza la necessità di un secondo passaggio separato solo per ottenere la [2FA](https://www.corbado.com/blog/passkeys-vs-2fa-security). - **Step-Up per la Verifica dell'Identità (Una Tantum):** La principale necessità di un passaggio extra con le Credenziali Digitali si presenta quando il servizio deve _verificare esplicitamente l'identità_ oltre alla semplice autenticazione di un utente di ritorno. Questo tipo di controllo forte e crittografico è vitale quando i deepfake possono falsificare in modo convincente ID visivi o basati su documenti. Solo la prova crittografica digitale da una fonte fidata può quindi confermare in modo affidabile un attributo. Ciò potrebbe essere necessario: - Durante l'onboarding iniziale. - Per specifiche azioni ad alto rischio che richiedono attributi di identità confermati. In questi casi, l'RP richiede una presentazione specifica di una [Verifiable Credential](https://www.corbado.com/glossary/verifiable-credential) (ad es. un PID, una credenziale di identità nazionale) dal wallet dell'utente dopo il [login con passkey](https://www.corbado.com/it/blog/migliori-pratiche-adozione-passkey-login). - **Identità per il Recupero:** Una volta che l'identità di un utente è stata verificata con forza (ad es. tramite uno step-up di presentazione VC), queste informazioni di identità verificate potrebbero potenzialmente essere sfruttate in flussi di [recupero account](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-passwordless) sicuri. Ad esempio, se un utente perde tutti i suoi authenticator passkey, la presentazione di una credenziale di identità ad alta sicurezza potrebbe far parte di un processo per riottenere l'accesso e registrare nuove passkey. - **Interazione:** Le passkey forniscono una robusta [2FA](https://www.corbado.com/blog/passkeys-vs-2fa-security)/[MFA](https://www.corbado.com/it/blog/psd2-passkey) autonoma per l'autenticazione. I VC vengono utilizzati strategicamente per la verifica esplicita dell'identità quando richiesto, e questa identità verificata può anche supportare meccanismi di [recupero account](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-passwordless) sicuri. ### 3.4 Scenari di Pagamento (Basso Attrito) - **Obiettivo:** Checkout o avvio di [pagamento](https://www.corbado.com/passkeys-for-payment) snello e sicuro, minimizzando l'attrito per l'utente. - **Flusso Probabile:** - **Autenticazione per il Pagamento:** Le passkey sono ideali per autenticare l'utente _al_ proprio account del [Payment Service Provider](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) (PSP) (ad es. [PayPal](https://www.corbado.com/blog/paypal-passkeys)) o direttamente nel flusso di checkout del [merchant](https://www.corbado.com/glossary/merchant). Questo sostituisce le password e fornisce una conferma rapida e sicura per avviare il [pagamento](https://www.corbado.com/passkeys-for-payment). - **Onboarding/KYC:** I VC rimangono cruciali durante la fase di _onboarding_ o configurazione dell'account con il [PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) o il [merchant](https://www.corbado.com/glossary/merchant), fornendo informazioni di identità verificate (controlli [KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding)/AML) necessarie per abilitare le funzionalità di [pagamento](https://www.corbado.com/passkeys-for-payment) in primo luogo. - **Preoccupazioni sull'Attrito della Transazione:** Introdurre un passaggio separato di presentazione di una [Verifiable Credential](https://www.corbado.com/glossary/verifiable-credential) _durante_ il flusso di autorizzazione del pagamento principale (che richiede l'interazione con un wallet di identità digitale) aggiungerebbe un attrito significativo rispetto a un passaggio di conferma con passkey fluido. Questa interruzione dell'esperienza utente danneggerebbe probabilmente i tassi di conversione ed è quindi inadatta per i tipici scenari di pagamento a basso attrito. - **Interazione:** La passkey protegge l'autenticazione per l'atto di pagamento stesso. I VC gestiscono la necessaria, spesso una tantum, verifica dell'identità/[KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) richiesta per stabilire l'account di pagamento, ma vengono tenuti fuori dal passaggio critico e sensibile all'attrito della conferma del pagamento. (L'argomento complesso dell'uso delle credenziali digitali direttamente _come strumenti di pagamento_, incluso come i diversi tipi di wallet e le API emergenti dei browser potrebbero abilitare o interagire con tali VC specifici per i [pagamenti](https://www.corbado.com/it/blog/credenziali-digitali-pagamenti-apple-vs-google-wallet), è esplorato in dettaglio nel nostro prossimo articolo complementare: Credenziali Digitali e [Pagamenti](https://www.corbado.com/it/blog/credenziali-digitali-pagamenti-apple-vs-google-wallet)). ### 3.5 Scenari per Istituti Finanziari (Fuori dalla SCA) - **Obiettivo:** Accesso [bancario](https://www.corbado.com/passkeys-for-banking) sicuro con una significativa riduzione delle frodi, in particolare quelle legate al phishing, aggiornando i metodi di autenticazione legacy. - **Flusso Probabile:** - **Sostituzione della MFA Legacy:** Molti istituti finanziari si affidano attualmente a password combinate con secondi fattori vulnerabili al phishing come gli OTP via SMS. Le passkey offrono un'alternativa di gran lunga superiore, fornendo un'autenticazione forte che è intrinsecamente resistente al phishing in un unico gesto dell'utente. - **Login Primario con Passkey:** Adottare le passkey per il login primario migliora immediatamente la sicurezza grazie alla loro resistenza al phishing. La natura crittografica delle passkey mitiga i vettori di attacco più comuni che affliggono le credenziali tradizionali. - **Step-Up Basato sul Rischio - Attenta Considerazione dei Segnali del Dispositivo:** Per operazioni a più alto rischio (ad es. grandi trasferimenti, modifica dei dati di contatto), gli istituti finanziari possono considerare una verifica step-up. Sebbene i segnali di binding al dispositivo associati alle passkey siano un'opzione, la loro necessità dovrebbe essere attentamente valutata. La resistenza al phishing dell'autenticazione primaria con passkey mitiga già pesantemente molti rischi. - **Sicurezza Basata sui Risultati e Riduzione delle Frodi:** La significativa riduzione del rischio di phishing ottenuta con le passkey è un fattore critico. Un approccio alla sicurezza basato sui risultati, che si concentra sulla forza e sulla resistenza al phishing del metodo di autenticazione, può portare a una sostanziale riduzione delle frodi. Il peso di un fattore resistente al phishing come una passkey è considerevolmente più alto dell'aggiunta di più fattori vulnerabili al phishing. Questo deve essere centrale nella strategia di un istituto finanziario durante la migrazione da metodi più vecchi. - **VC per Onboarding/Verifica dell'Identità:** Come in altri scenari, i VC rimangono essenziali per un robusto KYC/AML iniziale e per aggiornare in modo sicuro gli attributi di identità del cliente utilizzando informazioni verificate, stabilendo una base fidata per la relazione [bancaria](https://www.corbado.com/passkeys-for-banking). - **Interazione:** Le passkey fungono da potente metodo di autenticazione primario resistente al phishing, riducendo drasticamente il rischio di frode dai sistemi legacy. I segnali del dispositivo per lo step-up sono un'opzione tattica. La forza intrinseca delle passkey dovrebbe informare una postura di sicurezza basata sul rischio, riducendo potenzialmente l'eccessiva dipendenza da fattori aggiuntivi e meno resistenti al phishing. I VC forniscono la garanzia di identità fondamentale. ### 3.6 Scenario dell'Obbligo del Wallet EUDI dell'UE (Requisito Futuro) - **Obiettivo:** Rispettare le normative [eIDAS](https://www.corbado.com/glossary/eidas) 2 (Art 5f) che richiedono l'accettazione del Wallet di Identità Digitale dell'UE da parte di specifici Relying Party (enti pubblici, grandi entità private in settori regolamentati, VLOP), consentendo sia il login pseudonimo che preserva la privacy, sia la verifica dell'identità/attributi ad alta sicurezza quando legalmente richiesto. - **Flusso Probabile:** - **Login Pseudonimo (Predefinito):** L'utente avvia il login. L'RP richiede l'autenticazione tramite il Wallet EUDI. Il wallet utilizza la sua "chiave pseudonima" integrata – una [resident key](https://www.corbado.com/blog/webauthn-resident-key-discoverable-credentials-passkeys) WebAuthn legata all'hardware, con scope per l'RP, memorizzata nell'elemento sicuro certificato del dispositivo (WSCD) – per autenticare l'utente. Ciò fornisce un'autenticazione forte e conforme alla [SCA](https://www.corbado.com/it/blog/psd2-passkey) (possesso + [user verification](https://www.corbado.com/blog/webauthn-user-verification)) mantenendo l'identità civile dell'utente pseudonima per impostazione predefinita. - **Step-Up per Identità/Attributi (Legalmente Richiesto):** Se e solo se l'RP ha una base giuridica specifica ai sensi del diritto dell'Unione o nazionale (ad es. [PSD2](https://www.corbado.com/blog/psd2-passkeys), AML, registrazione [telecom](https://www.corbado.com/passkeys-for-telecom)) per richiedere la verifica dell'identità o attributi specifici, avvia un secondo passaggio. L'RP richiede una presentazione (tramite [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp)) dei necessari Dati di Identificazione della Persona (PID) o dell'[Attestazione](https://www.corbado.com/it/glossary/attestation) Qualificata di Attributi (QAA) dal wallet. L'utente deve acconsentire esplicitamente a condividere questi dati identificati. - **Autenticazione del Wallet e dell'RP:** Il flusso comporta un'autenticazione reciproca. L'RP si autentica al wallet (in base alla sua registrazione ufficiale), e il wallet attesta la sua autenticità e la validità della credenziale all'RP, sfruttando l'hardware sicuro (WSCD) e l'[infrastruttura](https://www.corbado.com/passkeys-for-critical-infrastructure) di certificazione associata. - **Interazione:** Il Wallet EUDI agisce come un authenticator unificato. La sua passkey WebAuthn integrata (chiave pseudonima) gestisce il login standard, offrendo un'autenticazione forte e che preserva la privacy. Le capacità VC del wallet vengono invocate selettivamente per la divulgazione esplicita di identità o attributi legalmente richiesta, garantendo la minimizzazione dei dati per impostazione predefinita. ## 4. Considerazioni Strategiche per gli RP Navigare in questo panorama in evoluzione richiede una pianificazione strategica. Ecco alcune considerazioni chiave per i Relying Party (RP). ### 4.1 Continuare a raccogliere passkey Per gli RP, l'azione principale oggi dovrebbe essere quella di abilitare e incoraggiare l'uso delle passkey per l'autenticazione. Le passkey sono standardizzate, ampiamente supportate dalle piattaforme e offrono benefici immediati e significativi in termini di sicurezza (resistenza al phishing) e user experience (login più rapidi e semplici). Ciò significa una minore dipendenza dalle password e da metodi [MFA](https://www.corbado.com/it/blog/psd2-passkey) insicuri come gli OTP via SMS. Può anche ridurre i costi di supporto derivanti dal reset delle password e dal recupero dell'account. Puntare a un ampio utilizzo delle passkey crea una base moderna e sicura per l'autenticazione degli utenti. Sebbene l'adozione possa essere lenta all'inizio, educare gli utenti sui benefici in anticipo e rendere la registrazione facile può aiutare a farli iniziare. ### 4.2 Affrontare le Lacune di Conformità SCA: L'Esempio di PayPal Mentre le passkey stesse offrono un passo significativo verso un'autenticazione robusta e possono soddisfare i requisiti della [Strong Customer Authentication](https://www.corbado.com/faq/sca-psd2-importance) (SCA), alcune organizzazioni potrebbero avere quadri di conformità interni con interpretazioni ancora più severe o preoccupazioni specifiche, in particolare per quanto riguarda le passkey sincronizzate. Per i Relying Party (RP) che si trovano in tali scenari, dove i dipartimenti di conformità cercano ulteriori garanzie, è utile sapere che misure aggiuntive possono integrare le implementazioni di passkey. Queste possono aiutare a colmare le lacune percepite della [SCA](https://www.corbado.com/it/blog/psd2-passkey) o a soddisfare quei requisiti interni più elevati. Una strategia comune è sfruttare i segnali di fiducia del dispositivo, un approccio adottato da servizi come [PayPal](https://www.corbado.com/blog/paypal-passkeys). [PayPal](https://www.corbado.com/blog/paypal-passkeys), ad esempio, consente agli utenti di contrassegnare un dispositivo come "memorizzato", come descritto sulla loro [pagina di aiuto](https://www.paypal.com/is/cshelp/article/what-are-the-payment-services-directives-strong-customer-authentication-and-remembered-device-help718): > "Un dispositivo memorizzato è un browser web o mobile personale, o un dispositivo mobile > utilizzato per accedere al tuo account PayPal che ricordiamo dopo aver confermato con > successo la tua identità. Questo rende più facile accedere, pagare e compiere altre > azioni con il tuo account PayPal perché il dispositivo funziona come uno dei due fattori > necessari per la [SCA](https://www.corbado.com/it/blog/psd2-passkey)." Ciò significa che se un utente accede con la propria password (qualcosa che sa) da un dispositivo memorizzato (qualcosa che ha), PayPal può considerare questo sufficiente per la SCA in molti casi. Tuttavia, affermano anche: "Potrebbero esserci casi in cui ti chiederemo comunque un'altra verifica per garantire che il tuo account sia sicuro." Questo potrebbe comportare l'invio di un codice monouso via SMS o la richiesta di conferma tramite l'app PayPal. Questo approccio consente un'esperienza utente più fluida sui dispositivi fidati, pur fornendo meccanismi per lo [step-up authentication](https://www.corbado.com/glossary/step-up-authentication) quando i rischi sono più elevati o le normative lo richiedono. Gli RP possono considerare modelli simili, in cui una combinazione di autenticazione primaria (come una passkey) e fiducia nel dispositivo (potenzialmente gestita al di fuori dei meccanismi diretti di WebAuthn, se necessario) può aiutare a colmare le lacune di conformità SCA. Tuttavia, per un approccio più integrato e standardizzato ai segnali di fiducia specifici del dispositivo all'interno del framework WebAuthn stesso, l'attenzione si sposta sugli sviluppi in corso in quel settore. ### 4.3 Monitorare i Successori delle Estensioni WebAuthn Abbandonate per un Binding al Dispositivo più Forte Riguardo a tali approcci integrati in WebAuthn per una maggiore fiducia nel dispositivo, gli RP in ambienti ad alta sicurezza dovrebbero comprendere la storia e la direzione futura. Le passate proposte di estensione di WebAuthn, come `devicePubKey` e `supplementalPubKeys`, miravano a fornire questi segnali di fiducia specifici del dispositivo. Erano tentativi di affrontare le considerazioni di sicurezza delle passkey sincronizzate, che, pur offrendo un'usabilità cruciale per l'adozione di massa, introducono profili di rischio diversi (ad es. dipendenza dal recupero dell'account cloud) rispetto alle chiavi legate al dispositivo. L'idea alla base di tali estensioni era di consentire agli RP di ottenere un ulteriore livello di garanzia controllando una firma da una chiave specificamente legata al dispositivo fisico in uso, _anche quando la passkey principale stessa è sincronizzata_. Sebbene queste specifiche estensioni (`devicePubKey` e `supplementalPubKeys`) siano state abbandonate, la sfida di ottenere segnali di binding al dispositivo più forti per le passkey sincronizzate persiste. Gli RP dovrebbero quindi monitorare lo sviluppo e la standardizzazione di _soluzioni successive_ in questo ambito. Tali soluzioni potrebbero aiutare gli RP a giudicare meglio il rischio (ad es. distinguere un login da un dispositivo noto e fidato da uno appena sincronizzato) senza costringere tutti gli utenti a utilizzare passkey legate al dispositivo meno convenienti. Questo contesto presenta agli RP una scelta più complessa del semplice "sincronizzate vs. legate al dispositivo". Le passkey sincronizzate (solitamente conformi a [AAL2](https://www.corbado.com/blog/nist-passkeys)) offrono la massima convenienza e le migliori possibilità di adozione, vitali per le app consumer. Le passkey legate al dispositivo (potenzialmente [AAL3](https://www.corbado.com/blog/nist-passkeys)) offrono la massima garanzia ma possono essere più difficili da usare. L'obiettivo delle estensioni abbandonate era trovare una via di mezzo: migliorare la sicurezza per le chiavi sincronizzate aggiungendo un segnale di fiducia specifico del dispositivo. Questo potrebbe aiutare a ridurre alcuni rischi se la sincronizzazione cloud viene compromessa, senza perdere tutta la comodità della sincronizzazione. Gli RP dovrebbero quindi cercare _soluzioni successive_ che mirino a fare questo. La migliore strategia dipenderà dalla specifica tolleranza al rischio di un RP, dalla sua base di utenti e dalla maturità di eventuali nuovi standard. ### 4.4 Credenziali Digitali: Una Considerazione per gli RP per il Binding al Dispositivo e la Transizione al Wallet Oltre ai meccanismi specifici all'interno di WebAuthn per la fiducia nel dispositivo, alcuni Relying Party (RP) — in particolare quelli in settori come [bancario](https://www.corbado.com/passkeys-for-banking), [assicurativo](https://www.corbado.com/passkeys-for-insurance) e dei servizi di pagamento — stanno iniziando a valutare le credenziali digitali (Verifiable Credentials, o VC) come componente complementare, o addirittura successivo, nelle loro strategie di identità e sicurezza. Un fattore significativo che guida questo interesse è il robusto binding al dispositivo spesso associato alle credenziali digitali, specialmente quando gestite all'interno di wallet di identità digitale sicuri. Questi wallet possono sfruttare la sicurezza basata su hardware (come Secure Enclave o TPM) per proteggere le credenziali e le chiavi private utilizzate per presentarle. Gli [Issuer](https://www.corbado.com/glossary/issuer) e i fornitori di wallet possono anche applicare policy che rendono alcune credenziali di alto valore intrinsecamente legate al dispositivo, offrendo un livello di controllo attraente per scenari ad alta sicurezza. È fondamentale riconoscere che, sebbene questa capacità di binding al dispositivo potenziata sia una caratteristica convincente per questi RP, lo _scopo primario_ delle credenziali digitali (attestazione di attributi e claim) è distinto da quello delle passkey (autenticazione dell'utente). Le passkey confermano _chi_ è l'utente, mentre le credenziali digitali confermano _cosa è vero riguardo_ all'utente. Nonostante questa differenza fondamentale di scopo, le forti caratteristiche di sicurezza dei VC conservati nel wallet li rendono un'area di attiva considerazione per gli RP che cercano di aggiungere ulteriori livelli di garanzia. Questo porta naturalmente la discussione verso i fornitori di questi wallet di identità digitale e l'ecosistema che consente l'emissione, l'archiviazione e la presentazione di tali credenziali. ## 5. Presentazione di Credenziali Digitali tramite Wallet per l'Attestazione dell'Identità Mentre le passkey offrono un'autenticazione diretta, le credenziali digitali (VC) sono gestite e presentate ai Relying Party attraverso i wallet di identità digitale. Questi wallet, che siano soluzioni native della piattaforma (come [Apple Wallet](https://www.corbado.com/it/blog/credenziali-digitali-pagamenti-apple-vs-google-wallet), [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay)) o applicazioni di terze parti (come il Wallet EUDI), si stanno evolvendo per utilizzare standard emergenti del browser come la [Digital Credentials API](https://www.corbado.com/blog/digital-credentials-api) per una verifica dell'identità online più fluida (ad es. controlli dell'età, condivisione di attributi di ID digitale). I meccanismi dettagliati dei diversi tipi di wallet, le strategie specifiche delle piattaforme per l'integrazione dei VC (incluso il focus di Apple su [mDoc](https://www.corbado.com/glossary/mdoc) per le interazioni del browser rispetto al più ampio supporto OpenID4VP di Android tramite il suo Credential Manager), come questi wallet facilitano l'[attestazione](https://www.corbado.com/it/glossary/attestation) degli attributi e le considerazioni completamente separate per qualsiasi funzionalità di pagamento sono argomenti complessi. Questi sono esplorati in dettaglio nel nostro prossimo articolo complementare: Credenziali Digitali e [Pagamenti](https://www.corbado.com/it/blog/credenziali-digitali-pagamenti-apple-vs-google-wallet). Questo articolo attuale mantiene il suo focus sull'interazione fondamentale tra le passkey per l'autenticazione e il ruolo generale delle credenziali digitali per l'attestazione degli attributi. ## 6. Conclusione Le passkey e le credenziali digitali, sebbene diverse nel loro scopo principale, rappresentano due pilastri di un futuro dell'identità digitale moderno, più sicuro e incentrato sull'utente. Comprendere come si relazionano e possono supportarsi a vicenda è la chiave per costruire la prossima ondata di servizi online. ### 6.1 Punti d'azione: Sulla base dello stato attuale e della traiettoria di queste tecnologie, due azioni chiave si distinguono per i Relying Party: - **Implementare le passkey ovunque, oggi stesso:** Gli standard sono maturi, il supporto delle piattaforme è diffuso e i benefici rispetto alle password sono chiari e sostanziali. Rendere le passkey l'obiettivo predefinito per l'autenticazione degli utenti per migliorare immediatamente la sicurezza e l'usabilità. - **Aggiungere lo step-up tramite wallet dove AML/KYC sono importanti:** Per i processi che richiedono una maggiore sicurezza o attributi verificati specifici – come il rispetto delle normative Anti-Money Laundering (AML) / Know Your Customer (KYC), l'esecuzione di una verifica dell'età affidabile o la conferma di qualifiche professionali – integrare flussi di presentazione di [Verifiable Credential](https://www.corbado.com/glossary/verifiable-credential) per ottenere attributi crittograficamente verificabili, che sono indispensabili per fidarsi dell'identità e dei claim in un'era di sofisticate falsificazioni digitali e deepfake. Utilizzare la Digital Credentials API dove possibile, ma implementare robusti fallback tramite QR/deep link per garantire la portata multipiattaforma fino a quando l'API non si stabilizzerà. Ciò fornisce un'alta sicurezza mirata senza appesantire ogni login. ### 6.2 Prospettive a lungo termine — trasferimento da dispositivo a dispositivo e API del browser consolidate Guardando al futuro, possiamo aspettarci una maggiore convergenza e miglioramenti: - **Migliore Portabilità delle Credenziali:** I metodi di trasferimento da dispositivo a dispositivo probabilmente miglioreranno. Questo potrebbe andare oltre l'autenticazione cross-device di [CTAP](https://www.corbado.com/it/glossary/ctap) 2.2 per le passkey per includere modi più fluidi per spostare i VC tra i wallet, sebbene la standardizzazione qui non sia così avanzata. - **API del Browser Consolidate:** La Digital Credentials API probabilmente maturerà e sarà supportata in modo più coerente tra i browser. Ciò offrirà agli RP un modo più standard per richiedere sia passkey che VC tramite navigator.credentials. - **User Experience Unificata:** In definitiva, gli utenti dovrebbero vedere meno differenze tecniche tra l'autenticazione con una passkey e la presentazione di attributi con un VC. I gestori di credenziali delle piattaforme e i wallet probabilmente gestiranno queste interazioni in modo fluido dietro le quinte. Utilizzeranno strumenti crittografici condivisi e hardware sicuro, consentendo agli utenti di approvare semplicemente le richieste con familiari prompt biometrici o PIN, indipendentemente dal fatto che venga utilizzata una passkey o un VC. Inoltre, concetti come la [Continuous Passive Authentication](https://www.corbado.com/blog/continuous-passive-authentication) (CPA), che verifica costantemente gli utenti in background utilizzando la [biometria](https://www.corbado.com/it/blog/biometria-consapevolezza-pagatore-dynamic-linking) comportamentale e altri segnali, potrebbero migliorare ulteriormente questa sicurezza senza interruzioni, lavorando potenzialmente a fianco di authenticator attivi come le passkey. Raggiungere questo futuro integrato richiederà più lavoro sugli standard, su come le piattaforme li supportano e su come le app li utilizzano. Utilizzando le passkey ora e aggiungendo con attenzione le credenziali digitali, le organizzazioni possono prepararsi a questo passaggio verso un mondo digitale senza password che offre agli utenti un maggiore controllo sui propri dati.