Zusammenfassung

  • Version 01 eines individuellen Internet-Drafts sagt nun klar: Deterministisches Rendern kann eine Abweichung zwischen signierter Aktion und behaupteter Darstellung erkennen, nicht aber die tatsächliche Anzeige eines nicht vertrauenswürdigen Bildschirms beweisen.
  • Belegprüfung und Prüfung der Darstellungsevidenz sind getrennte Ergebnisse. Weder ein gültiger Beleg noch eine gültige Anzeige-Bindung ist automatisch eine Autorisierung.
  • Daniel Kade schlägt einen Darstellungsentscheidungsnachweis vor, der beide Ergebnisse mit Schlüsselzuordnung, menschlicher Befugnis, Vertrauensankern und Restrisiko verbindet. Das ist redaktionelle Governance-Analyse, keine Vorgabe des Entwurfs.

Ein Schlüssel ist noch keine Person mit Mandat

Die Änderung beginnt an einer unscheinbaren Stelle. Version 01 sagt nicht mehr, eine benannte Person habe die nutzerbestätigte Signatur erzeugt. Sie schreibt diese Handlung einem registrierten Schlüssel zu. Genau das kann das kryptografische Verfahren belegen. Wer den Schlüssel führte, ob die Zuordnung noch gültig war und ob die Person für Betrag, Ziel und Zeitpunkt zuständig war, müssen andere Stellen nachweisen.

Auch die Aussage über den Bildschirm wurde enger. Der offizielle Vergleich ersetzt die Vorstellung, ein Prüfer könne beweisen, was dem Menschen gezeigt wurde. Nachweisbar ist nur, dass sich eine eingereichte Darstellung aus den signierten Aktionsdaten erneut ableiten lässt. Ein kompromittierter Client kann dem Prüfer korrekte Darstellungsbytes schicken und zugleich andere Pixel anzeigen.

Der Datatracker-Eintrag führt die am 12. September 2026 aktualisierte Fassung als aktiven individuellen Internet-Draft. Es gibt weder eine Working-Group-Zuordnung noch einen IETF-Stream, einen verantwortlichen Area Director oder einen eingetragenen angestrebten RFC-Status. Die Veröffentlichung ist kein IETF-Konsens und keine Standardisierung.

Reproduzierbarkeit schafft einen begrenzten Kontrollpunkt

Der vorgesehene Renderer ist eine reine Funktion der kanonischen Aktion. Gleiche Aktionen müssen auf jeder konformen Laufzeit, zu jeder Zeit und unabhängig von Umgebungsparametern dieselbe Bytefolge ergeben. Uhr, Zufall, externe Ein- und Ausgabe sowie die Umgebungssprache dürfen nicht einfließen. Das Profil schließt Feldmenge und Reihenfolge; RFC 8785 dient als Grundlage der JSON-Kanonisierung.

Damit wird eine wichtige Abweichung sichtbar. Wenn der signierte Betrag oder Empfänger nicht zur behaupteten Ansicht passt, scheitert die Neuberechnung. Bidirektionale Steuerzeichen, Kontrollzeichen, verwechslungsanfällige Zeichenfolgen und Überlängen müssen ebenfalls nach einer festgelegten Regel behandelt werden. Lässt sich ein Wert nicht sicher anzeigen, soll der Renderer abbrechen statt still zu kürzen.

Die Display-Attestation ist eine zusätzliche signierte Behauptung des Clients, die Darstellungs- und Aktionsdigest verbindet. Sie liegt neben dem Autorisierungsbeleg. Ihre Signatur zu prüfen bedeutet nicht, dem Client oder dem physischen Anzeigepfad zu vertrauen. Ein sauber signierter Client kann kompromittiert sein.

Die neue Ziffer 6.1 zieht daraus eine operative Regel. Beleg und Darstellungsevidenz müssen mit unabhängig ausgewählten Vertrauenseingaben bewertet werden. Ein gültiger Beleg darf nicht allein wegen seiner Signatur als akzeptierte Präsentation gelten; eine gültige Präsentationsbindung darf nicht allein deshalb zur Autorisierung werden.

Geschützte Hardware ist eine konkrete, keine magische Eigenschaft

Der Entwurf verweist auf Android Protected Confirmation als mögliches, gesondert zu profilierendes Verfahren, definiert dieses Profil aber nicht. Die offizielle ConfirmationPrompt-Dokumentation beschreibt, wie die vertrauende Stelle die attestierte Schlüsselverwendung, die Zertifikatskette, einen Nonce und den genauen bestätigten Prompttext prüft. Sie weist zugleich darauf hin, dass besondere Hardware erforderlich ist und die Funktion nicht immer verfügbar ist.

Darum reicht das Prüffeld „hardwaregestützt“ nicht. Festzuhalten sind die akzeptierte Wurzel, Aussagen der Schlüsselattestation, Frische, gebundener Text, tatsächlich darstellbare wesentliche Felder und der Ersatzweg bei Nichtverfügbarkeit. Der stille Rückfall auf einen gewöhnlichen Dialog verändert die Evidenzklasse und darf nicht als gleichwertig erscheinen.

Ähnlich begrenzt ist die Aussagekraft einer Referenzimplementierung. Negative Testvektoren können zeigen, dass ein bestimmter Renderer inkonsistente oder gefährliche Eingaben ablehnt. Sie beweisen keine unabhängige Prüfung, Verbreitung, Integrität eines Endgeräts oder menschliche Zuständigkeit. Version 01 beantragt keine IANA-Maßnahme; eine Registrierung der Kennungen ist Zukunftsarbeit.

Der lokale Beschluss braucht eine eigene Identität

Daniel Kade schlägt einen Darstellungsentscheidungsnachweis vor, den die Organisation führt, die die Folgen trägt. Er verknüpft Aktionsdigest, Belegprofil und Prüfergebnis; Rendererprofil, Version, Sprache, wesentliche Felder und Darstellungsdigest; Ergebnis der Display-Attestation; Client, Attestationskette, Vertrauenswurzel und Anzeigepfadklasse; Zuordnung des Schlüssels zur Person; Rolle, Mandatsgrenze und Gültigkeit; Restrisikoklasse; eigenständige Autorisierungsregel und Ergebnis; Prüfer, Zeit, Ablauf, Ablehnungs- oder Ersatzweg sowie Auslöser der Neubewertung.

Das ist kein weltweit gültiger Freigabeschein. Bei einer unwiderruflichen Zahlung kann eine Organisation einen geschützten Anzeigepfad plus Zweitbestätigung verlangen. Für eine reversible Wartungsänderung kann sie eine deterministische Darstellung und Vier-Augen-Prüfung akzeptieren. Gemeinsam ist nur die prüfbare Evidenz; die Schwelle bleibt dort, wo auch die Konsequenz getragen wird.

Heng Lus Minimum Initial Specification beschreibt genau diese Arbeitsteilung: eine kleine gemeinsame Fläche, ohne spätere Entscheidungen zu zentralisieren. The Policy Mirror verlangt, die tatsächliche Aussage jedes Akteurs in ihrer Reichweite zu bewahren. Why BTW Media Exists hält die Meldung nüchtern: Ein individueller Entwurf hat seine Behauptung korrigiert; Annahme, Einsatz und Sicherheitsnachweis sind nicht belegt.

Quellen

  1. Datatracker-Dokument
  2. Versionshistorie
  3. Datatracker-API
  4. Version 01
  5. Version 00
  6. Offizieller Vergleich
  7. Authorization Receipts
  8. Authorization Receipts Version 13
  9. RFC 8785
  10. Android ConfirmationPrompt
  11. Android Protected Confirmation
  12. Android Key Attestation
  13. The Policy Mirror
  14. Minimum Initial Specification
  15. Why BTW Media Exists