Publié le 13 août 2026, dernière mise à jour le 5 octobre 2026
L'essai Origin Trial de validation des adresses e-mail a commencé dans Chrome 150. Grâce à vos commentaires, nous avons apporté plusieurs corrections et améliorations. Cet article présente les modifications et les actions que vous devez effectuer sur votre site ou service.
Tout d'abord, rappelons la fonctionnalité de validation des adresses e-mail (pour en savoir plus, consultez l'annonce précédente). Sur de nombreux sites, l'utilisateur doit saisir une adresse e-mail lors de l'inscription, de la connexion, de la récupération de compte, etc., puis accéder à sa boîte de réception pour cliquer sur un lien magique ou obtenir un code OTP. La validation d'adresse e-mail offre une amélioration progressive en validant l'adresse e-mail auprès du fournisseur directement dans le navigateur. Le site reçoit ensuite un jeton du navigateur qu'il peut valider auprès du fournisseur de messagerie et éviter ainsi d'envoyer cet e-mail.
Mises à jour visibles par les utilisateurs
Modifications de l'interface utilisateur ou du comportement visible par l'utilisateur.
Saisie de l'adresse e-mail
Auparavant, les utilisateurs devaient utiliser la saisie semi-automatique ou automatique pour saisir une adresse e-mail. Désormais, la saisie d'une adresse e-mail dans le champ (par exemple, en la tapant ou en la collant) déclenche le processus de validation une fois que l'utilisateur quitte l'élément input, comme pour un événement change. Cela signifie que la validation de l'adresse e-mail devrait se déclencher pour toute adresse e-mail saisie.
Indicateur de progression
Nous testons également un indicateur de progression pour le processus de validation dans Chrome 152 et versions ultérieures. Bien que le processus de validation soit rapide, il est toujours possible qu'un utilisateur envoie le formulaire avant qu'il ne soit terminé. L'indicateur de progression affiche une icône de chargement pendant la vérification, puis une coche une fois l'opération terminée, à la fin de la ligne (à droite pour une langue LTR) du champ de saisie.
Si cela pose problème ou si vous constatez un comportement inattendu, signalez un bug.
Ordinateur uniquement
La validation par e-mail n'est disponible que sur ordinateur jusqu'à Chrome 152. Nous étudions activement la possibilité de proposer cette fonctionnalité sur Android et nous vous tiendrons informé.
Mises à jour du vérificateur
Modifications apportées aux sites qui collectent et valident des adresses e-mail
Validation des jetons
Le jeton de validation de l'adresse e-mail est fourni au format Selective Disclosure for JSON Web Tokens (SD-JWT). Dans sa forme brute, il ressemble à ceci : un jeton JWT signé par l'émetteur, suivi d'une ou plusieurs divulgations, et se terminant par un jeton JWT de liaison de clé, chaque composant étant séparé par un tilde :
<Issuer-signed JWT>~<Disclosure.1>~<Disclosure.2>~...~<Disclosure.N>~<Key Binding JWT>
Le jeton de validation de l'adresse e-mail, dans sa forme actuelle, ne renvoie que le jeton JWT signé par l'émetteur et le jeton JWT de liaison de clé, sans aucune information. L'article de blog d'origine et la première itération de la démo consistaient simplement à diviser le jeton en deux et à analyser les deux JWT. Cette méthode est fragile et ne fonctionnerait pas si des divulgations sélectives étaient ajoutées à l'avenir.
Plutôt que de vous appuyer sur cette fonctionnalité de la proposition actuelle, vous devez vous assurer que votre implémentation analyse correctement le jeton SD-JWT conformément à sa spécification, idéalement en utilisant des bibliothèques pour votre plate-forme. Par exemple, le code de validation de démonstration utilise désormais @sd-jwt/core pour analyser le jeton et valider l'association de clé (audience, nonce et hachage), puis jose pour valider les signatures du jeton EVT de l'émetteur et du jeton JWT d'association de clé du navigateur.
Tests d'origine tiers
Les versions d'essai d'origine tierces ne sont plus compatibles avec la validation des adresses e-mail depuis le mois d'août. Les essais Origin Trial tiers permettent à une origine tierce d'activer la fonctionnalité d'essai sur un site où elle est incluse, par exemple une dépendance JavaScript interorigine. Si cette fonctionnalité est une priorité pour votre cas d'utilisation, commentez ou suivez le bug de suivi.
Comparaison des adresses e-mail non sensible à la casse
Rappelons que les fournisseurs de messagerie peuvent renvoyer l'adresse e-mail canonique en majuscules (par exemple, Demo.User@example.com), même si demo.user@example.com a été fournie dans le formulaire. Assurez-vous d'effectuer une comparaison non sensible à la casse avec l'adresse e-mail reçue. Nous avons également corrigé un bug sur la page des paramètres, qui pouvait afficher des variantes sensibles à la casse de la même adresse e-mail.
Informations destinées aux fournisseurs
Modifications pour les fournisseurs de messagerie
Signature de message HTTP pour les demandes d'émission
Nous allons introduire un changement incompatible dans Chrome 153, où la demande d'émission n'enverra que le email au format application/json avec signatures de message HTTP.
- Chrome 152 (et versions antérieures) : le point de terminaison d'émission reçoit une requête
application/x-www-form-urlencodedPOSTavecrequest_tokendans le corps. - Chrome 153 (et versions ultérieures) : le type de contenu passe à
application/jsonavec les en-têtesSignature,Signature-InputetSignature-Key, et un corps contenant uniquement la cléemail.
En fonction de vos niveaux de trafic actuels et de vos objectifs de test, vous pouvez :
- Prenez en charge les deux formats et basculez de l'un à l'autre en fonction du type de contenu. Une fois que Chrome 153 sera disponible en version stable fin août, vous pourrez évaluer votre trafic pour supprimer l'ancienne fonctionnalité.
- Il vous suffit de passer au nouveau format. La validation échouera pour les utilisateurs qui utilisent des versions antérieures de Chrome.
Le point de terminaison d'émission dans le code de démonstration a été mis à jour pour gérer les deux flux à l'aide de structured-headers et http-message-sig.
Format complet de la demande :
POST /email-verification/issuance HTTP/1.1
Host: provider.example
Accept: application/json
Content-Digest: sha-256=:aBc123aBc123aBc123aBc123aBc123=:
Content-Type: application/json
Signature: sig=:+dEf567dEf567/dEf567dEf567dEf567/dEf567==:
Signature-Input: sig=("@method" "@authority" "@path" "content-digest" "signature-key");created=1786455840
Signature-Key: sig=hwk;crv="Ed25519";kty="OKP";x="gHi890_gHi890_gHi890"
{email: "demo@example.com"}
Le format de la réponse reste le même : un issuance_token dans un corps application/json.
Vous pouvez lire et envoyer d'autres commentaires sur les dépôts de propositions : WICG/email-verification et dickhardt/email-verification. Les réponses de la communauté ont été extrêmement utiles jusqu'à présent. Vous pouvez donc vous attendre à ce que les mises à jour et les améliorations se poursuivent.