E‑Mail-Bestätigung – Updates im Oktober 2026

Rowan Merewood

Veröffentlicht am 5. Oktober 2026

Im Rahmen des laufenden Ursprungstests zur E‑Mail-Bestätigung haben wir basierend auf Ihrem Feedback weitere Änderungen vorgenommen. Wir gehen nicht davon aus, dass es weitere schwerwiegende Änderungen geben wird, und bereiten die Einführung des Features vor. Außerdem haben wir einen neuen Dokumentationsbereich für die E-Mail-Bestätigung mit eigenen Abschnitten für Bestätiger und Aussteller eingeführt.

Der Ursprungstest für die E‑Mail-Bestätigung wurde in Chrome 150 auf dem Computer gestartet. Auf Grundlage von Entwicklerfeedback und Tests im gesamten Ökosystem arbeiten wir weiter an der Implementierung. In diesem Beitrag werden Updates aus Chrome 154 behandelt, darunter Android-Unterstützung, Ursprungstests von Drittanbietern, die Verarbeitung der Schlüsselermittlung während der Tokenvalidierung und eine Header-Aktualisierung für E-Mail-Anbieter.

Für Nutzer sichtbare Änderungen

Änderungen an der Benutzeroberfläche oder am nutzerorientierten Verhalten

Unterstützung von Chrome für Android

Ab Chrome 154 unterstützt Chrome für Android die E‑Mail-Bestätigung. Prüfer oder Anbieter müssen keine Änderungen vornehmen, da die API oder das Protokoll unverändert bleibt. Es gelten dieselben Voraussetzungen, einschließlich der Anforderung, dass der Nutzer im Browser bei seinem E‑Mail-Anbieter angemeldet sein muss.

Nutzer können auf ihre Einstellungen unter Einstellungen > Adressen und mehr > Bestätigte E-Mail-Adresse zugreifen.

Updates für Prüfer

Änderungen für Websites, auf denen E‑Mail-Adressen erhoben und bestätigt werden

Drittanbieter-Ursprungstests

Ab Chrome 154 werden Testläufe für Drittanbieterursprünge für die E-Mail-Bestätigung unterstützt (siehe Problem 534377131). Wenn Sie ein eingebettetes Script oder ein Identity SDK bereitstellen, können Sie sich jetzt für ein Drittanbieter-Test-Token registrieren und es in Seiten einschleusen, auf denen Ihr Script gehostet wird. Für Websites, auf denen Ihr Script eingebettet ist, müssen keine separaten Ursprungstest-Tokens registriert werden.

Es gibt jedoch eine wichtige Einschränkung: Der Registrant des Ursprungstests und der Aussteller müssen Same-Site sein. Der für den Test registrierte Ursprung muss mit der Ausstellerdomain übereinstimmen.

Unterstützte Konfiguration:

  • Ausstellerdomain: issuer.example
  • OT-Registrant: https://issuer.example
  • JavaScript-Quelle: https://issuer.example (oder https://app.issuer.example mit Subdomain-Abgleich)

Nicht unterstützte Konfigurationen:

  • Registrant der Subdomain: Die Ausstellerdomain ist issuer.example, der OT-Registrant ist jedoch https://app.issuer.example.
  • Websiteübergreifender Registrant: Die Ausstellerdomain ist issuer.example, der OT-Registrant ist jedoch https://different.example.

Optionale kid in EVT verarbeiten

Beim Validieren des E-Mail-Bestätigungstokens (EVT) ruft Ihr Server den JSON Web Key Set (JWKS) des Anbieters ab, um die kryptografische Signatur des Ausstellers zu überprüfen. Die Schlüssel enthalten optional eine kid-Schlüsselkennung, die auch optional im JWT enthalten ist und angibt, welcher Schlüssel zum Signieren des Tokens verwendet wurde. Wenn das Token den kid-Anspruch nicht enthält (z. B. bei Gmail), durchlaufen Sie die Schlüssel, um den richtigen zu finden. In der Dokumentation und im Demo finden Sie den entsprechenden Code.

Der Anspruch email wird genau wie angegeben zurückgegeben.

Ab Chrome 156 wird die E-Mail-Adresse im Token genau so zurückgegeben, wie sie im Formular angegeben wurde (siehe Problem 549217427). Bisher haben Aussteller möglicherweise die kanonische E‑Mail-Adresse des Kontos zurückgegeben, z. B. First.Last@example.com, wenn die Formulareinsendung first.last@example.com enthielt. Es ist immer ratsam, einen nicht berücksichtigenden Vergleich der Groß- und Kleinschreibung für die zurückgegebene E‑Mail-Adresse zu verwenden. Daher sollte dies keine schwerwiegende Änderung sein.

Aktualisierungen für Gesundheitsdienstleister

Änderungen für E‑Mail-Anbieter.

Der Anspruch email wird genau wie angegeben zurückgegeben.

Auf Anbieterseite ist diese Anforderung strenger: Wenn der Anbieter die E‑Mail-Adresse nicht genau wie angegeben zurückgibt, lehnt Chrome das Token ab. So werden nicht mehr Daten offengelegt, als durch das Senden einer Bestätigungs-E-Mail. Prüfen Sie, ob die eingehende E‑Mail mit dem angemeldeten Nutzer übereinstimmt. Gehen Sie dabei genauso vor wie bei der E‑Mail-Zustellung.

Sec-Fetch-Dest wird in email-verification umbenannt

Ab Chrome 154 wird im Sec-Fetch-Dest-Header, der bei Anfragen zur Tokenausstellung gesendet wird, ein Bindestrich verwendet:

  • Chrome 154 und höher: Sec-Fetch-Dest: email-verification
  • Chrome 153: Sec-Fetch-Dest: emailverification

Durch diese Änderung wird der Bezeichner für das Abrufziel an die Benennungskonventionen der Webplattform angepasst (siehe Problem 546618576).

Wenn Ihr Ausstellungs-Endpunkt den Sec-Fetch-Dest-Header validiert (empfohlen, um sich vor CSRF und unbeabsichtigten Anfragekontexten zu schützen), aktualisieren Sie die Prüfung, um email-verification zu akzeptieren. Um Unterbrechungen während Browser-Rollouts zu vermeiden, sollten Sie während der Umstellung beide Werte akzeptieren.

Ressourcen und Feedback