Zusammenfassung

  • Revision 11 von draft-ietf-oauth-attestation-based-client-auth erschien am 3. September 2026. Am 8. September startete die OAuth Working Group ihre Last Call mit Frist bis zum 22. September.
  • Server-Challenges sind optional. Lebensdauer und Einmal- oder Mehrfachnutzung bestimmt ausschließlich die lokale Server-Policy. Der Client muss den neuesten Wert verwenden, darf ihn aber wiederverwenden.
  • Ein Single-Use-Server weist den zweiten Versuch mit use_attestation_challenge zurück, liefert einen neuen Wert und erwartet höchstens einen erneuten Versuch. Der kombinierte DPoP-Modus nutzt stattdessen den Nonce-Pfad aus RFC 9449.
  • Neue Metadaten machen Methoden und Algorithmen sichtbar, nicht die Verbrauchsregel. Daniel Kade schlägt eine Freshness-Policy im Deployment-Profil vor; sie ist redaktionelle Analyse und keine IETF-Vorgabe.

Die Last Call prüft einen Entwurf

Die Mitteilung der OAuth Working Group fordert bis zum 22. September Unterstützung oder begründete Einwände an. Der Datatracker-Eintrag führt Revision 11 als aktuellen WG Draft „In WG Last Call“. Das ist ein institutioneller Prüfschritt, weder ein veröffentlichter RFC noch eine bereits festgestellte IETF-weite Einigung.

Das Verfahren authentisiert eine konkrete Softwareinstanz. Ein Client Attester signiert ein Client Attestation JWT, das seine Aussage an den öffentlichen Schlüssel dieser Installation bindet. Gegenüber Autorisierungsserver oder geschützter Ressource beweist die Instanz zusätzlich, dass sie den zugehörigen privaten Schlüssel tatsächlich besitzt. Attestierung und Besitznachweis beantworten damit zwei getrennte Fragen.

Im Normalmodus ist der Besitznachweis ein Client Attestation PoP JWT. Er enthält Erstellungszeit und eine eindeutige jti. Der Server kann außerdem eine eigene, für den Client undurchsichtige Challenge vorgeben. Sie kann aus einer Fehlerantwort, einer früheren regulären Antwort oder einem veröffentlichten Challenge Endpoint stammen. Sobald eine vorliegt, muss der Client stets die zuletzt empfangene verwenden.

Revision 11 legt weder eine gemeinsame Gültigkeitsdauer noch eine gemeinsame Verbrauchsregel fest. Ob dieselbe Challenge in mehreren PoP JWTs vorkommen darf, entscheidet allein die lokale Policy von Autorisierungsserver oder Ressource. Der Client darf wiederverwenden; ein Server, der nur einen Einsatz akzeptiert, darf die zweite Verwendung ablehnen.

Beide Varianten haben plausible Gründe. Single Use engt das Zeitfenster ein, verlangt aber Zustand und Koordination bei parallelen Anfragen. Kurze Wiederverwendung passt besser zu verteilten Clients, sofern jti oder ein anderes Verfahren die erneute Übertragung desselben Nachweises erkennt. Nicht die Wahlfreiheit erzeugt das Interoperabilitätsproblem, sondern die Tatsache, dass der opake Wert keine Auskunft über die getroffene Wahl gibt.

Der erste Fehler dient als Policy-Abfrage

Nach einer Abweichung ist der Ablauf präzise. Der Autorisierungsserver antwortet mit HTTP 400 und use_attestation_challenge, die geschützte Ressource mit HTTP 401 im Authentisierungsrahmen. Beide müssen eine neue OAuth-Client-Attestation-Challenge mitsenden. Der Client soll damit einen neuen Nachweis erstellen und einmal wiederholen; eine Endlosschleife ist verboten.

Die Grenze verhindert einen ungebremsten Retry. Sie vermeidet nicht den ersten Fehler, der die Regel enthüllt. Ein Dienst könnte eine Challenge vorsorglich abrufen und auf mehrere Prozesse für parallele Token-Anfragen verteilen. Ein Reuse-Server akzeptiert mehrere Nachweise mit jeweils neuer jti. Bei Single Use gewinnt eine Anfrage, alle übrigen verwenden plötzlich einen verbrauchten Wert. Der Client handelte beim Teilen normgerecht, wusste aber nicht, dass er serialisieren musste.

Die Sicherheitsbetrachtung erklärt, weshalb „Challenges aktiviert“ keine ausreichende Beschreibung ist. Der Server kann während eines gleitenden Fensters bereits gesehene jti speichern und so die Wiederholung desselben PoP JWT feststellen. Speichert er zusätzlich ausgegebene Challenge-Werte, gewinnt er stärkere Replay-Erkennung mit einem selbst gewählten Wert – zum Preis von Speicher und möglicherweise einer weiteren Netzrunde.

Zulässig ist auch eine selbstbeschreibende Challenge ohne Seen-Value-Liste. Sie skaliert besser, garantiert laut Entwurf aber nur Aktualität und verhindert kein Replay innerhalb des erlaubten Fensters. Eine weitere Variante bindet einen erwarteten Wert an die Sitzung einer Client Instance. Hinter demselben Claim stehen somit unterschiedliche Zustandskosten, Parallelitätseigenschaften und Sicherheitszusagen.

Challenge-Unterstützung bleibt optional, damit die Pflichtimplementierung einfach bleibt. jti ist dagegen vorgeschrieben und dient als Rückfall. Der Server soll außerdem ein akzeptables Zeitfenster prüfen. Daraus folgt: Eine serverseitige Challenge ist nicht automatisch einmalig und auch nicht automatisch ein Beleg für gespeicherten Replay-Zustand.

Der kombinierte DPoP-Modus bleibt getrennt

Im kombinierten Modus übernimmt ein DPoP-Nachweis nach RFC 9449 zugleich den Besitznachweis für die Instanz und die Senderbindung eines Access Tokens. Revision 11 bestimmt nun eindeutig, dass dieser Modus ausschließlich das DPoP-Nonce-Verfahren verwendet.

Fehlt der erwartete Nonce, heißt der Fehler use_dpop_nonce, und der neue Wert steht im Header DPoP-Nonce. Das ist nicht der generische use_attestation_challenge-Pfad. Der gemeinsame Challenge Endpoint kann einen DPoP Nonce proaktiv ausliefern und damit eine Fehlerrunde sparen; er macht die beiden Werte aber nicht semantisch gleich.

Der offizielle Vergleich mit Revision 10 nennt diese Exklusivität, die Auslieferung per Endpoint und die Klarstellung zu optionalen Challenges und Fehlern als Änderungen. Ein SDK, das beide Freshness-Werte in einem Cache vermischt, würde genau die neu gezogene Normgrenze wieder beseitigen.

Metadaten zeigen Fähigkeit, nicht Verbrauch

Revision 11 ergänzt Client-Metadaten auf Basis des allgemeinen Modells aus RFC 7591. Client und Server können unterstützte Signaturalgorithmen und Besitznachweis-Methoden wie attestation_pop_jwt und dpop_combined bekannt machen. Auch die URL des Challenge Endpoint ist veröffentlichbar. Mehrere Inkompatibilitäten lassen sich dadurch vor der Signatur erkennen.

Unsichtbar bleibt die Regel, die das Scheduling am stärksten verändert. Metadaten sagen nicht, ob eine Challenge erforderlich ist, welcher Lebensdauerklasse sie angehört, ob der erste Erfolg sie verbraucht, ob der Server gesehene Werte hält, ob eine selbstbeschreibende Ausführung nur Aktualität bietet oder welche Regel welchem Modus gilt. Eine Policy-Epoche zur Erklärung plötzlich wachsender Second-Use-Fehler fehlt ebenfalls.

Exakte Sekundenwerte und interne Datenstrukturen müssen nicht öffentlich werden. Last und Risiko dürfen dynamische Parameter rechtfertigen. Äußerlich beobachtbare Klassen reichen: single-use, reusable oder session-bound; dazu witnessed-state oder freshness-only. Sie erlauben Client-Planung und verhindern falsche Sicherheitsaussagen, ohne Implementierungsgeheimnisse offenzulegen.

Daniel Kade schlägt deshalb ein kleines freshness-policy-Objekt in einem Deployment-Profil vor. Je Nachweismodus würde es Unterstützung oder Pflicht, Ausgabekanäle, Lebensdauerklasse, Verbrauchsart, Replay-Haltung, Zahl automatischer Wiederholungen und Policy-Epoche angeben. Ein signierter Discovery-Beleg könnte es an die tatsächlich gelesene Metadatenversion binden.

Der Vorschlag ist kein Bestandteil von Revision 11 und kein Beschluss der OAuth Working Group. Der Entwurf erlaubt Ökosystemen bereits, Profile zu definieren. Dort lässt sich eine solche Vereinbarung erproben, ohne die lokale Freiheit des Basisprotokolls oder die Nonce-Regeln aus RFC 9449 umzuschreiben.

Quellen