Zusammenfassung

  • remoteClientDataJSON ist standardmäßig gesperrt und erfordert eine Freigabe je Origin. Diese lokale Erlaubnis beweist nicht, dass der Remote-Client die entfernte Origin und die RP ID korrekt geprüft hat.
  • Sinnvoll ist ein sitzungs-, richtlinien- und hashgebundener Beleg über die Clientgrenze hinweg, ohne die gesamte Remote-Prüfung im lokalen Browser zu duplizieren.

Im First Public Working Draft von Web Authentication Level 4 vom 15. September 2026 geht es an einer entscheidenden Stelle nicht um einen neuen kryptografischen Baustein, sondern um die Verlagerung einer Prüfverantwortung.

Im normalen WebAuthn-Ablauf leitet der Browser die aufrufende Origin aus seinem eigenen Ausführungskontext ab. Die RP ID muss grundsätzlich der effektiven Domain entsprechen oder ein registrierbares Domain-Suffix davon sein; für verwandte Origins gibt es ein gesondertes Verfahren. Der Browser erzeugt clientDataJSON, der Authenticator signiert dessen Hash, und der Relying Party prüft Zeremonietyp, Challenge, erwartete Origin und RP-ID-Hash.

Ein webbasierter Remote Desktop trennt diese Orte. Die anfordernde Website läuft auf dem entfernten Host, der Authenticator befindet sich am lokalen Gerät. Baut der lokale Browser die Clientdaten aus seinem eigenen Kontext neu auf, enthält das Ergebnis die Origin des Remote-Desktop-Webclients statt der Origin der Anwendung in der entfernten Sitzung. Schon eine andere Feldreihenfolge, optionale Angaben oder Leerzeichen im JSON verändern die Bytes und damit den Hash.

Die Erweiterung remoteClientDataJSON lässt einen autorisierten Remote-Desktop-Client die vollständige Zeichenfolge des entfernten Hosts an den lokalen Browser übergeben. Der Browser parst sie, darf ihren Inhalt aber weder ergänzen noch entfernen oder verändern. Beim Serialisieren übernimmt er die gelieferte Zeichenfolge, damit der Authenticator genau die Bytes signiert, die der entfernte Rechner erwartet.

Der Entwurf macht daraus keinen offenen Umgehungspfad. publickey-credentials-remote-client-data-json ist sowohl ein mächtiges als auch ein durch Permissions Policy kontrolliertes Feature. Der Standardzustand der Berechtigung lautet denied; als Standard-Allowlist nennt der Text 'none'. Die Konfiguration muss originbezogen sein, eine pauschale Freigabe für alle Origins ist untersagt. Vorgesehen sind verwaltete Browser- oder Geräterichtlinien beziehungsweise eine ausdrückliche Auswahl je Origin in den Clienteinstellungen, nicht eine beiläufige Nachfrage während der Anmeldung.

Diese Schranke beantwortet eine lokale Frage: Darf die aufrufende Origin die Erweiterung benutzen? Sie beantwortet nicht die entfernte Frage: Hat der Remote-Client die tatsächliche Origin des RP korrekt angegeben und die Beziehung zur RP ID nach der richtigen Regel bewertet?

Der Algorithmus zieht die Grenze ausdrücklich. Ohne den Zustand granted lehnt der lokale Browser den Vorgang ab. Eine RP ID muss explizit vorhanden sein, und das entfernte JSON wird geparst. Anschließend überspringt der lokale Client jedoch die normale Prüfung zwischen RP ID und dem Wert origin in diesen Daten. Der Entwurf sagt, sämtliche originbezogenen RP-ID-Prüfungen würden an den Remote-Client delegiert. In den Sicherheitshinweisen steht entsprechend, dass ein freigebender User Agent darauf vertrauen muss, dass der Aufrufer die Remote-Origin wahrheitsgemäß liefert und der Remote-Client die RP ID korrekt validiert.

Das boolesche Erweiterungsergebnis erweitert diese Aussage nicht. true bedeutet, dass die Erweiterung angewendet wurde. Es nennt weder Remote-Sitzung noch Richtlinienversion, Prüfmethode, Ergebnis oder Nachweis für verwandte Origins. Auch die Byte-Treue hat eine enge Bedeutung: Sie zeigt, dass der lokale Browser die Daten nicht rekonstruiert hat. Sie zeigt nicht, dass die darin enthaltene Origin-Angabe wahr, aktuell und autorisiert war.

Die Authenticator-Signatur bindet das Ergebnis an den Clientdaten-Hash und die Authenticator-Daten. Der RP muss weiterhin Typ, Challenge und Origin prüfen sowie rpIdHash mit der erwarteten RP ID vergleichen. Diese Kontrollen sind unverzichtbar. Sie halten aber nicht zwangsläufig fest, welcher Remote-Client die delegierte Entscheidung getroffen hat, welche Richtlinienversion galt und über welchen authentisierten Kanal die lokale Operation zur Remote-Sitzung gehörte.

Das ist keine Behauptung über eine Schwachstelle, einen Exploit oder einen Vorfall. Level 4 liegt als erster öffentlicher Arbeitsentwurf vor, nicht als W3C Recommendation und nicht als Beleg für Implementierung, Interoperabilität oder Produktionseinsatz. Der Statusabschnitt sagt ausdrücklich, die Veröffentlichung bedeute keine Billigung und der Entwurf könne geändert, ersetzt oder obsolet werden. Issue 2430 im W3C-WebAuthn-Repository verfolgt zudem eine terminologische Abhängigkeit: Die beabsichtigte Standardsperre ist klar, doch 'none' war im abhängigen Permissions-Policy-Entwurf noch nicht als normativer Standard-Allowlist-Wert definiert. Das Issue verlangt keine Verhaltensänderung.

Die Governance-Antwort sollte die Delegation daher nicht rückgängig machen. Die entfernte Seite kann Kontext besitzen, der lokal fehlt: Dokumente für verwandte Origins oder plattformspezifische App-Zuordnungen. Müsste der lokale Browser die gesamte Prüfung nachbilden, entstünden zwei Validatoren, deren Regeln unbemerkt auseinanderlaufen können.

Der engere Eingriff ist ein Origin-Validierungsbeleg über die Clientgrenze. Er sollte die lokale Aufrufer-Origin und die Freigabe — Subjekt, Quelle, Version und Ablauf — mit der Remote-Sitzung und ihrem authentisierten Kanal verbinden. Festgehalten werden Remote-Origin, RP ID, Prüfalgorithmus und Version, Ergebnis sowie Verweise auf Related-Origin- oder App-Zuordnungsnachweise. Ein Hash der exakten remoteClientDataJSON-Bytes bindet die Entscheidung an die signierten Daten; das Validierungsergebnis des RP-Servers schließt die Kette. Ausnahmen, Widerrufe und Korrekturen werden angehängt statt überschrieben.

Dieser Beleg ist ein vorgeschlagenes Betriebskontrollmittel, keine hier behauptete WebAuthn-Pflicht. Er trennt fünf Tatsachen: lokale Fähigkeit freigegeben, Remote-Prüfung ausgeführt, Bytes erhalten, Nutzerhandlung am Authenticator erfolgt, RP-Ergebnis akzeptiert oder abgelehnt. Ein einzelnes grünes WebAuthn-Signal beweist nicht alle fünf.

Quellen