Test het e-mailverificatieprotocol met een origin trial

Rowan Merewood

Gepubliceerd: 8 juli 2026, Laatste update: 5 oktober 2026

Als je een e-mailadres verzamelt als onderdeel van een aanmeldings-, inlog-, abonnements-, betaal-, accountherstels- of ander proces, is het gebruikelijk om te bevestigen dat het e-mailadres eigendom is van de persoon die het invoert. Voor bestaande verificatiemethoden, zoals eenmalige wachtwoorden (OTP's) of e-mailverificatielinks (magische links), moet de gebruiker uw site verlaten. Dit verstorende proces kan het risico vergroten dat de gebruiker, of dit nu een mens of een agent is, de sessie helemaal verlaat en het verificatieproces nooit afrondt.

De Email Verification API is een voorstel waarmee de browser rechtstreeks met de e-mailprovider kan communiceren om te verifiëren dat de gebruiker de eigenaar van het e-mailadres is. Gebruikers selecteren een e-mailadres uit de suggesties voor automatisch invullen of automatisch aanvullen van de browser, dienen het formulier in en de site verifieert het e-mailadres bij de provider zonder een e-mail te sturen of de gebruikersflow te onderbreken.

E-mailverzameling is een cruciaal conversiepunt in het traject van een gebruiker. Chrome wil graag feedback over het voorstel van sites die e-mails willen verifiëren, e-mailproviders die de verificatie kunnen uitvoeren en gebruikers die het proces doorlopen. Je kunt je vandaag nog aanmelden voor de origin trial en de implementatie-instructies hier volgen. Ga naar Aan de slag met origin trials voor algemene informatie over de configuratie van origin trials.

Je kunt de flow uitproberen met een demo-account:

• De demo voor uitgevers geeft je een nep-e-mailaccount en -sessie.
• De demo van Verifier verifieert elke deelnemende provider

Proces voor e-mailverificatie

In de volgende gedeelten staat wat jij en je gebruikers moeten doen om het e-mailverificatieproces te starten en de hele workflow als je het e-mailverificatieprotocol gebruikt.

Belangrijke termen

Dit zijn de belangrijkste termen voor de API voor e-mailverificatie:

• Verificator: De site die het e-mailadres verzamelt en het wil laten verifiëren. De verificateur wordt ook wel de Relying Party genoemd.
• E-mailprovider: De service die het e-mailadres van de gebruiker levert, bijvoorbeeld gmail.com.
• Uitgever: De service die het account voor het e-mailadres van de gebruiker beheert, bijvoorbeeld accounts.google.com. De kaartuitgever wordt ook wel de identiteitsprovider genoemd.

In sommige gevallen kunnen de e-mailprovider en de uitgever vanuit hetzelfde domein werken. Het is wel belangrijk om onderscheid te maken tussen een e-mailadres hebben en een actieve sessie hebben voor het gekoppelde account.

Vereisten

• De gebruiker moet zijn ingelogd bij de e-mailprovider of uitgever in hetzelfde browserprofiel. Als ze bijvoorbeeld Gmail gebruiken, moeten ze zijn ingelogd op hun Google-account.
• Als deelnemende verifiersite moet u zich aanmelden voor de oorsprongstest en de token op dezelfde pagina als uw e-mailformulier verstrekken.

• De gebruiker moet het e-mailadres selecteren in het dropdownmenu voor automatisch aanvullen.

  • Als de gebruiker eerder een e-mailadres in het veld heeft ingevoerd, wordt dit aangeboden via Automatisch aanvullen.

  • Als de gebruiker het e-mailadres heeft toegevoegd via de Chrome-instellingen voor Automatisch invullen en wachtwoorden (chrome://settings/autofill), wordt het aangeboden via automatisch invullen.

• De eerste keer dat een gebruiker een e-mailadres voor verificatie invoert, krijgt die een toestemmingsprompt. Dit gebeurt maar één keer per e-mailadres.

Zodra de gebruiker die actieve sessie in de browser heeft, kan die het proces starten:

1. In een formulier met een e-mailveld selecteert de gebruiker het e-mailadres in het dropdownmenu voor automatisch aanvullen. De verifiersite biedt een verborgen veld in het formulier met een nonce per instantie om dit verzoek te valideren.

2. De browser haalt dan de DNS-record voor e-mailverificatie op voor het e-maildomein. Hiermee wordt de browser naar de uitgever geleid. De uitgever bevestigt dan dat die een actieve sessie voor dat e-mailadres heeft.

3. De uitgever geeft daarna de e-mailverificatietoken (EVT) voor het adres op. De browser combineert dit tot een sleutelgebonden JWT met de EVT, de site-oorsprong en de nonce uit het invoerformulier.

4. Als het formulier wordt ingediend, wordt het EVT-pakket toegevoegd aan het verborgen veld en naar de site gestuurd.

5. De verifiersite verifieert daarna elk van deze gegevens: het verwachte e-mailadres, de nonce en handtekeningen van de browser en de uitgever.

6. De gebruiker ziet een kleine melding dat hun e-mailprovider hun adres heeft geverifieerd.

Dit proces geeft de verifieringssite de bevestiging dat het e-mailadres geldig is en bij de huidige gebruiker hoort. Dit betekent dat de site geen verificatiemail hoeft te sturen.

Gebruikers kunnen hun geverifieerde e-mailadressen beheren via Instellingen > Automatisch invullen en wachtwoorden > Contactgegevens > Geverifieerd e-mailadres (of open chrome://settings/contactInfo).

Overwegingen voor use cases

E-mailverificatie is een progressieve verbetering van uw bestaande proces. Hierdoor hoeft een gebruiker uw site niet te verlaten om een eenmalig wachtwoord op te halen of op een link te klikken. Sites kunnen de velden voor e-mailverificatie toevoegen aan alle relevante formulieren, zoals inlogformulieren, aanmeldingen voor nieuwsbrieven, accountcreatie en wachtwoordherstel. EVP wordt alleen geactiveerd als de browser dit ondersteunt. Als er geen code wordt ontvangen bij de indiening of als een van de validatiestappen mislukt, kun je terugvallen op het standaard e-mailbevestigingsproces. Dit betekent ook dat er geen functieherkenning voor de API is. De verifiersite behandelt de EVT als optioneel en verwerkt deze als deze aanwezig is in het verzoek.

E-mailverificatie bevestigt dat de gebruiker een actieve sessie heeft bij de provider van het e-mailadres. Het systeem verifieert niet of je e-mail de gebruiker heeft bereikt. Je wilt misschien nog steeds bestaande welkomst- of introductiemails sturen en de gebruiker vragen de spaminstellingen te checken.

De verifiersite implementeren

Ga voor meer informatie door de end-to-end democode en neem de validatiestappen door in de voorstellen voor de Email Verification API en het Email Verification Protocol.

Formuliervelden instellen

Zorg dat uw formuliervelden de juiste kenmerken hebben:

<input
  name="email-address"
  type="email"
  autocomplete="email">
<input
  type="hidden"
  name="token"
  nonce="rAnD0m-VaLuE"
  autocomplete="email-verification-token">

Stel de kenmerken type en autocomplete van de invoer email in op email, zodat de browser automatisch aanvullen kan aanbieden voor het e-mailadres.

Het nieuwe veld hidden wordt ingevuld met de e-mailverificatietoken als het formulier wordt ingediend. De vereiste kenmerken zijn:

• Stel type="hidden" in, omdat dit veld geen gebruikersinvoer vereist.
• Stel nonce="rAnD0m-VaLuE" in. De site moet een unieke, sessiegebonden nonce bieden om de formulierinzending te verifiëren.
• Stel autocomplete="email-verification-token" in. De browser gebruikt dit kenmerk om het in te vullen veld te identificeren.

Valideer je formulierelementen door het deelvenster Netwerk in DevTools te checken. Als je een e-mailadres selecteert, zie je dat de browser de DNS en de daaropvolgende zoekopdrachten voor het account activeert voor de e-mailprovider en de uitgever. Dit zijn interne browserverzoeken. Uw site ontvangt niets totdat het formulier is ingediend.

De EVT valideren

Er zijn 5 stappen om elke component van het EVT-pakket te valideren.

1. Parse de token.
2. Verwachte waarden valideren.
3. Valideer de sleutelbinding.
4. Valideer de DNS-record.
5. de uitgever ontdekken en de EVT-handtekening verifiëren.

1. De token parseren

De onbewerkte gegevens van de formulierinzending bevatten de EVT en ondertekende claims in een Selective Disclosure JSON Web Token (SD-JWT+KB), gescheiden door een tilde (~). Je moet deze scheiden en de JOSE-headers en -payloads (Javascript Object Signing and Encryption) decoderen (bijvoorbeeld met jose voor Node.js).

Als example.com demo@gmail.com verifieert, lijkt de gedecodeerde payload op het volgende voorbeeld:

{
  "evtJwtDecodedPayload": {
    "cnf": {
      "jwk": {
        "crv": "Ed25519",
        "kty": "OKP",
        "x": "pUbLiCkEy123pUbLiCkEy123pUbLiCkEy123"
      }
    },
    "email": "demo@gmail.com",
    "email_verified": true,
    "iat": 1782911685,
    "iss": "https://accounts.google.com"
  },
  "kbJwtDecodedPayload": {
    "aud": "https://example.com",
    "iat": 1782911685,
    "nonce": "rAnDoM123rAnDoM123rAnDoM123rAnDoM123",
    "sd_hash": "hAsH456hAsH456hAsH456hAsH456hAsH456"
  }
}

2. Verwachte waarden valideren

Controleer of de basiswaarden in de payload overeenkomen met de waarden die u heeft ingevoerd:

• Ga na of email_verified is ingesteld op true.
• Controleer of email overeenkomt met het e-mailadres dat u in het formulier heeft ingevuld.
• Ga na of nonce overeenkomt met de nonce die u in het formulier heeft ingevuld.
• Ga na of aud overeenkomt met de oorsprong van je site.
• Verifieer dat iat een relatief recent tijdstempel heeft, bijvoorbeeld nadat het formulier is gerenderd.

3. Sleutelbinding valideren

De browser maakt een tijdelijke, kortstondige sleutel voor de transactie om te bevestigen dat deze de token heeft ondertekend. Haal deze sleutel op uit de cnf (bevestigings)claim in de EVT en gebruik deze om de aan de sleutel gebonden JWT te verifiëren.

Bereken daarna de verwachte hash en vergelijk deze met de sd_hash-claim. In het volgende Node.js-voorbeeld staat hoe je deze berekening uitvoert:

const calculatedHash = createHash("sha256")
        .update(evtJwt + "~")
        .digest("base64url");

4. DNS-record valideren

Verifieer de _email-verification DNS-record voor het domein van het e-mailadres. Als je bijvoorbeeld demo@gmail.com wilt, zoek je de _email-verification.gmail.com TXT-record. Voor deze provider retourneert de query de locatie van de accountprovider, namelijk accounts.google.com.

$ dig +short TXT _email-verification.gmail.com
"iss=accounts.google.com"

5. De uitgever ontdekken en de EVT-handtekening verifiëren

Zorg dat de uitgever de /.well-known/email-verification-resource aanbiedt. Deze biedt de eindpunten voor de uitgifte van de token, de json-websleutel (JWK) voor de site en de ondersteunde ondertekeningsalgoritmen.

$ curl https://accounts.google.com/.well-known/email-verification
{
  "issuance_endpoint": "https://accounts.google.com/gsi/email-verification/issue",
  "jwks_uri": "https://verifiablecredentials-pa.googleapis.com/.well-known/vc-public-jwks",
  "signing_alg_values_supported": ["EdDSA"]
}

Gebruik de JWK's om de EVT JWT te verifiëren die je uit de token hebt geëxtraheerd. De meeste JOSE-bibliotheken bieden functies om deze verificatie af te handelen.

Als alle 5 stappen zijn gelukt, heb je het e-mailadres laten verifiëren door de provider. Als dat niet het geval is, stuurt u een bevestigingsmail naar de gebruiker volgens uw normale proces.

Implementeer de service van de e-mailprovider en de uitgever

Ga voor meer informatie naar de democode voor een nep-e-mailprovider en neem de stappen voor de uitgever door in de voorstellen voor de Email Verification API en het Email Verification Protocol.

Als uitgever hoeft u zich niet aan te melden voor de oorspronkelijke proefperiode of een token aan te leveren, omdat het browsergedrag wordt geactiveerd door de site van de afhankelijke partij. Je moet alleen zorgen dat de verwachte eindpunten aanwezig zijn om op die verzoeken te reageren.

Detectie van uitgevers instellen

Als u wilt dat browsers uw verificatie-eindpunten automatisch kunnen vinden als er een e-mailadres van uw domein is geselecteerd, stelt u uw configuratie beschikbaar via DNS en een .well-known HTTP-eindpunt.

DNS-delegeringsrecord configureren

Stel een DNS TXT-record in voor je e-maildomein dat de verificatiebevoegdheid delegeert aan je uitgever-ID. Deze ID's kunnen hetzelfde domein gebruiken, afhankelijk van uw infrastructuur.

Opname-indeling: _email-verification.<email-domain>

Voorbeeld van een zonebestand:

_email-verification.example.com IN TXT "iss=accounts.issuer.example"

Een .well-known/email-verification-eindpunt hosten

Host een json-bestand met metadata in uw uitgevende domein onder het pad /.well-known/. Dit bestand beschrijft je uitgiftecapaciteiten en de cryptografische ondertekeningsalgoritmen die je infrastructuur ondersteunt.

Eindpunt: https://<issuer-domain>/.well-known/email-verification

Voorbeeld van een reactie:

{
  "issuance_endpoint": "https://accounts.issuer.example/email-verification/issuance",
  "jwks_uri": "https://accounts.issuer.example/.well-known/vc-public-jwks",
  "signing_alg_values_supported": ["EdDSA", "ES256"]
}

Een .well-known/web-identity-eindpunt hosten

Een extra .well-known json-resource die je misschien al hebt geïmplementeerd als onderdeel van de Federated Credentials (FedCM) API. Dit biedt links naar het eindpunt van uw account en de inlog-URL.

Eindpunt: https://<domain>/.well-known/web-identity

Voorbeeld van een reactie:

{
  "accounts_endpoint": "https://accounts.issuer.example/accounts",
  "login_url": "https://accounts.issuer.example/login"
}

Een eindpunt voor accounts gebruiken

Het eindpunt accounts van de FedCM API biedt op dit moment een lijst met ingelogde accounts. Het volgende voorbeeld toont een minimale reactie. Ga naar de implementatiehandleiding voor identiteitsproviders voor meer informatie.

Eindpunt: zoals aangegeven in .well-known/web-identity

Dit is een voorbeeldreactie:

{
  "accounts": [
    {
      "id": "demo-example",
      "name": "Demo User",
      "email": "demo@example.com",
      "given_name": "Demo"
    }
  ]
}

Integreren met de Login Status API

De gebruiker moet een actieve sessie bij de provider hebben en je moet dit aan de browser doorgeven met de Login Status API.

Als een gebruiker in- of uitlogt, serveer je de bijbehorende HTTP-reactieheader:

Set-Login: logged-in
Set-Login: logged-out

U kunt de status ook updaten met JavaScript in de context van uw web-app:

navigator.login.setStatus("logged-in");
navigator.login.setStatus("logged-out");

Uitgifteverzoeken verwerken

Je issuance_endpoint krijgt een application/x-www-form-urlencoded POST-verzoek met de request_token.

In de volgende gedeelten staat het hele proces voor de verwerking van uitgifteverzoeken.

1. Het uitgifteverzoek valideren

Inkomende browser-payloads parseren en valideren:

• Methode: POST
• Sessiecontrole: Valideer de first-party cookies van de gebruiker die samen met het verzoek worden overgedragen om te zorgen dat er een actief, geautoriseerd identiteitscontext bestaat.session/authentication
• Parameterverificatie: Haal de parameter request_token op (een ondertekende JWT die door de browser is gegenereerd). Verifieer dat het de verwachte tijdelijke openbare sleutel, het doel-e-mailadres, de juiste doelgroep en een geldig tijdstempel bevat.

De gedecodeerde token ziet er ongeveer zo uit:

{
  "decodedHeader": {
    "alg": "ES256",
    "typ": "JWT",
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "pUbLiCKeY123pUbLiCKeY123pUbLiCKeY123",
      "y": "pUbLiCKeY456pUbLiCKeY456pUbLiCKeY456"
    }
  },
  "decodedPayload": {
    "iss": "https://accounts.issuer.example",
    "sub": "demo@example.com",
    "email": "demo@example.com",
    "iat": 1780272000,
    "exp": 1780272300
  },
  "signature": "SIGnatURE-123_SIGnatURE-123_SIGnatURE-123"
}

2. Reageren met een token

Nadat de sessie- en verzoektoken zijn gevalideerd, genereer je een ondertekende Selective Disclosure JWT (SD-JWT) met de volgende payload:

{
  "iss": "https://accounts.issuer.example",
  "iat": 1780272000,
  "exp": 1780272300,
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "pUbLiCKeY123pUbLiCKeY123pUbLiCKeY123",
      "y": "pUbLiCKeY456pUbLiCKeY456pUbLiCKeY456"
    }
  },
  "email": "demo@example.com",
  "email_verified": true
}

Onderteken de payload met je privésleutel en een ondersteund algoritme. Bijvoorbeeld: jose gebruiken in Node.js:

const evtJwt = await new SignJWT(evtPayload)
   .setProtectedHeader({
     alg: "EdDSA",
     kid: PRIVATE_KEY_JWK.kid, // Key ID corresponding to our JWKS keys
     typ: "evt+jwt", // Standard Token Type for EVTs
   })
   .sign(privateKey);

 // Standard SD-JWT compatibility requires appending a trailing tilde "~"
 // to separate the signed token from the key binding section.
 const issuanceToken = `${evtJwt}~`;

Voorbeeld van een geslaagde reactie (HTTP 200):

{
  "issuance_token": "tOkEn123tOkEn123tOkEn123...~"
}

Overwegingen voor origin trials

Origin trials zijn experimenten om feedback te verzamelen. Je inbreng is dus essentieel als je deelneemt als afhankelijke partij of identiteitsprovider. Gebruik de volgende GitHub-opslagplaatsen om problemen te melden:

• Browser Email Verification API: WICG/email-verification
• E-mailverificatieprotocol: dickhardt/email-verification

Als je bugs tegenkomt in de Chrome-implementatie, dien je een bug in voor de component:

• Nieuw probleem: Chromium > Blink > Identity > EVP

De functionaliteit van de origin trial aanzetten, wordt per reactie beheerd door het OT-token op te nemen. Dit betekent dat je gedetailleerde controle hebt als je de functionaliteit wilt beperken tot een deel van je gebruikers. Als je bijvoorbeeld al een A/B-testframework hebt, kun je de origin trial daar integreren voor een gecontroleerde experimentpopulatie. Als je een groep gebruikers hebt voor bètatests of vroege previews, wil je de functie misschien aanzetten voor hen. Check in dit geval het verstrekte e-mailadres voordat je de token uitgeeft of valideert.

Origin trials hebben ook verkeerslimieten om te voorkomen dat sites vóór de lancering op de functie vertrouwen. De uitgever-API is in ontwikkeling. Je kunt dus wijzigingen verwachten die niet achterwaarts compatibel zijn, samen met updates van de Chrome-UX.

We posten verdere updates op dit blog en op de mailinglijst evp-announce@chromium.org naarmate de ontwikkeling vordert.