Zusammenfassung

  • Der vorgeschlagene Auftrag der Web Authentication Working Group umfasst das Signieren beliebiger Daten unter Vermittlung von WebAuthn. Dafür soll ein mit dem Credential verbundener, aber vom Authentifizierungsschlüssel getrennter Schlüssel dienen.
  • Der Text nennt agentische KI und überprüfbare digitale Nachweise, schließt den direkten Zugriff auf private Schlüssel und eigenständige allgemeine Kryptografie-APIs jenseits der aufgeführten Funktionen jedoch weiterhin aus.
  • Arbeitsumfang ist kein Reifegrad: Die Charta wird noch geprüft, Level 4 hat kein FPWD, der sign-Pull-Request ist ein Draft, und der Explainer nennt weder Nutzerforschung noch Signale von Chrome, Firefox, Safari oder Edge.
  • Ein öffentlicher Zulassungsnachweis je Funktion sollte die Chartaermächtigung mit genauer Entwurfsfassung, Schlüssel- und Nachrichtengrenzen, Aussagen über Einwilligung, Reviews, Tests, unabhängigen Implementierungen, Recommendation-Status und realer Einführung verbinden.

Eine Charta eröffnet Arbeit, sie nimmt kein Produkt ab

Die geltende Charta der Web Authentication Working Group hat einen klaren Schwerpunkt: starke Authentifizierung für Webanwendungen. Sie umfasst an Origins gebundene Schlüsselpaare, den Nachweis des Schlüsselbesitzes, Wiederherstellung, Backups und verwandte Verbesserungen. Direkter Zugriff auf kryptografische Operationen oder Schlüsselmaterial bleibt außerhalb des Auftrags. Eine Website kann eine Authentifizierungszeremonie anstoßen, erhält aber nicht den privaten Schlüssel aus dem Authenticator.

Der zur Prüfung stehende Nachfolger verschiebt diese Grenze. Punkt 11 erlaubt Arbeiten am Signieren weiterer Daten außerhalb der üblichen WebAuthn-Authentifizierungsstruktur. WebAuthn soll die Operation vermitteln; der Signierschlüssel soll mit dem Credential zusammenhängen, aber nicht dessen Authentifizierungsschlüssel sein. Agentische KI und Ökosysteme überprüfbarer digitaler Nachweise erscheinen als Beispiele. Zwei folgende Punkte betreffen Vertrauenssignale von Credential-Managern und die Vertraulichkeit von Extensions.

Das ist eine folgenreiche Wahl des Arbeitsraums. Eine Web-API, die konventionelle, für andere Kryptografieprotokolle verständliche Signaturen ausgibt, ist nicht bloß eine weitere Anmeldung. Wallets, Autorisierungstoken, Software-Release-Signaturen und andere Anwendungen könnten hardwaregeschützte Schlüssel nutzen, ohne den privaten Schlüssel an JavaScript herauszugeben.

Der derzeitige institutionelle Schritt ist trotzdem enger. Der W3C eröffnete die Prüfung am 10. August; Stellungnahmen sind bis zum 7. September um 23:59 UTC möglich. Die bestehende Charta wurde bis zum 30. Oktober verlängert. Zum Redaktionsschluss ist die Nachfolgerin nicht beschlossen. Auch eine Zustimmung würde nur sagen, dass die Working Group diese Klasse von Funktionen entwickeln darf. Sie wählt nicht automatisch die vorliegende API, beseitigt keine Risiken und verpflichtet keinen Browser zur Implementierung.

Der Entwurf selbst macht den Abstand sichtbar. Web Authentication Level 4 ist als künftiges normatives Arbeitsergebnis aufgeführt, doch ein First Public Working Draft fehlt, und als erwarteter Abschluss steht das vierte Quartal 2028. Einen Gegenstand in den Auftrag aufzunehmen und interoperablen Code auf Endgeräten auszuliefern sind verschiedene Ereignisse.

Eine gültige Signatur beweist nicht das Verständnis der Nachricht

WebAuthn erzeugt schon heute Signaturen. Eine normale Assertion signiert die Challenge der Relying Party aber nicht unverpackt. Der Authenticator signiert eine definierte Konstruktion aus Authenticator-Daten und dem Hash der Client-Daten. Der Raw-Signing-Entwurf zielt bewusst auf etwas anderes: eine Signatur über die unveränderte Eingabe der Anwendung.

Diese Allgemeinheit ist sein Nutzen. Viele bestehende Prüfer verstehen eine gewöhnliche kryptografische Signatur, nicht aber den Aufbau einer WebAuthn-Assertion. Eine herkömmliche Signatur über eine festgelegte Nachricht könnte Webanwendungen an solche Protokolle anbinden, während das Schlüsselgeheimnis in geschützter Hardware bleibt.

Der Vorschlag versucht zugleich, wichtige WebAuthn-Grenzen mitzunehmen. Der Signierschlüssel muss vom übergeordneten Credential-Schlüssel getrennt und kryptografisch unabhängig sein. Eine bösartige Relying Party soll die neue Operation nicht missbrauchen können, um eine gültige Authentifizierungs-Assertion herzustellen. Die Origin-Bindung soll verhindern, dass der Schlüssel zu einem websiteübergreifenden Identifier wird. Mindestanforderungen an User Presence und User Verification werden bei der Schlüsselerzeugung festgelegt.

Die Webschicht soll kein unbeaufsichtigtes Signieren anbieten, auch wenn die darunterliegende Client-to-Authenticator-Schicht nativen Anwendungen mit einem anderen Modell dienen kann.

Das sind substanzielle Zusagen. Sie beweisen nicht, dass ein Mensch den signierten Inhalt verstanden hat.

Der Explainer erklärt die Transaktionsbestätigung ausdrücklich zum Nicht-Ziel. Er rechnet mit undurchsichtigen Binärdaten und verlangt keine vertrauenswürdige Anzeige, die deren Bedeutung vor der Signatur verständlich macht. Eine erfolgreiche Zeremonie kann zeigen, dass ein bestimmter Schlüssel unter einer festgelegten Anwesenheits- oder Verifikationsregel eingesetzt wurde. Sie beweist allein weder, dass die Person ein Dokument gelesen oder eine Zahlung verstanden hat, noch dass sie die konkrete Auswahl eines autonomen Agenten oder die später zugeschriebene Rechtswirkung gebilligt hat.

Diese Grenze ist keine von außen hinzugefügte Kritik, sondern Teil der veröffentlichten Beschreibung. „Nutzer verifiziert“ ist eine Eigenschaft der Zeremonie. „Nutzer verstand diese Nutzlast“ ist eine andere Behauptung. „Nutzer ermächtigte den Agenten, diese Nutzlast auszuwählen“ ist eine dritte. Wer sie im Produkttext zusammenzieht, behauptet eine Autorität, die das Protokoll nicht belegt.

Die öffentliche Beweislage ist noch Inkubation

Der Raw-Signing-Explainer hält fest, dass keine Nutzerforschung stattgefunden hat. Seine Stakeholder-Tabelle enthält keine Signale von Chrome, Firefox, Safari oder Edge. Positiv vermerkt sind je ein Authenticator- und ein Relying-Party-Implementierer. Kein Signal ist keine Ablehnung. Es ist aber ebenso wenig stillschweigende Zustimmung, sondern ein offener Zustand.

Die sign-Erweiterung bleibt im Pull Request 2078 als Draft gekennzeichnet und dem Meilenstein für den ersten öffentlichen Level-4-Entwurf zugeordnet. Im September 2024 berichtete der Autor von groben internen Proof-of-Concept-Bausteinen und davon, dass damals keine Zusagen anderer Working-Group-Teilnehmer bestanden. Spätere Diskussionen und Versuche zeigen weitere Arbeit. In der geprüften Akte ersetzen sie keinen offenen Bericht über zwei unabhängige interoperable Implementierungen.

Der W3C Process liefert die notwendige Reihenfolge. Eine wesentliche Erweiterung des Auftrags erfordert die Prüfung durch das Advisory Committee und eine W3C Decision. Ein FPWD beginnt die öffentliche Standards-Arbeit und hat patentbezogene Folgen. Horizontale Reviews prüfen Barrierefreiheit, Internationalisierung, Datenschutz und Sicherheit. Candidate Recommendation dient der letzten Prüfung und dem Sammeln von Implementierungserfahrung. Für Recommendation braucht es weitere Nachweise und eine Entscheidung. Erst danach zeigt die Einführung, was Browser, Authenticatoren und Relying Parties tatsächlich betreiben.

Jede Stufe beantwortet eine andere Frage. Charta: Darf die Gruppe daran arbeiten? Entwurf: Gibt es ein prüfbares Design? FPWD: Hat die öffentliche Standards-Arbeit begonnen? Horizontales Review: Wurden Querschnittsrisiken untersucht? Offene Tests: Lassen sich Behauptungen einheitlich prüfen? Unabhängige Implementierungen: Funktioniert es außerhalb eines einzelnen Stacks? Recommendation: Hat der W3C-Prozess die Spezifikation bestätigt? Einführung: Nutzen laufende Systeme sie?

Heng Lus Argument für den Vorrang laufenden Codes ist genau an dieser Grenze hilfreich. Eine Veröffentlichung kann künftige Arbeit organisieren; sie macht eine spätere Änderung ohne Implementierung, Prüfung und freiwillige Übernahme nicht operativ real. Der W3C ist kein RIR, ein Webstandard kein Nummernressourcenregister. Übertragbar ist allein die Disziplin, Dokumentstatus, Implementierungsbelege und Nutzung nicht füreinander auszugeben.

Eine Funktion braucht einen fortlaufenden Zulassungsnachweis

Die vorgeschlagene Charta enthält allgemeine Erfolgskriterien. Raw Signing benötigt darüber hinaus eine funktionsbezogene Akte, weil seine Versprechen über mehrere Dokumente und Belegarten verteilt sind und leicht auseinanderdriften.

Der Nachweis sollte mit der einschlägigen Chartaklausel und ihrem Status beginnen und die genaue Fassung von Explainer und Spezifikation nennen. Er sollte festhalten, ob die vollständige Eingabe, ein Prehash oder ein anderes Envelope signiert wird, welche Algorithmuskennung gilt und wie Domain Separation erfolgt. Hinzu kommen die Beziehung zwischen Credential- und Signierschlüssel, Origin-Grenze, unveränderliche Presence- und Verification-Regeln und das, was die Person tatsächlich sieht.

Ebenso gehören die Aussagekraft von Attestation, Analysen zu Verknüpfbarkeit und Fingerprinting, Signale von Browsern, Authenticatoren und Relying Parties, horizontale Review-Fragen und ihre Erledigung, offene Tests, unabhängige Implementierungen, offene Einwände und der jeweilige Reifezustand dazu.

Private Schlüssel, Gerätekennungen, persönliche Testdaten oder ausnutzbare Implementierungsdetails dürfen darin nicht stehen. Der Nachweis ist auch kein neues Gremium mit zusätzlichem Vetorecht. Er ist ein versionierter öffentlicher Index auf Unterlagen, die der bestehende Prozess ohnehin hervorbringen sollte.

Sein Nutzen ist Korrigierbarkeit. Ändert sich die Charta, ändert sich die erste Zeile. Wird Transaktionsbestätigung später zum Ziel, bleibt die anfängliche Grenze sichtbar. Äußert ein Browser später Ablehnung, wird das frühere „kein Signal“ nicht rückwirkend zur historischen Opposition. Finden Tests eine Protokollverwechslung, bleiben Ergebnis und Abhilfe verbunden. Wird die Funktion aufgegeben, erhält sie einen lesbaren Endzustand, statt als alte Chartazeile zeitlos wie eine Produktfreigabe weiterzuleben.

Quellen

  1. W3C-Aufruf zur Prüfung der vorgeschlagenen Web-Authentication-Charta
  2. Vorgeschlagene Charta der Web Authentication Working Group
  3. Geltende Charta der Web Authentication Working Group
  4. Web Authentication Level 3 Recommendation
  5. Explainer zur Raw-Signing-Erweiterung
  6. Draft-Pull-Request sign 2078
  7. W3C Process Document vom 18. August 2025
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision and Voluntary Adoption