Zusammenfassung

  • Die RVP-Fassung 03 ersetzt die bisher vorgeschriebene fünfstufige Kaskade und den addierten Vertrauenswert durch einen Nachweis für genau eine vorab fixierte Frage.
  • Ein altes Token, das nur eine Transport-Challenge signierte, darf nicht nachträglich als Signatur für den neuen Vorgang und dessen Ziel behandelt werden.

Ein erfolgreicher Prüfwert kann in einer Betriebsoberfläche eindeutig aussehen und im nächsten System etwas anderes bedeuten. Wurde die Anwesenheit eines Menschen festgestellt, ein Gerät bestätigt oder nur eine Netzwerk-Challenge beantwortet? Die am 29. September eingereichte RVP-Neufassung versucht nicht, diese Unterschiede in einer besseren Zahl zu verstecken. Sie verlegt den Beweis auf die vollständige Frage, die der Antwort zugrunde lag.

Die Vorgängerfassung 02 ging von fortlaufender Prüfung jeder Interaktion aus. Eine Kaskade aus fünf Methoden sollte Vertrauenswerte ansammeln und gegen eine Schwelle halten. Ob ein Vorgang tatsächlich gestoppt oder erlaubt wird, blieb allerdings schon dort Sache lokaler Regeln. Der neue Text erfindet diese Trennung also nicht. Er gibt die verpflichtende Kaskade und den portablen Summenwert auf und behandelt eine bestehende Sitzung, frische menschliche Anwesenheit, Gerätebindung, Wiederherstellungsstatus und Zulassung als verschiedene Tatsachen. Welche Kombination ausreicht, muss die Verbraucherrichtlinie festlegen.

Damit niemand die Bedingung nach Eingang des Ergebnisses verändert, erhält die Nachweisanforderung eine Kennung, eine unveränderliche Version und einen Digest ihrer kanonischen Form. Der Antrag benennt Vorgang, Ziel, betroffene Person, gegebenenfalls einen anderen Handelnden, Verbraucher, Zweck, Zeitfenster und Frist. Ein kryptografisches Commitment deckt dieses Gesamtpaket einschließlich Challenge ab. Mehrere Transportwege dürfen dieselbe Frage übermitteln, nicht je eine neue erfinden. Der Prüfer errechnet das Commitment aus seinem eigenen Antragsdatensatz erneut.

Im Migrationsanhang steht die unbequeme Folge. Token der ersten Generation dürfen als historische Belege aufbewahrt werden. Fordert eine Anforderung der zweiten Generation aber eine Bindung an Vorgang und Ziel, werden sie nicht akzeptiert. Fehlende Felder aus dem heutigen Datenbestand zu ergänzen und dann zu behaupten, der frühere Unterzeichner habe sie gebilligt, ist ausdrücklich ausgeschlossen. Ebenso unzulässig ist eine unbemerkte Rückstufung von der vollständigen Fragestellung auf eine alte, nur challenge-gebundene Antwort.

Eine passende Antwort hat darüber hinaus noch nichts freigegeben. match bezeichnet allein den Abschluss der Prüfbahn: Der Nachweis erfüllt die eingefrorene Bedingung. Erst wenn ein benannter Verbraucher ihn tatsächlich für einen konkreten Zweck und eine aktuelle Zielzustandsänderung verwendet, entsteht ein eigener bind. Vorher sind Frische und Zielzustand zu prüfen; gleichzeitige Verwendungen müssen koordiniert werden. Mehrere Verbraucher sind nur zulässig, wenn sie mit Zwecken und Umfang schon in der Anforderung stehen. Die Zulassung entscheidet weiterhin das Zielsystem.

Daniel Kade empfiehlt für eine Umstellung eine Übersicht über Token-Version, signierte Felder, Anforderungs-Digest, Vorgang, Ziel, Verbraucher, tatsächliche Nutzung und letztliche Zulassungsentscheidung. Das ist ein redaktioneller Kontrollvorschlag, keine im Draft festgelegte Vorlage. Er hält eine hohe alte Bewertung davon ab, zum angeblichen Einverständnis für einen neuen Vorgang aufzusteigen.

Der Datatracker führt Fassung 03 als aktiven individuellen Internet-Draft ohne RFC-Stream. Auch die beantragte Registrierung von application/rvp+json ist noch keine vollzogene Registrierung. Weder reale Verbreitung noch ein Angriff sind damit belegt. Fest steht die erhebliche Änderung des Vorschlags: Ein Nachweis soll an seiner ursprünglichen Frage enden.

Quellen