---
url: 'https://www.corbado.com/it/blog/passkeys-cheat-sheet'
title: 'Passkey Cheat Sheet per Sviluppatori'
description: 'La guida per sviluppatori su WebAuthn e l''implementazione delle passkey. Scarica il cheat sheet in PDF o usa il sito per avere tutto in un unico posto.'
lang: 'it'
author: 'Lukas R.'
date: '2026-07-03T07:12:36.749Z'
lastModified: '2026-07-03T07:12:54.878Z'
keywords: 'cheat sheet, passkey, webauthn, sviluppatori, implementazione, guida, pdf'
category: 'Passkeys Implementation'
---
# Passkey Cheat Sheet per Sviluppatori
## Scarica qui gratuitamente
Scarica l'intero **Passkey Cheat Sheet gratuitamente** e ottieni tutte le informazioni.
- ✅ Oltre 4.000 download
- ✅ Richiesto dai team di sviluppo di Ally, Kmart, Octopus [Energy](https://www.corbado.com/passkeys-for-energy) e Stanford CS
- ✅ Nessuna chiacchiera di marketing, solo approfondimenti tecnici
## Key Facts
- L'autenticazione con le passkey utilizza due **cerimonie**: la registrazione (attestation) e l'accesso (assertion), ognuna delle quali richiede una sfida (challenge) casuale generata dal server e firmata dall'autenticatore.
- **PublicKeyCredentialCreationOptions** regola la registrazione della passkey mentre **PublicKeyCredentialRequestOptions** regola l'accesso. Entrambi gli oggetti sono generati lato server e contengono la sfida che l'autenticatore deve firmare.
- La **Conditional UI** mostra le passkey disponibili come suggerimenti di compilazione automatica (autofill), ma richiede credenziali rilevabili (chiavi residenti) e non è supportata in tutte le combinazioni di sistemi operativi e browser.
- L'**ID del Relying Party (rpID)** lega una passkey a un dominio: l'autenticazione ha successo solo quando l'URL corrisponde o è un sottodominio non presente nella Public Suffix List dell'rpID.
- Le passkey utilizzano **algoritmi COSE** per la generazione delle chiavi, con l'algoritmo specifico registrato nell'attributo parsedCredentialPublicKey dell'oggetto attestation.
## 1. Cerimonie WebAuthn
L'autenticazione con le passkey si basa su due processi, chiamati anche cerimonie, la **registrazione** (nota anche come **fase di attestation**) e l'**accesso** (noto anche come **fase di assertion**).
Ogni fase richiede una sfida casuale generata dal server, che viene firmata dall'autenticatore e inviata al server WebAuthn per verificare l'utente.
### 1.1 Registrazione (Attestation)
_La cerimonia di registrazione utilizza due oggetti centrali: PublicKeyCredentialCreationOptions e attestation._
[Watch on YouTube](https://www.youtube.com/watch?v=0hRYXHESA24)
### 1.2 Accesso (Assertion)
_La cerimonia di accesso utilizza due oggetti centrali: PublicKeyCredentialRequestOptions e assertion._
## 2. Oggetti importanti
Per la registrazione e l'accesso con le passkey, ci sono quattro oggetti principali:
- PublicKeyCredentialCreationOptions
- PublicKeyCredentialRequestOptions
- attestation
- assertion
Questa sezione spiega anche l'oggetto authenticatorSelection, che viene utilizzato in PublicKeyCredentialCreationOptions.
### 2.1 Opzioni di creazione delle credenziali a chiave pubblica (Public Key Credential Creation Options)
PublicKeyCredentialCreationOptions è l'oggetto centrale della fase di attestation (Registrazione). Viene creato e restituito dal [server WebAuthn](#webauthn-server).
```json
{
"PublicKeyCredentialCreationOptions": {
"rp": {
"id": "passkeys.eu",
"name": "Corbado Passkeys Demo"
},
"user": {
"displayName": "john.doe",
"id": "dXNyLZ….DU10Tc",
"name": "john@doe.com"
},
"challenge": "888fix4Bus...pHHr3Y",
"pubKeyCredParams": [
{
"alg": -7,
"type": "public-key"
},
{
"alg": -257,
"type": "public-key"
}
],
"excludeCredentials": [],
"authenticatorSelection": {
"authenticatorAttachment": "platform",
"residentKey": "required",
"userVerification": "required"
},
"attestation": "none",
"extensions": {}
}
}
```
L'oggetto contiene questi attributi:
- **rp:** Identifica il Relying Party (= il server che cerca di autenticare l'utente), vedi sezione [4.2 ID del Relying Party (rpID).](#relying-party-id)
- **user:** Contiene i dati sull'account utente che richiede l'attestation. L'ID è una sequenza di byte scelta dal Relying Party, che non deve contenere informazioni personali. Il nome utente o l'indirizzo e-mail viene invece salvato nell'attributo name o displayName. Scopri di più nella sezione [4.1 Schema del database.](#database-schema)
- **challenge:** Un BufferSource codificato in base64URL generato in modo casuale che deve essere firmato dall'autenticatore.
- **pubKeyCredParams:** Attributi specificati della credenziale da creare, di solito gli algoritmi supportati.
- **timeout:** Tempo opzionale in millisecondi che il client deve attendere per il completamento della chiamata.
- **excludeCredentials:** Elenco opzionale di credenziali per limitare la creazione di più passkey su un singolo dispositivo.
- **authenticatorSelection:** Selezione opzionale dell'autenticatore utilizzato per il metodo, ad esempio se è richiesta una chiave residente (residentKey). Vedi [2.5 authenticatorSelection](#authenticatorSelection).
- **attestation:** Può essere utilizzato per richiedere che l'oggetto attestation venga trasmesso al Relying Party in una forma specifica. I valori possibili sono none (predefinito), indirect, direct e enterprise.
- **extensions:** Richieste opzionali per elaborazioni aggiuntive, come valori di ritorno specifici. Es.:
- _credProbs_ richiede informazioni sul fatto che la credenziale creata sia rilevabile (discoverable)
- _prf_ consente al Relying Party di utilizzare gli output di una funzione pseudo-casuale (PRF) associata a una credenziale
### 2.2 Opzioni di richiesta delle credenziali a chiave pubblica (Public Key Credential Request Options)
PublicKeyCredentialRequestOptions è l'oggetto centrale della fase di assertion (Accesso). Viene creato e restituito dal [server WebAuthn](#webauthn-server).
```json
{
"publicKeyCredentialRequestOptions": {
"challenge": "pT7HMA-…dFPHk",
"timeout": 500,
"rpId": "passkeys.eu",
"userVerification": "preferred",
"allowCredentials": [],
"extensions": []
}
}
```
L'oggetto contiene questi attributi:
- **challenge, timeout, extensions:** vedi [sopra](#creationoptions).
- **rpId:** L'identificatore del Relying Party per la richiesta di assertion, vedi sezione [4.2 ID del Relying Party (rpID).](#relying-party-id)
- **allowCredentials:** Elenco opzionale di credenziali consentite per l'autenticazione, indicando la preferenza del chiamante in ordine decrescente. Questo elenco verrebbe riempito con PublicKeyCredentialDescriptors.
- **userVerification:** Valore opzionale per specificare i requisiti per la verifica dell'utente durante l'operazione. I valori possibili sono preferred (predefinito), required o discouraged.
### 2.3 Attestation
Durante la Cerimonia di Attestation / Registrazione, l'Autenticatore restituisce questa **Risposta di registrazione**. Puoi provarlo tu stesso nel [Passkeys Debugger](https://www.passkeys-debugger.io/).
```json
{
"authenticatorAttachment": "platform",
"id": "JKZbixUfKN_aZtimefYT-OjH5dw",
"rawId": "JKZbixUfKN_aZtimefYT-OjH5dw",
"response": {
"attestationObject": {
"fmt": "none",
"attStmt": {},
"authData": {
"rpIdHash": "PpZrl-Wqt-OFfBpyy2SraN1m7LT0GZORwGA7-6ujYkM",
"flags": {
"userPresent": true,
"userVerified": true,
"backupEligible": true,
"backupStatus": true,
"attestedData": true,
"extensionData": false
},
"counter": 0,
"aaguid": {
"raw": "fbfc3007-154e-4ecc-8c0b-6e020557d7bd",
"name": "iCloud Keychain"
},
"credentialID": "JKZbixUfKN_aZtimefYT-OjH5dw",
"credentialPublicKey": "pQECAyYgASFYIPWLalDzyxIDmAADvfK8iNM5To50kh7TyPH-teEz8RMdIlgg3D7bPIWQJ8z-WFn3zdYZzJw9c7mhPdmflQqD9vV7efA",
"parsedCredentialPublicKey": {
"keyType": "EC2 (2)",
"algorithm": "ES256 (-7)",
"curve": 1,
"x": "9YtqUPPLEgOYAAO98ryI0zlOjnSSHtPI8f614TPxEx0",
"y": "3D7bPIWQJ8z-WFn3zdYZzJw9c7mhPdmflQqD9vV7efA"
}
}
},
"clientDataJSON": {
"type": "webauthn.create",
"challenge": "k2p6f-upzP_hc6NZvmMAxiI0VSTeQIeXXVRGW62LTj0",
"origin": "https://www.passkeys-debugger.io",
"crossOrigin": false
},
"transports": ["hybrid", "internal"],
"authenticatorData": "PpZrl-Wqt-OFfBpyy2SraN1m7LT0GZORwGA7-6ujYkNdAAAAAPv8MAcVTk7MjAtuAgVX170AFCSmW4sVHyjf2mbYpnn2E_jox-XcpQECAyYgASFYIPWLalDzyxIDmAADvfK8iNM5To50kh7TyPH-teEz8RMdIlgg3D7bPIWQJ8z-WFn3zdYZzJw9c7mhPdmflQqD9vV7efA",
"publicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE9YtqUPPLEgOYAAO98ryI0zlOjnSSHtPI8f614TPxEx3cPts8hZAnzP5YWffN1hnMnD1zuaE92Z-VCoP29Xt58A",
"publicKeyAlgorithm": -7
},
"type": "public-key",
"clientExtensionResults": {}
}
```
L'**attestation** contiene alcuni componenti importanti come [attestationObject](#attestationObject), [algorithm](#algorithm) e i flag di [transport](#transport).
#### 2.3.1 attestationObject
Tratto dalle [Specifiche WebAuthn del W3C](https://www.w3.org/TR/webauthn-2/#attestation-object)
L'**attestationObject** è un oggetto codificato in CBOR che contiene informazioni sulle credenziali appena create, la chiave pubblica e altri dati rilevanti:
- **fmt** viene tipicamente valutato come "none" per le passkey
- **attStmt** è vuoto per le passkey e popolato per altri autenticatori, es. chiavi di sicurezza hardware (hardware security key)
- **authData** è un buffer di valori contenente i seguenti dati:
Scopri di più sulle [estensioni](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/WebAuthn_extensions).
#### algorithm
Le passkey vengono generate con **algoritmi COSE**, indicando l'algoritmo utilizzato nell'attributo **algorithm** di parsedCredentialPublicKey nell'[oggetto attestation](#attestation).
Ecco una panoramica dei più rilevanti algoritmi COSE:
#### 2.3.2 transport
La proprietà **transports** indica i meccanismi attraverso i quali un autenticatore può comunicare con un client. Alcune combinazioni di valori di esempio comuni sono:
- **"transports": \["internal","hybrid"]**: Le passkey possono essere utilizzate dall'autenticatore della piattaforma (es. Face ID, Touch ID, Windows Hello) o tramite l'autenticazione cross-device (utilizzando codice QR e Bluetooth).
- **"transports": \["internal"]**: Le passkey possono essere utilizzate solo dall'autenticatore della piattaforma (es. Face ID, Touch ID, Windows Hello)
- **Nessuna proprietà "transports" impostata:** comportamento predefinito che non fornisce indicazioni
### 2.4 Assertion
Durante la Cerimonia di Assertion / Accesso, l'Autenticatore restituisce questa **Risposta di accesso**. Puoi provarlo tu stesso nel [Passkeys Debugger](https://www.passkeys-debugger.io/).
```json
{
"id": "JKZbixUfKN_aZtimefYT-OjH5dw",
"rawId": "JKZbixUfKN_aZtimefYT-OjH5dw",
"type": "public-key",
"authenticatorAttachment": "platform",
"response": {
"authenticatorData": {
"rpIdHash": "PpZrl-Wqt-OFfBpyy2SraN1m7LT0GZORwGA7-6ujYkM",
"flags": {
"userPresent": true,
"userVerified": true,
"backupEligible": true,
"backupStatus": true,
"attestedData": false,
"extensionData": false
},
"counter": 0
},
"clientDataJSON": {
"type": "webauthn.get",
"challenge": "GCVkITWbe2l2dttsn_DgJYvH9QPHPDo0ygWgcgI6B7U",
"origin": "https://www.passkeys-debugger.io",
"crossOrigin": false,
"other_keys_can_be_added_here": "do not compare clientDataJSON against a template. See https://goo.gl/yabPex"
},
"signature": "MEQCIA-orC8N2KKWOxyY17BWP8lB-Be5to9btXRnJZf2SLhXAiBGxJe5Eu5LwOTbsyzAYmIXHOhlC3pN7s7Q1fRLvEW57g",
"userHandle": "_FKz1uwqmR_3yGq6hJntzoIFwFC_d1u_53YRELh0KlE"
}
}
```
L'**assertion** contiene alcuni componenti importanti come flag, signature e userHandle.
#### 2.4.1 flags
Ecco una panoramica dei **flag** più rilevanti e delle loro combinazioni:
#### 2.4.2 signature
La **signature** (firma) viene utilizzata per verificare che l'utente che cerca di accedere abbia effettivamente la chiave privata. La firma viene creata concatenando authenticatorData e clientDataHash (ovvero la versione SHA-256 di ClientDataJSON) e firmando il risultato con la chiave privata (nell'autenticatore). Per verificare con la chiave pubblica, concateniamo anch'essi authenticatorData e clientDataHash. Se il risultato della verifica restituisce true, l'autenticazione ha successo.
#### 2.4.3 userHandle
L'**userHandle** è l'effettivo user_id. Scopri di più su user_id nella sezione [**4.1 Schema del database.**](#database-schema)
### 2.5 authenticatorSelection
L'oggetto **authenticatorSelection** consente al server di dettare le impostazioni per l'autenticatore e la creazione delle credenziali con i seguenti valori:
#### 2.5.1 authenticatorAttachment
- **Platform:** L'autenticatore è collegato alla piattaforma del client e quindi non è rimovibile.
- **Cross-platform:** L'autenticatore non è vincolato alla piattaforma del client e può essere utilizzato su più dispositivi.
#### 2.5.2 residentKey
- **Required:** L'autenticatore deve creare una chiave residente (se non è possibile l'operazione dovrebbe fallire).
- **Preferred:** L'autenticatore dovrebbe cercare di creare una chiave residente (se non è possibile dovrebbe creare una chiave non residente).
- **Discouraged:** L'autenticatore deve creare una chiave non residente (se non è possibile l'operazione dovrebbe fallire).
> **Chiavi residenti (chiamate anche Credenziali rilevabili - Discoverable Credential):** Le chiavi residenti sono memorizzate sull'autenticatore e recuperate durante l'autenticazione. In questo modo il client può scoprire un elenco di chiavi possibili, motivo per cui la Conditional UI richiede chiavi residenti.
> **Chiavi non residenti (chiamate anche Credenziali non rilevabili - Non-Discoverable Credential):** In caso di chiavi non residenti, l'ID della credenziale è memorizzato sul server e fornito durante l'autenticazione. L'ID della credenziale è un [identificatore opaco](https://www.w3.org/TR/webauthn-3/#sctn-credential-id) la cui struttura interna è specifica dell'implementazione: gli autenticatori possono memorizzare le chiavi private direttamente, utilizzare il wrapping delle chiavi crittografate o derivare le chiavi da segreti interni. Il meccanismo esatto varia a seconda dell'implementazione dell'autenticatore.
#### 2.5.3 userVerification
- **Required:** L'operazione deve verificare l'utente.
- **Preferred:** L'operazione dovrebbe verificare l'utente, ma può procedere senza (opzione standard).
- **Discouraged:** L'operazione non deve verificare l'utente.
> **Attenzione:** Se impostato su "**Preferred",** l'utente o il suo dispositivo possono saltare la verifica dell'utente nel processo di autenticazione (scopri di più in questo [articolo](https://web.dev/articles/passkey-form-autofill)).
## 3. Conditional UI
La **Conditional UI** (autofill delle passkey) mostra le passkey disponibili in un menu a tendina di selezione per l'utente, quando un utente ha una chiave residente registrata con il relying party. Migliora l'usabilità delle passkey, ma richiede sforzi di sviluppo aggiuntivi e non è disponibile per tutte le combinazioni di sistemi operativi e browser.
### 3.1 Flusso di accesso con Conditional UI
_Come un normale accesso, anche la Conditional UI utilizza gli oggetti PublicKeyCredentialRequestOptions e assertion._
### 3.2 Compatibilità dei dispositivi
La Conditional UI non è ancora disponibile su tutte le combinazioni di sistemi operativi e browser. Ecco una panoramica dell'attuale copertura dei browser (marzo 2024):
Per una panoramica aggiornata vedi [questo sito.](https://caniuse.com/mdn-api_publickeycredential_isconditionalmediationavailable_static)
### 3.3 Esempi di codice
#### 3.3.1 Metodo per la Conditional UI
Un codice completo e minimalista per un metodo di Conditional UI si presenta così:
```html
Conditional UI
```
#### 3.3.2 Controllo della compatibilità del browser
La Conditional UI funziona solo con le **chiavi residenti** / credenziali rilevabili.
Si raccomanda di fornire un **endpoint server diverso** per avviare l'accesso tramite Conditional UI.
Il client deve soddisfare diversi requisiti:
- Il browser deve supportare la Conditional UI (vedi [3.2 Compatibilità dei dispositivi](#device-compatibility)).
- JavaScript deve essere abilitato e la pagina web deve fornire un campo di input HTML.
- I parametri di timeout dovrebbero essere ignorati.
Per evitare errori, il server dovrebbe prima testare la disponibilità del client con questa funzione:
Nel traffico reale, i problemi di rilevamento e del ciclo di vita emergono spesso come `NotAllowedError` o `AbortError`. Usa questa guida agli errori WebAuthn per la classificazione tra previsto e imprevisto, inclusi gli errori passkey del Credential Manager nativo.
```javascript
// source: https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/isConditionalMediationAvailable#examples
// Availability of `window.PublicKeyCredential` means WebAuthn is usable.
if (window.PublicKeyCredential && PublicKeyCredential.isConditionalMediationAvailable) {
// Check if conditional mediation is available.
const isCMA = await PublicKeyCredential.isConditionalMediationAvailable();
if (isCMA) {
// Call WebAuthn authentication start endpoint
let options = await WebAuthnClient.getPublicKeyRequestOptions();
const credential = await navigator.credentials.get({
publicKey: options.publicKeyCredentialRequestOptions,
mediation: "conditional",
});
/*
...
*/
}
}
```
#### 3.3.3 Token di compilazione automatica (Autocomplete) nei campi di input
Il campo di input dovrebbe ricevere un token autofill HTML, che segnala al client di popolare le passkey per la richiesta in corso. Oltre alle passkey, i token autofill possono essere abbinati a token esistenti, ad esempio nomi utente e password:
- autocomplete="username webauthn": Oltre a visualizzare le passkey, questo suggerisce anche l'autofill del nome utente.
- autocomplete="current-password webauthn": Oltre a visualizzare le passkey, questo richiede ulteriormente l'autofill della password.
```html
```
## 4. Server WebAuthn
### 4.1 Schema del database
Non esiste uno schema di database obbligatorio o standardizzato per i server WebAuthn. Tuttavia, questo esempio di schema di database può essere utilizzato per memorizzare le informazioni richieste e fornire tutte le funzionalità di un server WebAuthn:
_Gli attributi in grassetto sono obbligatori per un'implementazione minima funzionante, mentre gli altri sono necessari solo per funzionalità opzionali, ma utili._
#### 4.1.1 Dati rilevanti per l'autenticazione
- **ID della credenziale (Credential ID):** Questo è un ID univoco generato dall'autenticatore durante la registrazione di una passkey. Dovrebbe essere utilizzato per cercare l'account utente effettivo associato alla passkey. Inoltre, l'userHandle (da user_id) dovrebbe poi essere confrontato per convalidare l'account utilizzato per l'autenticazione. Non utilizzare l'attributo user.name per il confronto in quanto può cambiare nel tempo.
- **ID Utente (user_id):** ID univoco specificato dal Relying Party per rappresentare un account utente nel proprio sistema. Viene restituito come userHandle all'interno dell'oggetto assertion.
#### 4.1.2 Metadati per la visualizzazione e la selezione delle passkey:
- **Nome visualizzato dell'utente (user.displayName):** Nome leggibile e facile da usare per l'utente che è tipicamente il nome completo dell'utente. Viene mostrato all'utente, ma non utilizzato durante l'autenticazione.
- **Nome Utente (user.name):** Nome univoco e leggibile che è tipicamente un indirizzo e-mail o un nome utente. Può essere mostrato all'utente, ma non è utilizzato durante l'autenticazione.
### 4.2 ID del Relying Party (rpId)
L'**ID del Relying Party (rpID)** è un dominio memorizzato all'interno della passkey, garantendo che la passkey funzioni solo per il dominio corretto (URL del browser, vedi questo articolo per le app native). Durante l'autenticazione, l'rpID viene confrontato con l'URL del browser ed è consentito solo in questi due casi:
1. L'URL corrisponde esattamente all'rpId OPPURE
2. L'URL è un sottodominio che corrisponde all'rpId e il dominio genitore non è presente nella Public Suffix List
Ecco alcuni esempi di combinazioni consentite (e non):
## 5. Siti web e strumenti utili
Ecco un elenco di strumenti e siti web utili per l'implementazione delle passkey.
- [**Passkeys Debugger:**](https://www.passkeys-debugger.io/) Strumento per il debug delle Risposte WebAuthn come JSON e per testare le operazioni WebAuthn con diverse opzioni.
- **Glossario delle passkey:** Spiegazione dei termini e concetti relativi alle passkey.
- [**Specifiche WebAuthn:**](https://www.w3.org/TR/webauthn-2/) Queste sono le specifiche ufficiali WebAuthn.
- [**Log dei dispositivi Chrome:**](http://chrome://device-log) Strumento per mostrare un registro delle operazioni WebAuthn del tuo dispositivo (disponibile solo su Chrome tramite `chrome://device-log`)
Per le strategie su come ottimizzare la UX delle passkey oltre l'implementazione tecnica, consulta le nostre guide sulle best practice per la creazione di passkey e le best practice per l'accesso con passkey.
Se desideri implementare le passkey con poche righe di codice in qualsiasi applicazione, puoi anche utilizzare [Corbado Complete](https://docs.corbado.com/start) (per le nuove app) o [Corbado Connect](https://www.corbado.com/enterprise) (per le app esistenti).
## Domande frequenti (FAQ)
### Come implemento la Conditional UI per l'autofill delle passkey nella mia web app?
La Conditional UI richiede la verifica del supporto del browser tramite `PublicKeyCredential.isConditionalMediationAvailable()` prima di avviare l'autenticazione. Il campo di input deve includere il token HTML `autocomplete="username webauthn"` e l'utente deve avere registrato una chiave residente (credenziale rilevabile). Si raccomanda un endpoint server separato per gestire il flusso di accesso della Conditional UI.
### Quali sono i dati minimi che devo memorizzare nel mio database per supportare l'autenticazione WebAuthn?
Come minimo, memorizza l'ID della Credenziale, generato dall'autenticatore durante la registrazione, e l'ID Utente (user_id), che viene restituito come userHandle nell'oggetto assertion. Utilizza l'ID della Credenziale per cercare l'account utente associato e confronta l'userHandle per convalidare l'autenticazione. Evita di usare user.name per il confronto poiché può cambiare nel tempo.
### Qual è la differenza tra chiavi residenti e chiavi non residenti in WebAuthn?
Le chiavi residenti (credenziali rilevabili) sono memorizzate sull'autenticatore stesso e recuperate durante l'autenticazione, il che è necessario affinché la Conditional UI funzioni. Le chiavi non residenti memorizzano l'ID della credenziale sul server e lo inviano all'autenticatore durante l'autenticazione. Il campo residentKey in authenticatorSelection controlla questo comportamento con valori "required", "preferred" o "discouraged".
### Come funziona l'userVerification e quali sono i rischi se la si imposta su "preferred"?
Il campo userVerification controlla se l'autenticatore deve verificare l'utente durante l'accesso, accettando valori "required", "preferred" (impostazione predefinita) o "discouraged". Quando è impostato su "preferred", l'utente o il suo dispositivo possono saltare del tutto la verifica durante il processo di autenticazione, indebolendo potenzialmente la sicurezza. Impostarlo su "required" assicura che la verifica avvenga sempre prima del completamento dell'autenticazione.