Zusammenfassung

  • Das W3C veröffentlichte Web Authentication Level 3 am 25. August 2026 als Recommendation und verknüpfte einen festen Implementierungsbericht vom 26. Juni.
  • Der Bericht nennt 53 Tests und 415 Untertests für konkrete Builds von Chrome, Firefox, Safari Preview und Edge, jeweils mit Umgebung, Datum und demselben WPT-Commit.
  • Das Übergangsdossier sagt nur, ein Teil von Chrome unterscheide sich von Edge. Ein funktionsbezogener Schlüssel sollte Implementierungsschicht, Unabhängigkeitsgrund, Ergebnis und Entscheidungsbezug zusammenführen.

Präzise Testherkunft, offene Implementierungsherkunft

Web Authentication: An API for accessing Public Key Credentials — Level 3 beschreibt eine Schnittstelle, über die Webanwendungen auf eine Relying Party begrenzte Public-Key-Zugangsdaten erstellen und verwenden. User Agent und Authenticator vermitteln den Vorgang. Die Fassung vom 25. August ist eine W3C Recommendation, empfiehlt breite Bereitstellung und vermerkt, dass es seit dem Candidate Recommendation Snapshot vom 26. Mai keine substanziellen Änderungen gab.

In den Dokumentangaben steht ein fester Implementation Report. Er bezeichnet sich als Momentaufnahme vom 26. Juni, wird nicht fortgeschrieben und verweist für aktuelle Ergebnisse auf den Live-Dienst. Für /webauthn/ weist er 53 Tests und 415 Untertests aus.

Die Laufumgebungen sind sauber dokumentiert. Chrome 151 und Firefox 154 alpha liefen am 25. Juni unter Linux. Safari 246 Preview lief am folgenden Tag unter macOS, Edge 151 unter Windows. Alle vier Datensätze verwenden den WPT-Commit d41367df1e. Die Matrix bewahrt PASS, FAIL, TIMEOUT, ERROR, NOTRUN und fehlende Resultate.

Damit lässt sich eine wichtige Frage beantworten: Was beobachtete dieser Produkt-Build in dieser Umgebung gegenüber dieser Testrevision? Die Spalten beantworten jedoch nicht automatisch die andere Frage des W3C Process: Welche Resultate stammen aus unabhängigen, interoperablen Implementierungen einer Funktion?

Vier Produktnamen sind keine sichere Zählung. Ebenso wenig lässt sich Chrome und Edge für jede Funktion pauschal eine einzige Implementierung zuschreiben. Ein Browserprodukt kann Engine, Betriebssystemdienste, Plattform-Authenticator und anbieterspezifische Komponenten verbinden. Für eine Funktion kann der maßgebliche Pfad gemeinsam sein, für eine andere getrennt. Unabhängigkeit braucht daher Funktion und Schicht als Bezugsgröße.

Aus einer konkreten Diskussion wurde „ein Teil“

Der endgültige Übergangsantrag verlinkt unter „Implementation“ die laufenden WPT-Ergebnisse und die feste Momentaufnahme. Direkt danach folgt der Satz, ein Teil der Implementierung in Chrome sei anders als in Edge.

Diese Einschränkung ist sinnvoll. Sie verhindert, dass beide Spalten allein wegen gemeinsamer Grundlagen vollständig zusammengelegt werden. Doch sie benennt weder Teil noch Funktion, Testgruppe oder Komponentengrenze. Eine Quelle für die Einstufung fehlt ebenso wie die Angabe, ob ein bestimmtes Chrome-Edge-Paar als unabhängiger Nachweis für eine konkrete Übergangsaussage diente.

Das Protokoll der Working Group vom 18. März enthält mehr Auflösung. Im Abschnitt „Testing“ werden technische Unterschiede von Edge gegenüber „normal Chrome“ erwähnt. Anschließend fragt die Runde, ob Microsoft Authenticator über Android oder iOS arbeitet, und beschreibt diese Wege für eine Erweiterung als zwei Implementierungen auf der WebAuthn-Schicht. Später hält das Protokoll den Konsens fest, nach Erledigung offener Punkte die Recommendation zu beantragen; Widerspruch ist nicht verzeichnet.

Die Working Group hat die Frage also nicht übersehen. Sie diskutierte Schichten. Beim Übergang in den öffentlichen Entscheidungsbeleg wurde diese Überlegung verdichtet: Aus Erweiterung und Schicht wurde ein unbestimmter „Teil“. Testmatrix und Herkunftsaussage stehen nebeneinander, sind aber nicht zeilenweise verbunden.

Der Beschlussweg ist abgeschlossen. Das issue dokumentiert die Team-Genehmigung am 17. Juli, den Abschluss der Advisory-Committee-Prüfung am 18. August mit Konsens und ohne Formal Objections, die Publikationsfreigabe am 19. August und die feste Recommendation am 25. August. Fehlende öffentliche Granularität hebt diese Akte nicht auf und beweist nicht, dass dem Team weitere Belege fehlten.

Der Process kennt keine Browserarithmetik

Abschnitt 6.3.2 vermeidet bewusst eine starre Formel. Implementierungserfahrung soll zeigen, dass eine Spezifikation klar, vollständig und marktgerecht genug ist, um unabhängige interoperable Implementierungen jeder Funktion zu ermöglichen. Das Team kann unter anderem fragen, ob jede Funktion implementiert ist, ob die Implementierungen unabhängig sind, ob andere als die Spezifikationsautoren sie gebaut haben, ob sie öffentlich eingesetzt werden, ob Erfahrung auf mehreren Ebenen vorliegt und ob Schwierigkeiten gemeldet wurden.

Ein PASS-Feld belegt beobachtetes Verhalten. Ohne zusätzliche Herkunftsdaten belegt es weder Autoren- noch Codepfad-Unabhängigkeit. Ein anderes Betriebssystem kann für eine Plattformfunktion entscheidend und für eine andere Funktion belanglos sein. Der gemeinsame WPT-Commit verbessert die Vergleichbarkeit, beschreibt aber nicht die Abstammung der getesteten Software.

Gemischte Resultate sind auch keine Sicherheitsrangliste. Ein FAIL kann fehlende Unterstützung, eine andere Umsetzung oder eine zu prüfende Testerwartung anzeigen. TIMEOUT und fehlende Resultate sagen noch weniger. Der Recommendation-Übergang verlangt nicht, dass jedes Feld jedes Produkts grün ist; dieser Beitrag erfindet eine solche Schranke nicht.

Ein begrenzter Schlüssel pro Funktion

Die Ergänzung kann knapp bleiben. Für jede als Beleg verwendete Funktion oder Testgruppe nennt eine Zeile die feste Spezifikationsfassung, den Test-Commit, Produkt und Build sowie die maßgebliche Implementierungsschicht. Hinzu kommt eine begrenzte Unabhängigkeitsaussage mit öffentlicher Architekturquelle oder einer zurechenbaren Bestätigung, wenn Details vertraulich bleiben müssen.

Dieselbe Zeile enthält die Interoperabilitätsbeobachtung und sagt, ob sie in die Übergangsentscheidung einging. Nutzen Chrome und Edge bei einer Erweiterung unterschiedliche Pfade, gilt die Aussage für diese Erweiterung. Teilen sie bei einer anderen Funktion den relevanten Pfad, werden zwei Spalten nicht stillschweigend zu zwei unabhängigen Implementierungen. Firefox, Safari, Android, iOS, Authenticatoren und Relying-Party-Software werden nach derselben funktionsbezogenen Regel behandelt.

Der Schlüssel ist weder Quellcodeprüfung noch neue Genehmigungsinstanz. Das W3C Team behält das kontextbezogene Urteil, das ihm der Process zuweist. Getrennt werden lediglich drei Aussagen: wo der Test lief, welches Verhalten beobachtet wurde und warum die Implementierung für einen bezeichneten Zweck als unabhängig zählt.

Lu Heng ordnet eine Recommendation in Minimum Initial Specification als Koordinationsartefakt ein; Implementierung, Validierung, Bereitstellung und Annahme bleiben eigenständige Tatsachen. Diese Zurückhaltung gilt auch für die vorgelagerte Evidenz. Der Browsername bezeichnet das geprüfte Produkt, nicht automatisch seine Implementierungslinie.

Quellen