Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

E‑Mail-Bestätigungsprotokoll mit einem Origin-Trial testen

Rowan Merewood

Veröffentlicht am 8. Juli 2026

Wenn Sie im Rahmen einer Registrierung, Anmeldung, eines Abos, eines Check-outs, einer Kontowiederherstellung oder eines anderen Vorgangs eine E-Mail-Adresse erheben, ist es üblich, zu bestätigen, dass die E-Mail-Adresse der Person gehört, die sie eingibt. Bei bestehenden Bestätigungsmethoden wie Einmalpasswörtern oder E‑Mail-Bestätigungslinks (Magic Links) muss der Nutzer Ihre Website verlassen. Dieser störende Prozess kann das Risiko erhöhen, dass der Nutzer, ob Mensch oder Agent, die Sitzung ganz abbricht und den Authentifizierungsprozess nie abschließt.

Die Email Verification API ist ein Vorschlag, der es dem Browser ermöglicht, direkt mit dem E‑Mail-Anbieter zu kommunizieren, um zu bestätigen, dass der Nutzer Inhaber der E‑Mail-Adresse ist. Nutzer wählen eine E‑Mail-Adresse aus dem Vorschlag der Autofill- oder Autocomplete-Funktion des Browsers aus, senden das Formular ab und die Website bestätigt die E‑Mail-Adresse beim Anbieter, ohne eine E‑Mail zu senden oder den Nutzerfluss zu unterbrechen.

Demo der Nutzeraufforderung für die Email Verification API — Demo für Nutzeraufforderung der Email Verification API

Die Erhebung von E-Mail-Adressen ist ein wichtiger Conversion-Punkt im Nutzerverlauf. Chrome möchte Feedback zum Vorschlag von Websites, die E-Mail-Adressen bestätigen möchten, von E-Mail-Anbietern, die die Bestätigung durchführen können, und von Nutzern, die den Prozess durchlaufen. Sie können sich noch heute für den Ursprungstest registrieren und der Implementierungsanleitung folgen. Allgemeine Informationen zur Konfiguration von Origin Trials finden Sie unter Erste Schritte mit Origin Trials.

Sie können den Ablauf mit einem Demo-Konto testen:

Issuer demo bietet Ihnen ein Mock-E-Mail-Konto und eine Mock-Sitzung.
Mit der Verifier-Demo kann jeder teilnehmende Anbieter überprüft werden.

Ablauf der E‑Mail-Bestätigung

In den folgenden Abschnitten wird erläutert, was Sie und Ihre Nutzer benötigen, um den E‑Mail-Bestätigungsprozess zu starten, und wie der gesamte Workflow bei Verwendung des E‑Mail-Bestätigungsprotokolls aussieht.

Wichtige Begriffe

Die wichtigsten Begriffe für die Email Verification API sind:

Bestätiger: Die Website, auf der die E-Mail-Adresse erhoben und bestätigt werden soll. Der Prüfer wird auch als Relying Party bezeichnet.
E‑Mail-Anbieter: Der Dienst, der die E‑Mail-Adresse des Nutzers bereitstellt, z. B. gmail.com.
Aussteller: Der Dienst, der das Konto für die E-Mail-Adresse des Nutzers verwaltet, z. B. accounts.google.com. Der Aussteller wird auch als Identitätsanbieter bezeichnet.

In einigen Fällen können der E‑Mail-Anbieter und der Aussteller dieselbe Domain verwenden. Es ist jedoch wichtig, zwischen einer E‑Mail-Adresse und einer aktiven Sitzung für das zugehörige Konto zu unterscheiden.

Architektur des E-Mail-Bestätigungsprozesses — Architektur des E-Mail-Bestätigungsablaufs

Vorbereitung

Der Nutzer muss im selben Browserprofil bei seinem E-Mail-Anbieter oder Aussteller angemeldet sein. Wenn sie beispielsweise Gmail verwenden, müssen sie in ihrem Google-Konto angemeldet sein.
Als teilnehmende Prüfwebsite müssen Sie sich für den Ursprungstest registrieren und das Token auf derselben Seite wie Ihr E-Mail-Formular angeben.
Der Nutzer muss seine E-Mail-Adresse aus dem Drop-down-Menü für das automatische Ausfüllen oder die automatische Vervollständigung auswählen.
- Wenn der Nutzer zuvor eine E-Mail-Adresse in das Feld eingegeben hat, wird sie über die automatische Vervollständigung angeboten.
- Wenn der Nutzer seine E-Mail-Adresse über die Chrome-Einstellungen „Autofill und Passwort“ (chrome://settings/autofill) hinzugefügt hat, wird sie über Autofill angeboten.
  
  Hinweis :Die Unterstützung für manuell eingegebene Adressen ist für eine zukünftige Version geplant.
Wenn ein Nutzer zum ersten Mal eine E-Mail-Adresse zur Bestätigung angibt, wird er aufgefordert, eine Berechtigung zu erteilen. Das passiert nur einmal pro E‑Mail-Adresse.

Sobald der Nutzer eine aktive Sitzung in seinem Browser hat, kann er den Vorgang starten:

In einem Formular mit einem E-Mail-Feld wählt der Nutzer seine E-Mail-Adresse aus dem Drop-down-Menü für die automatische Vervollständigung aus. Die Verifizierungswebsite stellt ein verborgenes Feld im Formular mit einem instanzbezogenen Einmalcode zur Verfügung, um diese Anfrage zu validieren.
Der Browser ruft dann den DNS-Eintrag zur E-Mail-Bestätigung für die E-Mail-Domain ab. Dadurch wird der Browser zum Aussteller weitergeleitet. Der Aussteller bestätigt dann, dass er eine aktive Sitzung für diese E-Mail-Adresse hat.

Hinweis :Bei diesen Anfragen werden keine zusätzlichen Informationen zum Nutzer preisgegeben. Die Website des Prüfers erhält in diesem Schritt keine Informationen. Der Aussteller sieht nur eine Anfrage, um zu bestätigen, dass der Nutzer existiert. Er sieht nicht, von welcher Website die Anfrage stammt.
Der Aussteller stellt dann sein Email Verification Token (EVT) für die Adresse bereit. Der Browser kombiniert diese Informationen zu einem schlüsselgebundenen JWT mit dem EVT, dem Ursprung der Website und der Nonce aus dem Eingabeformular.
Wenn das Formular gesendet wird, wird das EVT-Paket dem verborgenen Feld hinzugefügt und an die Website gesendet.
Die Website des Prüfers überprüft dann jede dieser Angaben: die erwartete E‑Mail-Adresse, die Nonce sowie Signaturen des Browsers und des Ausstellers.
Der Nutzer sieht eine kleine Benachrichtigung, dass sein E-Mail-Anbieter seine Adresse bestätigt hat.

Durch diesen Vorgang wird der Website des Prüfers bestätigt, dass die E-Mail-Adresse gültig ist und dem aktuellen Nutzer gehört. Die Website kann also das Senden einer Bestätigungs-E-Mail überspringen.

Nutzer können ihre bestätigten E‑Mail-Adressen unter Einstellungen > Autofill und Passwörter > Kontaktdaten > Bestätigte E‑Mail-Adresse verwalten (oder chrome://settings/contactInfo öffnen).

Überlegungen zu Anwendungsfällen

Die E‑Mail-Bestätigung ist eine progressive Erweiterung Ihres bestehenden Ablaufs, bei der Nutzer Ihre Website nicht verlassen müssen, um ein Einmalkennwort abzurufen oder auf einen Link zu klicken. Websites können die Felder zur E-Mail-Bestätigung in alle relevanten Formulare einfügen, z. B. Anmeldungen, Newsletteranmeldungen, Kontoerstellungen und Passwortwiederherstellungen. EVP-Trigger werden nur ausgelöst, wenn der Browser sie unterstützt. Wenn bei der Einreichung kein Code empfangen wird oder einer der Validierungsschritte fehlschlägt, können Sie auf Ihren Standard-E‑Mail-Bestätigungsablauf zurückgreifen. Das bedeutet auch, dass es keine Funktionserkennung für die API gibt. Die Prüfstelle behandelt das EVT als optional und verarbeitet es, wenn es in der Anfrage vorhanden ist.

Bei der E-Mail-Bestätigung wird geprüft, ob der Nutzer eine aktive Sitzung beim Anbieter seiner E-Mail-Adresse hat. Es wird nicht überprüft, ob Ihre E‑Mail den Nutzer erreicht hat. Möglicherweise möchten Sie weiterhin vorhandene Begrüßungs- oder Onboarding-E-Mails senden und den Nutzer auffordern, seine Spameinstellungen zu überprüfen.

Prüfwebsite implementieren

Weitere Informationen finden Sie im End-to-End-Democode sowie in den Validierungsschritten in den Vorschlägen zur Email Verification API und zum Email Verification Protocol.

Formularfelder konfigurieren

Achten Sie darauf, dass Ihre Formularfelder die richtigen Attribute haben:

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

Legen Sie die Attribute type und autocomplete der email-Eingabe auf email fest, damit der Browser die E-Mail-Adresse automatisch vervollständigen kann.

Das neue Feld hidden wird beim Einreichen des Formulars mit dem E‑Mail-Bestätigungstoken gefüllt. Die erforderlichen Attribute sind:

Legen Sie type="hidden" fest, da für dieses Feld keine Nutzereingabe erforderlich ist.
Legen Sie dazu nonce="rAnD0m-VaLuE" fest. Die Website muss einen eindeutigen sitzungsgebundenen Nonce-Wert zur Verfügung stellen, um die Formulareinsendung zu bestätigen.
Legen Sie dazu autocomplete="email-verification-token" fest. Der Browser verwendet dieses Attribut, um das auszufüllende Feld zu identifizieren.

Prüfen Sie Ihre Formularelemente, indem Sie das Netzwerk-Panel in den Entwicklertools aufrufen. Wenn Sie eine E-Mail-Adresse auswählen, sehen Sie, wie der Browser die DNS- und nachfolgenden Kontoabfrageanfragen für den E-Mail-Anbieter und den Aussteller auslöst. Es handelt sich um interne Browseranfragen. Ihre Website erhält erst nach dem Senden des Formulars Daten.

EVT validieren

Es gibt fünf Schritte zum Validieren jeder Komponente des EVT-Pakets.

Parsen Sie das Token.
Erwartete Werte validieren
Prüfen Sie die Tastenzuweisung.
DNS-Eintrag validieren
den Aussteller ermitteln und die EVT-Signatur überprüfen.

1. Token parsen

Die Rohdaten aus der Formulareinsendung enthalten das EVT und die signierten Behauptungen in einem Selective Disclosure JSON Web Token (SD-JWT+KB), das durch eine Tilde (~) getrennt ist. Sie müssen diese trennen und die JOSE-Header (Javascript Object Signing and Encryption) und ‑Nutzlasten decodieren, z. B. mit jose für Node.js.

Wenn example.com demo@gmail.com bestätigt, sieht die decodierte Nutzlast in etwa so aus:

{
  "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. Erwartete Werte validieren

Prüfen Sie, ob die grundlegenden Werte in der Nutzlast mit den von Ihnen angegebenen Werten übereinstimmen:

Prüfen Sie, ob email_verified auf true gesetzt ist.
Prüfen Sie, ob email mit der E‑Mail-Adresse übereinstimmt, die Sie in Ihrem Formular angegeben haben.
Prüfen Sie, ob nonce mit dem in Ihrem Formular angegebenen Nonce übereinstimmt.
Prüfen Sie, ob aud mit dem Ursprung Ihrer Website übereinstimmt.
Prüfen Sie, ob iat einen relativ aktuellen Zeitstempel hat, z. B. nach dem Rendern des Formulars.

3. Tastenbelegung validieren

Der Browser erstellt einen temporären, kurzlebigen Schlüssel für die Transaktion, um zu bestätigen, dass er das Token signiert hat. Extrahieren Sie diesen Schlüssel aus dem cnf-Anspruch (Bestätigung) im EVT und verwenden Sie ihn dann, um das schlüsselgebundene JWT zu überprüfen.

Berechnen Sie dann den erwarteten Hash und vergleichen Sie ihn mit dem sd_hash-Anspruch. Das folgende Node.js-Beispiel zeigt, wie diese Berechnung durchgeführt wird:

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

4. DNS-Eintrag validieren

Bestätigen Sie den _email-verification-DNS-Eintrag für die Domain der E‑Mail-Adresse. Fragen Sie beispielsweise für demo@gmail.com den _email-verification.gmail.com-Eintrag TXT ab. Für diesen Anbieter gibt die Abfrage den Standort des Kontoanbieters zurück, also accounts.google.com.

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

5. Aussteller ermitteln und EVT-Signatur prüfen

Der Aussteller muss die /.well-known/email-verification-Ressource bereitstellen, die die Endpunkte für die Ausstellung des Tokens, den JSON Web Key (JWK) für die Website und die unterstützten Signaturalgorithmen enthält.

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

Verwenden Sie die JWKs, um das EVT-JWT zu überprüfen, das Sie aus dem Token extrahiert haben. Die meisten JOSE-Bibliotheken bieten Funktionen für diese Überprüfung.

Wenn alle fünf Schritte erfolgreich sind, haben Sie die E-Mail-Adresse beim Anbieter bestätigt. Andernfalls senden Sie dem Nutzer wie gewohnt eine Bestätigungs-E‑Mail.

E‑Mail-Anbieter- und Ausstellerservice implementieren

Weitere Informationen finden Sie im Democode für einen Mock-E-Mail-Anbieter und in den Schritten für Aussteller in den Vorschlägen für die Email Verification API und das Email Verification Protocol.

Als Aussteller müssen Sie sich nicht für den Ursprungstest registrieren oder ein Token angeben, da das Browserverhalten von der Website der vertrauenden Partei ausgelöst wird. Sie müssen nur dafür sorgen, dass die erwarteten Endpunkte vorhanden sind, um auf diese Anfragen zu reagieren.

Ausstellererkennung konfigurieren

Damit Browser Ihre Bestätigungsendpunkte automatisch erkennen können, wenn eine E-Mail-Adresse Ihrer Domain ausgewählt wird, müssen Sie Ihre Konfiguration über DNS und einen .well-known-HTTP-Endpunkt verfügbar machen.

DNS-Delegierungseintrag konfigurieren

Konfigurieren Sie einen DNS-TXT-Eintrag in Ihrer E‑Mail-Domain, der die Bestätigungsautorität an Ihre Aussteller-ID delegiert. Diese Kennungen können je nach Infrastruktur dieselbe Domain verwenden.

Eintragsformat: _email-verification.<email-domain>

Beispiel für eine Zonendatei:

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

`.well-known/email-verification`-Endpunkt hosten

Hosten Sie eine JSON-Metadatendatei in Ihrer Ausstellerdomain unter dem Pfad /.well-known/. In dieser Datei werden Ihre Ausstellungsfunktionen und die kryptografischen Signaturalgorithmen beschrieben, die von Ihrer Infrastruktur unterstützt werden.

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

Beispielantwort:

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

`.well-known/web-identity`-Endpunkt hosten

Eine zusätzliche .well-known-JSON-Ressource, die Sie möglicherweise bereits als Teil der API für föderierte Anmeldedaten (FedCM) implementiert haben. Hier finden Sie Links zum Endpunkt Ihres Kontos und zur Anmelde-URL.

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

Beispielantwort:

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

Kontenendpunkt verwenden

Der Kontenendpunkt der FedCM API bietet derzeit eine Liste der angemeldeten Konten. Das folgende Beispiel zeigt eine minimale Antwort. Weitere Informationen finden Sie im Implementierungsleitfaden für Identitätsanbieter.

Endpunkt: wie in .well-known/web-identity angegeben

Hier ist ein Beispiel für eine Antwort:

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

In die Login Status API einbinden

Der Nutzer muss eine aktive Sitzung mit dem Anbieter haben und Sie müssen dies dem Browser mit der Login Status API signalisieren.

Wenn sich ein Nutzer erfolgreich an- oder abmeldet, müssen Sie den entsprechenden HTTP-Antwortheader bereitstellen:

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

Alternativ können Sie den Status mit JavaScript in Ihrer Webanwendung aktualisieren:

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

Ausstellungsanträge bearbeiten

Ihr issuance_endpoint erhält eine application/x-www-form-urlencoded-POST-Anfrage mit dem request_token.

In den folgenden Abschnitten wird der gesamte Prozess der Bearbeitung von Ausstellungsanfragen beschrieben.

1. Ausstellungsantrag validieren

Eingehende Browser-Nutzlasten parsen und validieren:

Methode:POST
Sitzungsüberprüfung:Überprüfen Sie die eigenen session/authentication-Cookies des Nutzers, die zusammen mit der Anfrage übertragen werden, um sicherzustellen, dass ein aktiver, autorisierter Identitätskontext vorhanden ist.
Parameterüberprüfung:Extrahieren Sie den Parameter request_token (ein vom Browser generiertes signiertes JWT). Prüfen Sie, ob er den erwarteten temporären öffentlichen Schlüssel, die Ziel-E-Mail-Adresse, die richtige Zielgruppe und einen gültigen Zeitstempel enthält.

Das decodierte Token sollte in etwa so aussehen:

{
  "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. Mit einem Token antworten

Generieren Sie nach erfolgreicher Validierung des Sitzungs- und des Anfrage-Tokens ein signiertes SD-JWT (Selective Disclosure JWT) mit der Nutzlast:

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

Signieren Sie die Nutzlast mit Ihrem privaten Schlüssel und einem unterstützten Algorithmus. Beispiel für die Verwendung von jose 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}~`;

Beispiel für eine Erfolgsantwort (HTTP 200):

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

Hinweise zu Ursprungstests

Ursprungstests sind Experimente, bei denen Feedback gesammelt wird. Ihr Beitrag ist daher entscheidend, wenn Sie als vertrauende Partei oder Identitätsanbieter teilnehmen. Verwenden Sie die folgenden GitHub-Repositories, um Probleme zu melden:

Browser Email Verification API: WICG/email-verification
E‑Mail-Bestätigungsprotokoll: dickhardt/email-verification

Wenn Sie Fehler in der Chrome-Implementierung finden, melden Sie einen Fehler für die Komponente:

Neues Problem: Chromium > Blink > Identity > EVP

Die Aktivierung der Origin Trial-Funktionalität wird pro Antwort durch die Einbeziehung des OT-Tokens gesteuert. So können Sie die Funktion bei Bedarf auf einen Teil Ihrer Nutzer beschränken. Wenn Sie beispielsweise bereits ein A/B-Test-Framework haben, können Sie das Origin-Trial dort für eine kontrollierte Testgruppe einbinden. Alternativ können Sie die Funktion für eine Gruppe von Betatestern oder Early Preview-Nutzern aktivieren. In diesem Fall sollten Sie die angegebene E-Mail-Adresse prüfen, bevor Sie das Token ausstellen oder validieren.

Für Ursprungstests gelten auch Traffic-Limits, um zu verhindern, dass Websites vor der Einführung auf die Funktion angewiesen sind. Die Issuer API befindet sich in der Entwicklung. Sie sollten mit abwärtsinkompatiblen Änderungen und Updates der Chrome-Benutzeroberfläche rechnen.

Wir werden weitere Neuigkeiten im Blog und auf der Mailingliste evp-announce@chromium.org posten, sobald es Neuigkeiten gibt.