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

Rowan Merewood

Veröffentlicht am 8. Juli 2026, zuletzt aktualisiert am 5. Oktober 2026

Wenn Sie im Rahmen einer Registrierung, Anmeldung, eines Abos, einer Kaufabwicklung, 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 überprüft die E‑Mail-Adresse beim Anbieter, ohne eine E‑Mail zu senden oder den Nutzerfluss zu unterbrechen.

E-Mail Verification API – Demo für Nutzeraufforderung
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 hier folgen. Allgemeine Informationen zur Konfiguration von Ursprungstests finden Sie unter Erste Schritte mit Ursprungstests.

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

  • Die Ausstellerdemo bietet Ihnen ein Test-E‑Mail-Konto und eine Test-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 Prozess bei Verwendung des E‑Mail-Bestätigungsprotokolls abläuft.

Wichtige Begriffe

Wichtige Begriffe für die Email Verification API:

  • 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ätigungsprozesses

Vorbereitung

  • Der Nutzer muss in demselben 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 Website für die Bestätigung 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.

  • Wenn ein Nutzer zum ersten Mal eine E-Mail-Adresse zur Bestätigung angibt, wird er aufgefordert, eine Berechtigung zu erteilen. Dies geschieht nur einmal pro E‑Mail-Adresse.

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

  1. 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 Website des Prüfers stellt ein verborgenes Feld im Formular mit einem instanzspezifischen Nonce zur Verfügung, um diese Anfrage zu validieren.

  2. 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.

  3. Der Aussteller stellt dann sein Email Verification Token (EVT) für die Adresse bereit. Der Browser kombiniert diese Informationen in einem schlüsselgebundenen JWT mit dem EVT, dem Ursprung der Website und der Nonce aus dem Eingabeformular.

  4. Wenn das Formular gesendet wird, wird das EVT-Paket dem verborgenen Feld hinzugefügt und an die Website gesendet.

  5. Die Prüfwebsite prüft dann jede dieser Angaben: die erwartete E‑Mail-Adresse, die Nonce und die Signaturen des Browsers und des Ausstellers.

  6. Der Nutzer sieht eine kleine Benachrichtigung, dass sein E‑Mail-Anbieter seine Adresse bestätigt hat.

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

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. Nutzer müssen Ihre Website nicht mehr verlassen, um ein Einmalkennwort abzurufen oder auf einen Link zu klicken. Websites können die Felder für die E‑Mail-Bestätigung in alle relevanten Formulare einfügen, z. B. für 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üfwebsite behandelt das EVT als optional und verarbeitet es, wenn es in der Anfrage vorhanden ist.

Bei der E‑Mail-Bestätigung wird bestätigt, dass 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 Willkommens- 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 für die Email Verification API und das 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">

Setzen Sie die Attribute type und autocomplete der email-Eingabe auf email, damit der Browser die automatische Vervollständigung für die E-Mail-Adresse anbieten 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 zur Bestätigung der Formulareinsendung bereitstellen.
  • Legen Sie dazu autocomplete="email-verification-token" fest. Der Browser verwendet dieses Attribut, um das auszufüllende Feld zu identifizieren.

Prüfen Sie die 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 Konto-Lookup-Abfragen 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

Jede Komponente des EVT-Pakets wird in fünf Schritten validiert.

  1. Token parsen
  2. Erwartete Werte validieren
  3. Prüfen Sie die Tastenbelegung.
  4. DNS-Eintrag validieren
  5. 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 festgelegt 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-Datensatz 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 überprü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. Falls nicht, 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 E‑Mail-Bestätigungs-API und das E‑Mail-Bestätigungsprotokoll.

Als Aussteller müssen Sie sich nicht für den Ursprungstest registrieren oder ein Token bereitstellen, 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.

Aufzeichnungsformat: _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 im Rahmen der Federated Credentials (FedCM) API implementiert haben. Hier finden Sie Links zu Ihrem Kontoendpunkt und Ihrer 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 auch mit JavaScript im Kontext 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 Anfragetokens 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...~"
}

Überlegungen 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:

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

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

Für Ursprungstests gelten auch Traffic-Limits, um die Anzahl der Websites zu minimieren, die 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 hier im Blog und auf der Mailingliste evp-announce@chromium.org über die Fortschritte bei der Entwicklung berichten.