Updates voor e-mailverificatie, augustus 2026

Rowan Merewood

Gepubliceerd: 13 augustus 2026

De proef met e-mailverificatie is gestart in Chrome 150. Op basis van jullie feedback hebben we verschillende bugs verholpen en verbeteringen doorgevoerd. Dit bericht geeft een overzicht van de wijzigingen en de acties die je op je website of service moet ondernemen.

Eerst een korte samenvatting van de e-mailverificatiefunctie (of raadpleeg de eerdere aankondiging voor meer details). Een veelvoorkomend patroon op websites is dat gebruikers een e-mailadres invoeren als onderdeel van registratie, inloggen, accountherstel, enzovoort, en vervolgens naar hun e-mail moeten gaan om op een geheime link te klikken of een OTP te ontvangen. E-mailverificatie biedt een verbeterde versie hiervan door het e-mailadres rechtstreeks in de browser bij de provider te verifiëren. De website ontvangt vervolgens een token van de browser dat kan worden gevalideerd bij de e-mailprovider, waardoor het versturen van die e-mail helemaal wordt overgeslagen.

Gebruikersgerichte updates

Wijzigingen in de gebruikersinterface of het gedrag dat de gebruiker ervaart.

E-mailinvoer

Voorheen moesten gebruikers de automatische aanvulfunctie gebruiken om een ​​e-mailadres in te voeren. Nu wordt het verificatieproces geactiveerd zodra de gebruiker het input verlaat (bijvoorbeeld door te typen of te plakken), net als bij een change . Dit betekent dat de e-mailverificatie in principe wordt geactiveerd bij elke ingevoerde e-mailadres.

Voortgangsindicator

We testen momenteel ook een voortgangsindicator voor het verificatieproces in Chrome 152+. Hoewel het verificatieproces snel verloopt, is het nog steeds mogelijk dat een gebruiker het formulier verzendt voordat het proces is voltooid. De voortgangsindicator toont een draaiend icoontje tijdens de verificatie en vervolgens een vinkje aan het einde (rechterkant voor een taal met leesrichting van links naar rechts) van het invoerveld wanneer de verificatie is voltooid.

Als dit problemen veroorzaakt of als u onverwacht gedrag opmerkt, meld dit dan als een bug .

Alleen voor desktop

E-mailverificatie is alleen beschikbaar op desktops tot en met Chrome versie 152. We onderzoeken actief de mogelijkheden voor ondersteuning op Android en zullen hier in de toekomst meer informatie geven.

Updates van de verificatie-instantie

Wijzigingen voor websites die e-mailadressen verzamelen en verifiëren.

Tokenvalidatie

Het e-mailverificatietoken wordt geleverd in het Selective Disclosure for JSON Web Tokens (SD-JWT) -formaat. In de ruwe vorm ziet dit er als volgt uit: een door de uitgever ondertekend JWT, gevolgd door nul of meer Disclosures, en eindigend met een Key Binding JWT, waarbij elk onderdeel gescheiden is door een tilde:

<Issuer-signed JWT>~<Disclosure.1>~<Disclosure.2>~...~<Disclosure.N>~<Key Binding JWT>

Het e-mailverificatietoken retourneert in zijn huidige vorm alleen de door de uitgever ondertekende JWT en de sleutelbindende JWT, zonder enige openbaarmakingen. In het oorspronkelijke blogbericht en de eerste versie van de demo werd het token in tweeën gesplitst en werden de twee JWT's geanalyseerd. Dit is een kwetsbare methode die zou kunnen falen als er in de toekomst selectieve openbaarmakingen worden toegevoegd.

In plaats van te vertrouwen op deze functie van het huidige voorstel, moet u ervoor zorgen dat uw implementatie het SD-JWT-token correct parseert volgens de specificatie, idealiter door gebruik te maken van bibliotheken voor uw platform. De demo-verificatiecode gebruikt bijvoorbeeld nu @sd-jwt/core om het token te parseren en de sleutelbinding (audience, nonce en hash) te valideren, en vervolgens jose om de handtekeningen voor de EVT van de uitgever en de Key Binding JWT van de browser te verifiëren.

Oorsprongsonderzoeken door derden

Proefversies van externe bronnen worden sinds augustus niet meer ondersteund voor e-mailverificatie. Met proefversies van externe bronnen kan een externe bron de proeffunctionaliteit inschakelen op een site waar deze is opgenomen, bijvoorbeeld als een cross-origin JavaScript-afhankelijkheid. Als dit voor uw gebruikssituatie prioriteit heeft, kunt u een reactie plaatsen of de betreffende bug volgen.

E-mailvergelijking zonder rekening te houden met hoofdletters

Ter herinnering: e-mailproviders kunnen het canonieke e-mailadres met hoofdletters retourneren, bijvoorbeeld Demo.User@example.com , zelfs als demo.user@example.com in het formulier is ingevoerd. Zorg ervoor dat u een hoofdletterongevoelige vergelijking maakt met het ontvangen e-mailadres. We hebben ook een bug in de instellingenpagina verholpen waar u mogelijk hoofdlettergevoelige varianten van hetzelfde e-mailadres zag staan.

Updates van de provider

Wijzigingen voor e-mailproviders.

HTTP-berichthandtekening voor uitgifteverzoeken

We introduceren een ingrijpende wijziging in Chrome 153, waarbij het verzendverzoek alleen email in het formaat application/json met HTTP-berichtsignaturen zal versturen.

  • Chrome 152 (en ouder): Het uitgifte-eindpunt ontvangt een application/x-www-form-urlencoded POST verzoek met de request_token in de body.
  • Chrome 153 (en later): Het contenttype verandert naar application/json met de headers Signature , Signature-Input en Signature-Key , en een body die alleen de email bevat.

Afhankelijk van uw huidige verkeersniveaus en testdoelen kunt u het volgende doen:

  • Ondersteun beide formaten en schakel automatisch over op basis van het contenttype. Zodra Chrome 153 eind augustus stabiel is, kunt u uw verkeer analyseren om de verouderde functionaliteit te verwijderen.
  • Schakel gewoon over naar het nieuwe formaat, waardoor de verificatie voor gebruikers van oudere Chrome-versies zal mislukken.

Het uitgifte-eindpunt in de democode is bijgewerkt om beide stromen te verwerken, zowel met structured-headers als met http-message-sig .

Volledig aanvraagformulier:

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"}

Het antwoordformaat blijft hetzelfde: een issuance_token in een application/json -bestand.

Je kunt de voorstellen lezen en aanvullende feedback geven via de volgende repositories: WICG/email-verification en dickhardt/email-verification . De reacties vanuit de community zijn tot nu toe zeer behulpzaam geweest, dus je kunt verwachten dat de updates en verbeteringen zullen worden voortgezet.