Credenziali Digitali e Passkey: Somiglianze e Differenze

• 🔑 Passkey: per accessi sicuri. Dimostrano chi sei (autenticazione) e combattono efficacemente il 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 e una user experience più fluida rispetto alle password.
• 🎯 Differenze: Le passkey servono principalmente per accedere ai servizi. Le Credenziali Digitali servono per fornire informazioni verificate su di te.

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 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, 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.

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. 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 (RP). Questo dimostra che l'utente possiede la chiave senza rivelarla.

Questa crittografia rende le passkey molto difficili da intercettare con il 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 dopo le violazioni dei dati. Oltre alla sicurezza, le passkey migliorano notevolmente l'esperienza di accesso: è più veloce, spesso richiede solo una scansione biometrica (come Face ID o impronta digitale), quindi gli utenti non devono ricordare o digitare lunghe password. Questo mix di maggiore sicurezza e facilità d'uso le ha rese rapidamente popolari.

Allo stesso tempo, le credenziali digitali, spesso conservate in wallet di identità digitale, sono diventate un argomento molto più discusso. Il Wallet di Identità Digitale dell'UE (EUDI Wallet) è 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 (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. 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.

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 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 già disponibile.

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.

La seguente tabella fornisce un confronto di alto livello:

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 frequente e sicura, mentre le credenziali digitali eccellono nel fornire attributi verificabili con il consenso dell'utente.

Le passkey prendono vita attraverso l'interazione di diversi standard chiave:

• WebAuthn (Web Authentication): Questo standard W3C definisce l'API JavaScript che le applicazioni web utilizzano per interagire con gli authenticator per registrare (navigator.credentials.create()) e autenticare (navigator.credentials.get()) le passkey. Agisce come ponte tra l'applicazione web del Relying Party e il browser o il sistema operativo dell'utente. WebAuthn estende la Credential Management API generale del W3C.

• CTAP (Client to Authenticator Protocol): Definito dalla FIDO Alliance, CTAP specifica come il client (browser o SO) comunica con il dispositivo authenticator. Questo potrebbe essere un authenticator di piattaforma integrato nel dispositivo (utilizzando hardware sicuro come un TPM o un Secure Enclave) o un authenticator roaming come una security key USB o persino un telefono che funge da authenticator per un altro dispositivo. CTAP2 è la versione allineata con FIDO2 e le passkey, supportando vari trasporti come USB, NFC e Bluetooth Low 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 (RP) a volte hanno avuto bisogno di identificare il dispositivo fisico specifico utilizzato durante l'autenticazione 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 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 (SCA).

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 che mira a estendere l'API navigator.credentials.get() per consentire alle applicazioni web di richiedere Credenziali Verificabili 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, 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 al Verifier.
• OpenID for Verifiable Credential Issuance (OpenID4VCI): A complemento di OpenID4VP, questo standardizza come un Issuer consegna i VC al Wallet di un Holder, utilizzando nuovamente i meccanismi di OAuth 2.0. 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 definisce la struttura dati principale della mDL e la presentazione offline (NFC, BLE), mentre ISO 18013-7 e 23220 specificano i meccanismi di presentazione online, incluse le API REST e i profili di integrazione con OpenID4VP (Allegato B di 18013-7). Piattaforme come Google Wallet e Apple Wallet sfruttano questi standard ISO.

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 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.
  • 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 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. 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, Keystore supportato da hardware di 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 di Apple) per proteggere con forza sia le credenziali di autenticazione (passkey) che le credenziali di attestazione (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 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, OID4VP e ISO, semplificando le cose per sviluppatori e utenti.

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.

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

Legenda:

• Ruolo del VC 🆔: Descrive il ruolo durante l'interazione principale, riconoscendo che i VC sono spesso utilizzati per l'onboarding iniziale/KYC 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 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.

• 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.

• Obiettivo: Login ad alta sicurezza e, dove necessario, assertion di identità verificata.
• Flusso Probabile:
  • Passkey come 2FA/MFA Autonoma: Le passkey soddisfano intrinsecamente i requisiti di autenticazione a due fattori quando la user verification (PIN/biometrica) avviene durante la cerimonia di login. Combinano:
    • Possesso: Prova del controllo sulla chiave privata.
    • Conoscenza/Inerenza: User verification tramite PIN o dati biometrici. Questo rende il login con passkey stesso un metodo MFA 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.
  • 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 (ad es. un PID, una credenziale di identità nazionale) dal wallet dell'utente dopo il login con passkey.
  • 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 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/MFA 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 sicuri.

• Obiettivo: Checkout o avvio di pagamento 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 (PSP) (ad es. PayPal) o direttamente nel flusso di checkout del merchant. Questo sostituisce le password e fornisce una conferma rapida e sicura per avviare il pagamento.
  • Onboarding/KYC: I VC rimangono cruciali durante la fase di onboarding o configurazione dell'account con il PSP o il merchant, fornendo informazioni di identità verificate (controlli KYC/AML) necessarie per abilitare le funzionalità di pagamento in primo luogo.
  • Preoccupazioni sull'Attrito della Transazione: Introdurre un passaggio separato di presentazione di una 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 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, è esplorato in dettaglio nel nostro prossimo articolo complementare: Credenziali Digitali e Pagamenti).

• Obiettivo: Accesso bancario 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.
• 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.

• Obiettivo: Rispettare le normative 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 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 (possesso + 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, AML, registrazione telecom) per richiedere la verifica dell'identità o attributi specifici, avvia un secondo passaggio. L'RP richiede una presentazione (tramite OpenID4VP) dei necessari Dati di Identificazione della Persona (PID) o dell'Attestazione 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 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.

Navigare in questo panorama in evoluzione richiede una pianificazione strategica. Ecco alcune considerazioni chiave per i Relying Party (RP).

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 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.

Mentre le passkey stesse offrono un passo significativo verso un'autenticazione robusta e possono soddisfare i requisiti della Strong Customer Authentication (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 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.

PayPal, ad esempio, consente agli utenti di contrassegnare un dispositivo come "memorizzato", come descritto sulla loro pagina di aiuto:

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 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.

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) offrono la massima convenienza e le migliori possibilità di adozione, vitali per le app consumer. Le passkey legate al dispositivo (potenzialmente AAL3) 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.

Oltre ai meccanismi specifici all'interno di WebAuthn per la fiducia nel dispositivo, alcuni Relying Party (RP) — in particolare quelli in settori come bancario, assicurativo 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 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.

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, Google Wallet) o applicazioni di terze parti (come il Wallet EUDI), si stanno evolvendo per utilizzare standard emergenti del browser come la 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 per le interazioni del browser rispetto al più ampio supporto OpenID4VP di Android tramite il suo Credential Manager), come questi wallet facilitano l'attestazione 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.

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.

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.

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 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.

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 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 (CPA), che verifica costantemente gli utenti in background utilizzando la biometria 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.