Verifica email

L'API Verifica email è una proposta che consente al browser di comunicare direttamente con il provider email per verificare che l'utente sia il proprietario dell'indirizzo email. Gli utenti inseriscono il loro indirizzo email, inviano il modulo e il sito verifica il token di verifica email firmato dal browser con il provider senza inviare un'email o interrompere il flusso dell'utente.

Quando raccolgono un indirizzo email durante la registrazione, l'accesso, il pagamento, l'iscrizione alla newsletter o il recupero dell'account, i siti in genere confermano che la persona che invia il modulo controlla l'indirizzo. I metodi di verifica esistenti richiedono agli utenti di uscire dal sito, cambiare app per controllare la posta in arrivo, copiare un OTP o fare clic su un link di verifica. Questa interruzione aumenta l'abbandono e l'interruzione della sessione sia per gli utenti umani sia per gli agenti automatici. Gli utenti spesso riscontrano problemi con i metodi di verifica esistenti, ad esempio email ritardate, link scaduti o codici non riconosciuti.

Demo del prompt utente di verifica email
Demo del prompt utente di verifica email

La verifica email funge da potenziamento progressivo del flusso esistente:

  • Nessuna interruzione: la verifica viene eseguita in background mentre l'utente compila il modulo.
  • Non è necessario rilevare le funzionalità: i siti aggiungono un input email e un input token nascosto ai moduli. Se il browser o il provider non supporta la verifica email o se la verifica non va a buon fine, il sito torna al flusso di conferma email predefinito.
  • Riduzione al minimo dei rischi di phishing: non è necessario copiare alcun codice né esiste la possibilità di inviare l'utente a un sito falso.

Puoi testare il flusso nella demo:

Considerazioni sull'origin trial

Gli origin trial sono esperimenti per raccogliere feedback, quindi il tuo contributo è fondamentale se partecipi come relying party o provider di identità. Per segnalare problemi, utilizza i seguenti repository GitHub:

Se riscontri bug nell'implementazione di Chrome, segnala un problema nel seguente componente:

Puoi controllare la funzionalità dell'origin trial in base alla risposta includendo il token dell'origin trial. In questo modo puoi limitare la funzionalità a un segmento specifico di utenti, ad esempio una popolazione di test A/B. In alternativa, se hai un gruppo di utenti di test beta o di anteprima, potresti voler o dover attivare la funzionalità per loro. In questo caso, controlla l'indirizzo email fornito prima di emettere o convalidare il token.

Gli origin trial hanno anche limiti di traffico per ridurre al minimo i siti che si basano sulla funzionalità prima del lancio. L'API dell'emittente è in fase di sviluppo e dovresti aspettarti modifiche incompatibili con le versioni precedenti insieme agli aggiornamenti dell'esperienza utente di Chrome.

Man mano che lo sviluppo procede, cerca ulteriori aggiornamenti sul blog qui e nella evp-announce@chromium.org

Flusso di verifica email

Le sezioni seguenti spiegano i termini chiave e i passaggi del protocollo quando si utilizza l'API Email Verification.

Termini chiave

I termini chiave per l'API Verifica email sono:

  • Verificatore: il sito che raccoglie l'indirizzo email e vuole verificare lo. Il verificatore è chiamato anche Relying Party.
  • Provider di posta elettronica: il servizio che fornisce l'indirizzo email dell'utente, ad esempio gmail.com.
  • Emittente: il servizio che gestisce l'account per l'email dell'utente, ad esempio accounts.google.com. L'emittente è chiamato anche Identity Provider.

In alcuni casi, il provider di posta elettronica e l'emittente operano dallo stesso dominio. Tuttavia, è importante distinguerli perché l'API Email Verification utilizza la sessione attiva nel browser con il provider di identità come metodo di verifica. Ad esempio, per verificare example@gmail.com, l'utente deve aver eseguito l'accesso a google.com con quell'account nello stesso browser.

Flusso del protocollo

Architettura del flusso di verifica email
Architettura del flusso di verifica email
  1. Presentazione del modulo: la relying party pubblica un modulo HTML contenente un <input type="email"> e un input nascosto contrassegnato con autocomplete="email-verification-token" e un nonce univoco per istanza.
  2. Inserimento dell'email: quando l'utente inserisce un indirizzo email, selezionando un suggerimento di compilazione automatica o digitando o incollando e uscendo dal campo (blur), il browser attiva la verifica in background.
  3. Rilevamento e sessione: il browser esegue una query sul record TXT DNS per _email-verification.<email-domain> per scoprire l'origine dell'emittente autorizzato del provider, quindi controlla se l'utente ha una sessione attiva utilizzando la configurazione .well-known/web-identity dell'emittente e gli endpoint degli account FedCM. Se il dominio non pubblica un record EVP o non esiste una sessione attiva, il browser interrompe la verifica senza chiedere all'utente.
  4. Emissione del token: il browser rileva l'issuance_endpoint del provider da .well-known/email-verification, crea una coppia di chiavi effimere e invia una richiesta HTTP POST utilizzando HTTP Message Signatures (RFC 9421) con i cookie di sessione proprietari dell'emittente e l'indirizzo email di destinazione per ricevere un token di verifica email firmato (EVT).
  5. Associazione di chiavi e invio: il browser associa l'EVT firmato all' origine della relying party e al nonce del modulo all'interno di un JWT di associazione di chiavi (KB-JWT) e mostra una piccola notifica che informa l'utente che il suo provider di posta elettronica ha verificato il suo indirizzo. Quando l'utente invia il modulo, Chrome compila l'input nascosto con il token combinato (<EVT>~<KB-JWT>).
  6. Convalida delle attestazioni e della KB: il server della relying party analizza il token <EVT>~<KB-JWT>, convalida le attestazioni previste (email, email_verified, aud, nonce, iat, e exp) e verifica la firma di associazione di chiavi rispetto alla chiave pubblica effimera in cnf.jwk.
  7. DNS e chiavi pubbliche: la relying party esegue una query sul record TXT DNS _email-verification.<email-domain> per verificare che corrisponda all'attestazione del token iss, quindi recupera i metadati .well-known/email-verification dell'emittente e le chiavi pubbliche da jwks_uri.
  8. Verifica l'EVT e completa: la relying party verifica la firma EVT dell'emittente utilizzando il JWKS pubblico del provider. Se non viene ricevuto alcun token o se un passaggio di convalida non va a buon fine, il sito torna al processo di conferma email esistente.

La prima volta che un utente verifica un indirizzo email, Chrome mostra un prompt di autorizzazione (una finestra di dialogo su computer o un riquadro inferiore su Android) prima di richiedere un token. Se concessa, questa autorizzazione viene memorizzata per indirizzo email nei siti partecipanti.

Impostazioni di Chrome

Gli utenti possono gestire le loro email verificate:

  • Su computer, in Impostazioni > Compilazione automatica e password > Informazioni di contatto > Email verificata (o apri chrome://settings/contactInfo)
  • Su Android, in Impostazioni > Indirizzi e altro > Email verificata

Gli utenti possono disattivare completamente la funzionalità o gestire i singoli indirizzi email verificati.

Considerazioni sui casi d'uso

La verifica email è un potenziamento progressivo del flusso esistente che elimina la necessità per un utente di uscire dal sito per recuperare un OTP o fare clic su un link. I siti possono aggiungere i campi di verifica email a tutti i moduli pertinenti, come accessi, iscrizioni alla newsletter, creazione di account e recupero della password. L'EVP viene attivato solo se il browser lo supporta. Se non viene ricevuto alcun codice all'invio o se uno dei passaggi di convalida non va a buon fine, puoi tornare al flusso di conferma email predefinito. Ciò significa anche che non esiste il rilevamento delle funzionalità per l'API; il sito del verificatore tratta l'EVT come facoltativo, elaborandolo se è presente nella richiesta.

La verifica email conferma che l'utente ha una sessione attiva con il provider del suo indirizzo email. Non verifica che l'email sia stata ricevuta dall'utente. Potresti comunque voler inviare le email di benvenuto o di onboarding esistenti e potresti voler o dover chiedere all'utente di controllare le impostazioni dello spam.