Summary

  • Revision 01 transportiert ein vom Issuer signiertes JWT Credential in Authorization: DPoP und verwendet die Request-Proof-Regeln aus RFC 9449 unverändert.
  • Gültige Bytes und ein gültiger Proof klassifizieren das Objekt nicht. Der Server muss Credential und Access Token anhand eines vertrauten iss und eines zugelassenen typ trennen.
  • Besitznachweis für einen Request ersetzt weder Issuer-aud, aktuellen Status, angemessene Claim-Offenlegung, lokale Autorisierung noch den beobachteten Serviceausgang.

Wiederverwendet wird der Steckplatz

Der Holder sendet das vollständige Credential dort, wo sonst das Token steht, und signiert einen DPoP Proof mit htu, htm, iat, jti, gegebenenfalls Nonce und ath. ath bleibt der SHA-256-Hash der empfangenen US-ASCII-Bytes. Zusätzlich gleicht der Resource Server den Proof-Schlüssel mit cnf.jkt oder dem Thumbprint von cnf.jwk ab.

Diese Kette beweist Konsistenz und Schlüsselbesitz. Sie wählt keine Semantik. RFC 9068 verlangt für sein JWT-Access-Token-Profil eine Audience und at+jwt. Das vorgeschlagene Credential benötigt einen deployment-spezifischen typ, der weder at+jwt noch ein ID-Token-Typ sein darf. Akzeptiert ein Server beide Objektklassen, müssen iss und typ in getrennte Validierungszweige führen. Sonst wird eine korrekte Signatur zur Eintrittskarte in die falsche Policy.

Request-Ziel und Audience sind verschiedene Entscheidungen

htu und htm binden den Proof an HTTP-Methode und URI. Das ist Proof of Possession für diesen Request. Die Audience beschreibt dagegen, welche Verifier der Issuer für das wiederverwendbare Credential vorgesehen hat. Nur der Issuer setzt aud; der Holder erzeugt durch die Wahl eines Ziels keine nachträgliche Audience.

Der Entwurf erlaubt Credentials ohne aud. Sie können jedem Resource Server vorgelegt werden, der demselben Issuer vertraut. Gemeinsames Vertrauen in einen Identity Provider bedeutet jedoch nicht, dass alle Dienste dieselben Claims oder Berechtigungen akzeptieren sollten. Deshalb bleibt die lokale Autorisierung ein eigener Schritt, und die Gültigkeit des Credentials darf nicht als Zugriffsentscheidung gelesen werden.

Status wird zur zweiten Uhr

Credentials können länger leben als Access Tokens. Der empfohlene status soll diese Differenz auffangen. Ist er vorhanden, muss der Verifier ihn prüfen und einen ungültigen Zustand ablehnen. Ein langlebiges Credential ohne Status kann die lokale Policy ebenfalls zurückweisen.

Ein Statuslisten-Cache macht seine Lebensdauer zur Revocation-Verzögerung. Issuer-Signatur, frischer DPoP Proof und ältere Statusliste sind Belege mit verschiedenen Zeitgrenzen. Kein Issuer-Aufruf im Request-Pfad senkt Latenz und direkte Beobachtung; Statusabrufe können den Nutzungsort trotzdem verraten.

Vollständig heißt nicht datensparsam

Der Holder sendet alle Claims. Jeder Verifier sieht das ganze JWT, und der stabile Signaturwert ermöglicht Korrelation über mehrere Server hinweg. Authorization-Header können außerdem in Access Logs oder Proxies landen. TLS schützt die Übertragung, nicht vor überbreiten Claims oder bereits gespeicherten Kopien.

Muss ein Verifier Credentials entdecken, nur Teilmengen verlangen oder menschliche Zustimmung einholen, passt OpenID4VP besser. Dieses Profil gilt für Software, die Ziel und akzeptiertes Credential bereits kennt. Ein SD-JWT VC wird hier nur als Issuer-signiertes JWT ohne Disclosures eingesetzt.

Lu Hengs Minimum Initial Specification trennt die Wiederverwendung eines kleinen gemeinsamen Mechanismus von einer zentralen Gesamtentscheidung. Running-Code Primacy verlangt danach die realen Belege: gewählter Typ, Issuer-Vertrauen, Audience-Zweig, Statusalter, Policy-Version und beobachtetes Ergebnis.

Sources and limits

Diese Quellen belegen keine OAuth-WG-Übernahme, keinen IETF-Konsens, RFC, Implementierung, Interoperabilität, Agenten-Deployment, reale Ausstellung oder Sperrung, Autorisierung oder Servicewirkung. Der bestehende RFC-9449-Artikel behält die allgemeine Sender-Constraint-These; hier geht es nur um das andere Autoritätsmodell im gleichen Wire-Format.