Aktualisierungen der E‑Mail-Bestätigung, August 2026

Rowan Merewood

Veröffentlicht am 13. August 2026, zuletzt aktualisiert am 5. Oktober 2026

Der Ursprungstest für die E‑Mail-Bestätigung wurde in Chrome 150 gestartet. Auf Grundlage Ihres Feedbacks haben wir einige Fehler behoben und Verbesserungen vorgenommen. In diesem Beitrag finden Sie eine Übersicht über die Änderungen und die Maßnahmen, die Sie auf Ihrer Website oder in Ihrem Dienst ergreifen sollten.

Zuerst eine Zusammenfassung der E‑Mail-Bestätigungsfunktion (weitere Informationen finden Sie in der früheren Ankündigung). Auf vielen Websites muss der Nutzer bei der Registrierung, Anmeldung, Kontowiederherstellung usw. eine E‑Mail-Adresse eingeben und dann in seinem E‑Mail-Posteingang auf einen Magic Link klicken oder ein Einmalkennwort abrufen. Die E‑Mail-Bestätigung bietet eine progressive Verbesserung, da die E‑Mail-Adresse direkt im Browser beim Anbieter bestätigt wird. Die Website erhält dann ein Token vom Browser, das sie beim E‑Mail-Anbieter validieren kann, sodass die E‑Mail gar nicht erst gesendet werden muss.

Für Nutzer sichtbare Änderungen

Änderungen an der Benutzeroberfläche oder am nutzerorientierten Verhalten

E‑Mail-Eingabe

Bisher mussten Nutzer die automatische Vervollständigung oder Autofill verwenden, um eine E‑Mail-Adresse einzugeben. Wenn Sie jetzt eine E-Mail-Adresse auf irgendeine Weise in das Feld eingeben (z. B. durch Tippen oder Einfügen), wird der Bestätigungsprozess ausgelöst, sobald der Nutzer das input-Element verlässt, ähnlich wie bei einem change-Ereignis. Das bedeutet, dass die E‑Mail-Bestätigung bei jeder Eingabe einer E‑Mail-Adresse ausgelöst werden sollte.

Fortschrittsanzeige

Außerdem testen wir in Chrome 152 und höher eine Fortschrittsanzeige für den Bestätigungsprozess. Der Bestätigungsprozess ist zwar schnell, aber es ist trotzdem möglich, dass ein Nutzer das Formular sendet, bevor der Prozess abgeschlossen ist. Die Fortschrittsanzeige zeigt während der Überprüfung einen Spinner und nach Abschluss ein Häkchen am Ende des Eingabefelds (rechts für eine LTR-Sprache).

Wenn dadurch Probleme auftreten oder Sie unerwartetes Verhalten feststellen, melden Sie einen Fehler.

Nur auf Computern

Die E‑Mail-Bestätigung ist nur auf dem Computer bis Chrome 152 verfügbar. Wir arbeiten daran, die Funktion auch auf Android-Geräten verfügbar zu machen, und werden Sie hier auf dem Laufenden halten.

Updates für Prüfer

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

Tokenvalidierung

Das E-Mail-Bestätigungstoken wird im Format Selective Disclosure for JSON Web Tokens (SD-JWT) bereitgestellt. In seiner Rohform sieht das so aus: ein vom Aussteller signiertes JWT, gefolgt von null oder mehr Offenlegungen und einem Key Binding JWT. Die einzelnen Komponenten sind durch eine Tilde getrennt:

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

Das E-Mail-Bestätigungstoken in seiner aktuellen Form gibt nur das vom Aussteller signierte JWT und das Key Binding JWT ohne Offenlegungen zurück. Im ursprünglichen Blogpost und in der ersten Iteration der Demo wurde das Token einfach in zwei Teile aufgeteilt und die beiden JWTs wurden geparst. Das ist nicht stabil und würde nicht mehr funktionieren, wenn in Zukunft selektive Offenlegungen hinzugefügt werden.

Anstatt sich auf diese Funktion des aktuellen Vorschlags zu verlassen, sollten Sie dafür sorgen, dass Ihre Implementierung das SD-JWT-Token gemäß seiner Spezifikation korrekt parst. Verwenden Sie dazu idealerweise Bibliotheken für Ihre Plattform. Beispielsweise wird beim Demobestätigungscode jetzt @sd-jwt/core verwendet, um das Token zu parsen und die Schlüsselbindung (Zielgruppe, Nonce und Hash) zu validieren, und dann jose, um die Signaturen für das EVT des Ausstellers und das Key Binding JWT des Browsers zu überprüfen.

Drittanbieter-Ursprungstests

Testläufe von Drittanbietern werden seit August nicht mehr für die E‑Mail-Bestätigung unterstützt. Mit Drittanbieter-Ursprungstests kann ein Drittanbieter-Ursprung die Testfunktion auf einer Website aktivieren, auf der er enthalten ist, z. B. eine Cross-Origin-JavaScript-Abhängigkeit. Wenn dies für Ihren Anwendungsfall Priorität hat, kommentieren Sie den Tracking-Fehler oder folgen Sie ihm.

E-Mail-Vergleich ohne Berücksichtigung der Groß-/Kleinschreibung

E-Mail-Anbieter geben möglicherweise die kanonische E-Mail-Adresse mit Großbuchstaben zurück, z. B. Demo.User@example.com, auch wenn im Formular demo.user@example.com angegeben wurde. Achten Sie darauf, dass Sie einen Vergleich durchführen, bei dem die Groß- und Kleinschreibung der empfangenen E‑Mail-Adresse keine Rolle spielt. Außerdem haben wir einen Fehler auf der Seite „Einstellungen“ behoben, bei dem möglicherweise verschiedene Schreibweisen derselben E‑Mail-Adresse angezeigt wurden, die sich nur in der Groß- und Kleinschreibung unterschieden.

Aktualisierungen für Gesundheitsdienstleister

Änderungen für E‑Mail-Anbieter.

HTTP-Nachrichtensignatur für Ausstellungsanfragen

In Chrome 153 führen wir eine wichtige Änderung ein. Bei der Ausstellung von HTTP Message Signatures wird in der Ausstellungsanfrage nur noch die email im application/json-Format gesendet.

  • Chrome 152 und früher: Der Ausstellungs-Endpunkt empfängt eine application/x-www-form-urlencoded-Anfrage vom Typ POST mit dem request_token im Text.
  • Chrome 153 und höher: Der Inhaltstyp wird mit den Headern Signature, Signature-Input und Signature-Key zu application/json geändert. Der Body enthält nur den Schlüssel email.

Je nach Ihrem aktuellen Traffic und Ihren Testzielen haben Sie folgende Möglichkeiten:

  • Unterstützt beide Formate und wechselt je nach Inhaltstyp. Sobald Chrome 153 Ende August die stabile Version erreicht, können Sie Ihren Traffic analysieren, um die Legacy-Funktion zu entfernen.
  • Wechseln Sie einfach zum neuen Format. Die Bestätigung schlägt dann für Nutzer mit älteren Chrome-Versionen fehl.

Der Ausstellungs-Endpunkt im Democode wurde aktualisiert, um beide Abläufe mit structured-headers und http-message-sig zu verarbeiten.

Vollständiges Anfrageformat:

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

Das Antwortformat bleibt gleich: ein issuance_token in einem application/json-Text.

Sie können sich die Vorschlags-Repositories WICG/email-verification und dickhardt/email-verification ansehen und dort zusätzliches Feedback geben. Das Feedback der Community war bisher sehr hilfreich. Wir werden also auch in Zukunft Updates und Verbesserungen vornehmen.