Passkeys & WebAuthn PRF per la crittografia end-to-end (2025)

WebAuthn e le Passkey hanno rivoluzionato l'autenticazione web, offrendo accessi senza password e resistenti al phishing tramite la crittografia a chiave pubblica. Ma le loro capacità vanno oltre i semplici login. Una funzionalità entusiasmante è l'estensione WebAuthn Pseudo-Random Function (PRF). Questa estensione permette alle applicazioni web di derivare chiavi segrete direttamente dalla passkey di un utente o da una chiave di sicurezza hardware durante l'autenticazione. Questo sblocca la possibilità di crittografare dati end-to-end o decrittare un vault sicuro usando solo la propria passkey, senza bisogno di una password separata. In questo articolo vogliamo rispondere alle seguenti domande:

• Casi d'uso della PRF per le Passkey: Quali sono i casi d'uso interessanti per l'estensione WebAuthn PRF?
• Supporto dell'estensione PRF: Qual è l'attuale supporto reale dell'estensione WebAuthn PRF tra i sistemi operativi e i browser oggi?

Questo articolo analizza l'estensione WebAuthn PRF, esplorandone le specifiche tecniche, i casi d'uso, i dettagli di implementazione, le considerazioni sulla sicurezza e il panorama attuale del supporto da parte di browser e sistemi operativi. Ci concentriamo sui cambiamenti nell'ecosistema del 2025 e ampliamo le basi gettate da Matthew Miller e Levi Schuck nel 2023, i cui articoli precedenti forniscono un background tecnico dettagliato, esempi live e test online (inclusa la crittografia).

L'estensione WebAuthn PRF (PRF) è formalmente definita nella specifica WebAuthn Level 3. Il suo scopo principale è consentire a una Relying Party (la tua applicazione web) di richiedere la valutazione di una funzione pseudo-casuale associata a una specifica credenziale WebAuthn (passkey) durante una cerimonia di autenticazione (navigator.credentials.get()).

Una PRF prende una chiave segreta (conservata in modo sicuro all'interno dell'authenticator e legata alla credenziale) e uno o più valori di input (forniti dalla Relying Party) per produrre un output deterministico e crittograficamente dall'aspetto casuale. Questo output, tipicamente una stringa di 32 byte, può essere utilizzato dall'applicazione lato client, in particolare come materiale per una chiave simmetrica per la crittografia WebAuthn o per la derivazione di chiavi.

Molti authenticator, in particolare le chiavi di sicurezza FIDO2, implementano una capacità sottostante definita nel Client-to-Authenticator-Protocol (CTAP2) chiamata estensione hmac-secret. Questa estensione CTAP2 fornisce accesso a una funzione HMAC (Hash-based Message Authentication Code) supportata da hardware, che funge da funzione pseudo-casuale. L'estensione WebAuthn PRF agisce come un modo standardizzato per le applicazioni web di accedere a questa capacità hmac-secret attraverso l'API WebAuthn del browser.

Per prevenire potenziali conflitti o problemi di sicurezza in cui un sito web potrebbe ingannare l'authenticator facendogli generare HMAC destinati a scopi non web (come il login al sistema operativo locale), la specifica WebAuthn impone un passaggio importante: gli input forniti dal sito web (primo e secondo salt) vengono prima sottoposti a hash con una stringa di contesto specifica ("WebAuthn PRF" e un byte nullo) prima di essere passati alla funzione hmac-secret sottostante. Questo partiziona efficacemente lo spazio di input della PRF, garantendo che gli output derivati dal web siano distinti da quelli potenzialmente utilizzati in altri contesti.

La capacità di derivare chiavi legate all'authenticator sblocca diversi casi d'uso interessanti per gli sviluppatori:

1. Crittografia lato client / End-to-End (E2EE): Questo è il principale motore dell'estensione WebAuthn PRF. Le applicazioni basate su browser possono derivare una chiave di crittografia unica per ogni credenziale durante il login. Questa chiave può poi essere utilizzata con l'API WebCrypto per crittografare i dati dell'utente memorizzati localmente o sul server. I dati rimangono crittografati a riposo e possono essere decrittati solo dall'utente dopo essersi autenticato con successo con la specifica passkey, migliorando la privacy e la sicurezza dei dati. I fornitori di servizi possono memorizzare i dati degli utenti senza mai avere accesso al testo in chiaro. Questo è particolarmente utile per le applicazioni nel mondo senza password, perché senza l'estensione PRF, dovrebbero richiedere un segreto aggiuntivo sotto forma di password, il che contraddice l'architettura passwordless.

2. Decrittazione di vault senza password: Servizi come i gestori di password (ad es. Bitwarden, 1Password) o le app per appunti sicuri (ad es. Notesnook, Reflect) possono utilizzare la PRF per sostituire la tradizionale master password. L'utente si autentica con la propria passkey, l'estensione PRF deriva la chiave di decrittazione del vault e il vault viene sbloccato, senza bisogno di alcuna master password. Bitwarden ha annunciato il supporto per questa funzionalità. Inoltre, Dashlane ha recentemente adottato l'estensione WebAuthn PRF per rafforzare la resistenza al phishing e migliorare la sicurezza per l'accesso ai vault crittografati. Gli utenti si autenticano usando le loro passkey, consentendo alla PRF di derivare le chiavi di decrittazione del vault in modo sicuro, eliminando completamente la necessità di una master password.

3. Rotazione sicura delle chiavi: L'estensione WebAuthn PRF consente di fornire due "salt" di input (primo e secondo) durante l'autenticazione. Ciò facilita gli schemi di rotazione delle chiavi crittografiche. Un server potrebbe richiedere la chiave "corrente" usando il primo salt e la chiave "successiva" usando il secondo. Nel tempo, il server può aggiornare quale salt corrisponde alla chiave corrente, consentendo una rotazione fluida senza interrompere l'esperienza dell'utente. Questo è particolarmente importante nel caso in cui requisiti normativi o politiche interne richiedano la rotazione di tutte le chiavi entro una scadenza specifica, aumentando la sicurezza.

4. Wallet di identità e sistemi non-custodial: La PRF può derivare chiavi per proteggere i dati di identità all'interno di wallet digitali o abilitare sistemi non-custodial in cui le chiavi private non vengono mai esposte lato server.

Sebbene la specifica sia definita, il supporto effettivo da parte di browser e piattaforme è il fattore critico per gli sviluppatori. Il supporto si è evoluto e, fino a poco tempo fa, era principalmente limitato ai browser basati su Chromium. Tracciare il supporto può essere difficile, poiché non esiste una voce dedicata su CanIUse.com per l'estensione PRF stessa (la ricerca di "webauthn" mostra il supporto generale dell'API, ma non delle estensioni specifiche). Le informazioni devono spesso essere raccolte dalle note di rilascio dei browser, dai bug tracker e dalle pagine di stato. L'utilizzo con successo dell'estensione WebAuthn PRF richiede uno sforzo coordinato tra tre livelli distinti dello stack tecnologico. Il supporto dell'estensione PRF deve essere presente a ogni livello affinché la funzionalità operi:

1. L'Authenticator: Questo è l'hardware (come una chiave di sicurezza) o il componente di piattaforma (come Windows Hello, Portachiavi iCloud e il modulo hardware corrispondente, ad es. TPM o Secure Enclave) che memorizza in modo sicuro la chiave segreta della credenziale ed esegue il calcolo effettivo della funzione pseudo-casuale (tipicamente utilizzando la capacità CTAP2 hmac-secret). Se l'authenticator non dispone di questa capacità crittografica fondamentale, la PRF non può funzionare.

2. Il Sistema Operativo (OS): L'OS funge da ponte tra il browser e l'authenticator. Fornisce i driver necessari e le API a livello di sistema affinché il browser possa scoprire, comunicare e richiedere operazioni agli authenticator (specialmente gli authenticator di piattaforma e quelli connessi tramite USB/NFC/Bluetooth). L'OS deve essere in grado di riconoscere ed esporre al browser la capacità PRF (hmac-secret) dell' authenticator. Se l'OS non fornisce questo percorso, il browser non può accedere alla funzionalità.

3. Il Browser: Come interfaccia per l'applicazione web, il browser deve implementare l'API JavaScript di WebAuthn, riconoscere specificamente l'estensione prf, tradurre la richiesta web nei comandi appropriati per l'OS/authenticator, gestire il passaggio cruciale di sicurezza dell'hashing degli input con la stringa di contesto e analizzare e restituire correttamente i risultati all'applicazione.

Un fallimento o una mancanza di supporto in uno qualsiasi di questi tre livelli – capacità dell'Authenticator, esposizione da parte dell'OS o implementazione del Browser – impedirà il funzionamento dell'estensione PRF.

Questo diagramma di sequenza mostra una versione semplificata di come questi attori collaborano per facilitare il supporto della PRF.

Un flusso di lavoro PRF funzionante richiede la cooperazione di ogni livello della catena WebAuthn ↔ CTAP. Per chiarezza, separiamo la discussione in (1) comportamento del browser + sistema operativo e (2) comportamento dell'authenticator.

Il percorso verso un ampio supporto della PRF evidenzia una sfida comune con le estensioni degli standard web: l'implementazione è spesso scaglionata, con problemi specifici della piattaforma che necessitano di essere risolti. Cercheremo di mantenere questa tabella aggiornata, ma tenete presente che, poiché l'estensione PRF è una delle aggiunte più recenti che richiede l'adattamento dell'intera catena di compatibilità, sono previsti aggiustamenti continui.

Di seguito, analizziamo il supporto per sistema operativo.

Il supporto per l'estensione WebAuthn PRF su Windows è limitato, poiché l'autenticatore di piattaforma nativo (Windows Hello) attualmente non dispone della necessaria capacità hmac-secret. La funzionalità PRF dipende quindi da chiavi di sicurezza esterne.

Con macOS 15, è arrivato il supporto PRF per gli authenticator di piattaforma. Sia Safari che Chrome supportano la PRF tramite il Portachiavi iCloud. Il supporto di Firefox per l'autenticatore di piattaforma è ancora in attesa. Le chiavi di sicurezza funzionano solo con Chrome.

Lo stato su iOS e iPadOS rispecchia quello di macOS, con la PRF che funziona tramite il Portachiavi iCloud. Tuttavia, ci sono avvertenze significative: un bug nelle prime versioni di iOS 18 può portare alla perdita di dati e il supporto per le chiavi di sicurezza esterne non è ancora implementato.

Android offre attualmente il supporto più robusto e diffuso per l'estensione WebAuthn PRF. Le passkey memorizzate in Google Password Manager includono il supporto PRF per impostazione predefinita e funziona sulla maggior parte dei principali browser, ad eccezione di Firefox.

Nella tabella sopra, abbiamo incluso le combinazioni più importanti per il supporto dei provider di passkey di prima parte. Tuttavia, quando si utilizzano gestori di password come provider di passkey di terze parti, le loro capacità specifiche devono essere considerate separatamente. Ad esempio, 1Password supporta la PRF nella sua versione per Android ma non nella sua versione per iOS. Anche il Profilo Chrome come authenticator non supporta la prf. Per maggiori dettagli sugli authenticator, vedi sotto.

Mentre WebAuthn specifica cosa una Relying Party può chiedere, il Client‑to‑Authenticator Protocol (CTAP) definisce come l'authenticator deve comportarsi. In pratica, gli authenticator rientrano in quattro categorie:

1. Nessun supporto PRF: Authenticator di piattaforma più vecchi (ad es. Windows Hello), chiavi di sicurezza legacy senza l'estensione hmac‑secret e provider di terze parti che non hanno ancora adottato l'estensione prf.

2. PRF solo se il flag PRF è stato impostato alla creazione della credenziale: Alcune chiavi di sicurezza CTAP 2.0/2.1 espongono hmac‑secret, ma rifiuteranno le valutazioni PRF a meno che la Relying Party non lo abbia richiesto al momento della creazione della credenziale per inizializzare i segreti.

3. PRF disponibile all'autenticazione anche se non richiesto alla creazione: Token hardware di nuova generazione, Portachiavi iCloud e Google Password Manager espongono la funzionalità hmac‑secret incondizionatamente; le credenziali create senza il flag funzionano comunque con la PRF durante navigator.credentials.get().

4. Piena conformità a CTAP 2.2 (PRF + primo valore PRF alla creazione): Gli authenticator di piattaforma che sincronizzano le passkey, come Portachiavi iCloud e Google Password Manager, possono, su richiesta, restituire il primo output PRF già durante navigator.credentials.create(), semplificando i flussi di stabilimento della chiave.

Sapere a quale categoria appartiene un authenticator è essenziale quando si progetta la logica di backup, migrazione o stabilimento della chiave. Abbiamo anche incluso test per questi scenari nella nostra demo.

Puoi provare direttamente l'estensione WebAuthn PRF utilizzando la nostra applicazione demo interattiva WebAuthn PRF. In questa demo), potrai:

• Registrare una passkey con PRF e confermare se il tuo authenticator supporta questa potente estensione.
• Autenticarti usando la tua passkey e visualizzare il valore crittografico generato dalla PRF in azione.

Vedere di persona il valore PRF evidenzia le implicazioni pratiche dell'uso delle passkey per operazioni sicure basate su chiavi. Ti permette di verificare direttamente la compatibilità dell'authenticator per l'estensione PRF e di osservare come le chiavi derivate dalla PRF possono alimentare la crittografia end-to-end di WebAuthn e la decrittazione sicura di vault senza password.

Prenditi un momento per provare la demo: comprendere la capacità PRF del tuo ambiente specifico ti aiuta a pianificare meglio esperienze sicure e senza password su misura per i tuoi utenti.

Pronto a testare la potenza della PRF? Clicca sull'immagine qui sopra o segui questo link per iniziare la tua esplorazione pratica.

L'estensione WebAuthn PRF non è l'unica estensione WebAuthn legata alla memorizzazione o derivazione di dati. Come si confronta la PRF per le passkey?

• PRF vs. credBlob / largeBlob:

  • credBlob: Permette di memorizzare un piccolo blob statico (32 byte) con la credenziale, possibilmente al momento della creazione. Non è stato progettato principalmente per i segreti e il supporto è limitato, specialmente per le credenziali non individuabili.

  • largeBlob: Consente di memorizzare più dati (circa 1KB) con credenziali individuabili, spesso destinato a dati ausiliari come i certificati. Anche il supporto è limitato (supportato da Portachiavi iCloud da iOS 17, ma non da GPM). Gli sviluppatori di Chrome hanno esplicitamente preferito concentrarsi sulla PRF piuttosto che su largeBlob per la maggior parte dei casi d'uso, sebbene lo sviluppo potrebbe avvenire in futuro.

  • PRF: Al contrario, la PRF è specificamente progettata per derivare chiavi segrete su richiesta durante l'autenticazione utilizzando un segreto legato all'hardware, piuttosto che memorizzare un blob statico. È generalmente considerato il meccanismo standard più appropriato e sicuro per derivare chiavi di crittografia legate a una passkey. L'evoluzione dalla discussione sui blob per i segreti alla standardizzazione e all'attenzione implementativa sulla PRF suggerisce una convergenza sulla PRF come soluzione dedicata per questo caso d'uso.

• PRF vs. Chiavi Derivate da Password (ad es. PBKDF2): Tradizionalmente, le chiavi di crittografia lato client venivano derivate dalle password degli utenti. La PRF offre vantaggi significativi:

  • Fonte più robusta: Le chiavi sono derivate da materiale crittografico forte all'interno dell'authenticator, non da password potenzialmente deboli o riutilizzate.

  • Resistenza al Phishing: La derivazione è legata al flusso di autenticazione WebAuthn, resistente al phishing.

  • Senza Password: Abilita casi d'uso come la decrittazione di vault senza richiedere affatto una password.

• PRF vs. Altri Dati WebAuthn: Tentare di derivare chiavi da altre parti della risposta WebAuthn (come la firma, authenticatorData o la chiave pubblica) è fondamentalmente insicuro e scorretto. Questi componenti sono pubblici, non segreti o progettati per la verifica, non per la derivazione di chiavi.

Per derivare in modo sicuro materiale per chiavi crittografiche legato direttamente a una credenziale WebAuthn o a una passkey, l'estensione WebAuthn PRF è l'approccio standard, appositamente costruito e raccomandato.

Quando si integra l'estensione PRF nella propria applicazione, è bene considerare queste linee guida pratiche:

Le seguenti raccomandazioni aiutano gli sviluppatori a navigare efficacemente lo stato attuale del supporto dell'estensione PRF e a pianificare gli sviluppi futuri:

• Trattare la PRF in modo opportunistico: Il supporto per l'estensione WebAuthn PRF varia attualmente in modo significativo tra browser, sistemi operativi e authenticator. Pertanto, è bene trattare l'integrazione della PRF come un miglioramento piuttosto che come una dipendenza fondamentale.

• Evitare la dipendenza critica dalla PRF: Evitare di rendere la PRF essenziale per funzionalità mission-critical. Il supporto attuale, in particolare su piattaforme come Safari su macOS e iOS, rimane incoerente e incompleto.

• Prepararsi a scenari di perdita della passkey: Ricordare che i dati crittografati con chiavi derivate dalla PRF sono legati esclusivamente alla specifica passkey. La perdita della passkey renderà i dati crittografati permanentemente inaccessibili. Implementare sempre meccanismi di backup e ripristino robusti.

• Prevedere un supporto più ampio entro il 2026: Il supporto dell'estensione PRF sta maturando rapidamente. Entro il 2026, si prevede una disponibilità costante sui principali browser, sistemi operativi e authenticator, in particolare con i provider di passkey di prima parte.

• Monitorare l'ecosistema Windows: Il supporto dell'autenticatore di piattaforma tramite Windows Hello è attualmente assente. La piena integrazione della PRF negli ambienti Windows dipende fortemente dalla strategia di adozione di Microsoft, quindi è bene tenere questo ecosistema sotto stretta osservazione.

Seguire queste linee guida garantisce che gli sviluppatori possano incorporare agevolmente la PRF mantenendo la compatibilità e la sicurezza durante la sua fase di adozione.

Comprendere come la PRF si allinea con la propria strategia generale per le passkey aiuta a massimizzarne i benefici senza complicazioni inutili:

• Integrazione flessibile: Non è necessario decidere se sfruttare la PRF al momento della creazione della passkey. Le passkey esistenti possono essere integrate senza problemi con i casi d'uso della PRF in un secondo momento, senza oneri aggiuntivi di gestione delle credenziali.

• Retrofitting della PRF: Poiché la PRF opera durante la fase di autenticazione (navigator.credentials.get()), le passkey create in precedenza possono supportare flussi di lavoro basati su PRF in una fase successiva. Ciò consente alla tua applicazione di migliorare la sicurezza in modo incrementale senza interrompere i metodi di autenticazione consolidati. Questo approccio funziona con Portachiavi iCloud e Google Password Manager (GPM) e con le chiavi di sicurezza più recenti. Per le chiavi di sicurezza più vecchie, un hmac-secret potrebbe essere generato solo se richiesto alla creazione della credenziale.

• Considerazioni sulla complessità delle passkey: Le complessità inerenti alla gestione delle passkey, come la sincronizzazione delle credenziali, l'autenticazione cross-device e i processi di ripristino, si applicano ugualmente quando si utilizza la PRF. Assicurarsi che l'implementazione della PRF si allinei in modo coeso con la strategia generale di autenticazione con passkey, mantenendo esperienze utente semplificate e controlli di sicurezza robusti.

Considerare la PRF come parte di una strategia olistica per le passkey consente una transizione più fluida verso pratiche di autenticazione più sicure e facili da usare.

Per i fornitori di servizi aziendali che gestiscono dati sensibili degli utenti, la capacità di sfruttare la WebAuthn PRF insieme alle passkey apre possibilità per migliorare la sicurezza e l'esperienza utente, in particolare in scenari che richiedono la crittografia lato client di informazioni di identificazione personale (PII) o la messa in sicurezza di applicazioni che richiedono la crittografia End-2-End. Sebbene Corbado Connect sia progettato principalmente per un'integrazione aziendale fluida delle passkey, può facilitare anche l'implementazione di estensioni per le passkey come SPC o PRF.

Ecco come Corbado può assistere le organizzazioni che desiderano integrare la PRF:

• Facilitare la PRF per l'archiviazione crittografata: In contesti aziendali, a volte è necessario archiviare informazioni sensibili in modo sicuro, talvolta anche direttamente lato client per minimizzare l'esposizione di PII lato server. Corbado Connect può essere configurato per richiedere valori PRF durante il flusso di autenticazione con passkey (navigator.credentials.get()), consentendo alle applicazioni di derivare le chiavi crittografiche necessarie.
• Pattern di archiviazione flessibili: I dati crittografati utilizzando chiavi derivate dalla PRF possono essere archiviati in vari modi a seconda dei requisiti di sicurezza e dell'architettura:
  • Lato client: Archiviati direttamente nel browser utilizzando meccanismi come localStorage o cookie sicuri. I dati in chiaro esistono solo transitoriamente sul client durante la decrittazione.
  • Backend di Corbado (E2EE): Sebbene Corbado eviti generalmente di archiviare PII dei clienti, il meccanismo PRF consente tecnicamente di archiviare dati crittografati lato client sui server di Corbado. Corbado non possederebbe le chiavi per decrittare questi dati; la decrittazione avverrebbe comunque lato client dopo un'autenticazione utente riuscita.
  • Backend del cliente: I dati crittografati potrebbero anche essere inviati e archiviati sui sistemi backend dell'azienda, beneficiando comunque della crittografia lato client.
• Flusso di derivazione sicura della chiave: I componenti di Corbado Connect gestiscono l'interazione con l'API WebAuthn. Quando viene richiesta la PRF:
  1. Un output PRF specifico per l'utente viene generato dall'authenticator, legato alla singola passkey.
  2. Questo output viene restituito in modo sicuro all'applicazione lato client.
  3. L'applicazione dovrebbe quindi utilizzare una Key Derivation Function (KDF) tramite l'API WebCrypto (ad es. HKDF) per derivare una robusta chiave di crittografia simmetrica dall'output PRF.
  4. Questa chiave simmetrica viene utilizzata con WebCrypto (ad es. AES-GCM) per crittografare o decrittare le informazioni target (come le PII).
• Decrittazione fluida ai login successivi: Quando l'utente si autentica di nuovo utilizzando la stessa passkey, Corbado Connect avvia la stessa richiesta PRF. Questo produce l'identico output PRF, consentendo all'applicazione di ri-derivare la stessa chiave simmetrica e decrittare le informazioni precedentemente archiviate lato client.
• Intelligence sull'adozione della PRF: Implementare la PRF richiede di sapere se l'ambiente dell'utente (OS, browser, authenticator) la supporta. Corbado Connect raccoglie segnali sul dispositivo e sulle capacità dell'utente durante l'autenticazione. Questa intelligence può essere utilizzata per:
  • Determinare la prontezza alla PRF nella base di utenti prima di attivare completamente le funzionalità dipendenti dalla PRF.
  • Implementare la PRF in modo opportunistico, fornendola come un miglioramento per gli utenti supportati e mantenendo meccanismi di fallback (come la richiesta di una nuova verifica o l'uso di metodi alternativi) per coloro che non hanno supporto.
• Semplificare la disponibilità delle PII: Utilizzando la PRF per crittografare PII verificate (ad es. attributi di identità ottenuti tramite un flusso di verifica) e archiviandole lato client, le applicazioni possono rendere questi dati immediatamente disponibili dopo un login con passkey per interazioni o transazioni successive, riducendo significativamente l'attrito rispetto a flussi di ri-verifica o basati su app.
• Abilitare sistemi E2EE personalizzati: Sebbene Corbado Connect offra componenti UI per flussi standard, i principi sottostanti possono consentire agli sviluppatori di integrare più a fondo la funzionalità PRF in applicazioni sensibili. Ciò consente di costruire sistemi crittografati end-to-end in cui l'applicazione frontend sfrutta direttamente le chiavi derivate dalla PRF per operazioni crittografiche complesse su dati esistenti o nuovi. Per il momento, questo sarà possibile solo in modo opportunistico e i meccanismi di fallback dovranno implementare un modo diverso per archiviare tali informazioni.

Corbado mira a semplificare le complessità dell'integrazione di passkey e PRF, consentendo alle aziende di sfruttare gli standard in modo sicuro ed efficace, adattandosi a casi d'uso specifici come la crittografia di PII lato client e navigando nel panorama in evoluzione.

L'estensione WebAuthn PRF segna un importante passo avanti nel rendere le applicazioni veramente senza password e con crittografia end-to-end una realtà pratica. Sfruttando le passkey per derivare in modo sicuro le chiavi crittografiche, offre un'esperienza utente fluida e sicura senza compromettere la privacy.

Rispondendo direttamente alle domande poste all'inizio di questo articolo:

• Casi d'uso interessanti della PRF: La PRF abilita casi d'uso convincenti come l'archiviazione di dati con crittografia end-to-end, la decrittazione di vault senza password per i gestori di password, schemi di rotazione sicura delle chiavi crittografiche e wallet di identità sicuri o sistemi non-custodial che proteggono la privacy dell'utente garantendo che le chiavi private non lascino mai i dispositivi client.

• Stato attuale del supporto PRF (giugno 2025): Il supporto rimane frammentato e in evoluzione. Mentre Android ha un supporto robusto su browser e authenticator, piattaforme come macOS e soprattutto iOS sono instabili, in particolare come sorgente CDA con un bug grave. Il supporto di Windows è limitato principalmente a chiavi di sicurezza esterne, con il supporto della piattaforma nativa tramite Windows Hello notevolmente assente.

Gli sviluppatori che considerano l'estensione PRF dovrebbero prevedere un rapido miglioramento, ma procedere con cautela, costruendo applicazioni resilienti che gestiscano con grazia le attuali limitazioni. Man mano che emergerà un'adozione più ampia nelle principali piattaforme ed ecosistemi di authenticator, il futuro per la crittografia senza password abilitata dalla PRF appare luminoso, promettendo una maggiore privacy e usabilità nell'autenticazione web.