Summary

  • La révision 01 signe uniquement l’identifiant de preuve et l’objet complet user_confirmation : contenu affiché, action enregistrée et horodatage.
  • La audit_trail, pourtant chargée d’expliquer la transformation de l’intention en opérations autorisées, est explicitement hors du périmètre de cette signature interne.
  • Un JWT signé intact protège encore l’ensemble du jeton. Après extraction depuis un jeton opaque, en revanche, TLS protège le transport sans transformer la trace voisine en déclaration signée portable.

Ce que l’auditeur peut démontrer

Le mécanisme proposé par draft-liu-oauth-authorization-evidence-01 apporte une précision utile. Le serveur d’autorisation conserve un id, l’objet user_confirmation et une signature JWS détachée. La confirmation contient le texte exact présenté à la personne, la manière dont elle a confirmé et un horodatage NumericDate.

La section 3.6 impose une construction très étroite : créer un nouvel objet JSON avec seulement id et user_confirmation, le canoniser avec JCS selon le RFC 8785, puis signer ces octets. Les champs d’extension au-delà de id, user_confirmation et as_signature ne doivent pas être inclus. La frontière est normative.

Cette signature répond donc à une question définie : le serveur d’autorisation a-t-il signé cet enregistrement de confirmation ? Le projet ajoute lui-même une réserve décisive. Il ne s’agit pas d’une preuve indépendante que la personne a réellement consenti, car le serveur contrôle l’interface et la clé. Une signature côté utilisateur ou un audit indépendant est nécessaire pour une non-répudiation plus forte.

Elle ne prouve pas non plus l’exécution. Le serveur de ressources est invité à consigner séparément l’identifiant, l’heure et un résumé de l’écran, puis l’opération réalisée et son succès ou son échec. Confirmation, décision, exécution et effet restent des faits distincts.

Le dossier manquant est précisément celui qui explique le sens

La section 4 attribue à audit_trail la traçabilité sémantique. Elle doit aider à analyser comment l’intention a été interprétée puis traduite en opérations autorisées. Ses champs facultatifs comprennent evidence_ref, un niveau d’expansion et proposal_ref.

Le niveau peut être none, low, medium ou high. Ce classement signale l’ampleur, mais ne décrit pas les paramètres calculés. « Medium » ne dit pas pourquoi « bon marché » vaut 50 dollars, quel catalogue a été interrogé, quelle règle a choisi la catégorie ni quelle version de politique a été exécutée.

proposal_ref pointe vers la proposition originale avant évaluation, réduction de portée ou modification du consentement. C’est une URI opaque attribuée par le serveur. La révision 01 ne définit ni protocole de récupération, ni empreinte du contenu, ni durée de conservation, ni règle d’accès. L’auditeur peut donc posséder une confirmation valide sans pouvoir reconstituer le dossier que la trace était censée rendre comparable.

Il ne faut pas transformer ce manque en accusation. Un déploiement peut conserver une proposition immuable, signer une enveloppe plus large ou lier la réponse à un registre durable. Le texte étudié ne rend simplement pas ces propriétés portables.

Deux objets ont gardé la même entrée de signature

Notre reproduction locale a construit deux objets complets. Tous deux contenaient le même identifiant, la même phrase, la même action et le même instant. Le premier indiquait une expansion medium et une proposition « headphones-50 » ; le second une expansion high et une proposition « headphones-500 ».

Les objets canoniques complets et leurs empreintes étaient différents. La projection prescrite par la section 3.6 était identique dans les deux cas, avec l’empreinte aec26fa5351ab57f144fd6b387b297969f73e34ec3ea5a557592a0b2d3a7b512. Cela démontre seulement que la modification se situe hors de l’entrée de la signature interne. La reproduction ne vérifie pas le JWS abrégé du projet et ne révèle ni exploitation, ni serveur malveillant, ni incident réel.

Le support de transport change la portée disponible

Dans un jeton d’accès JWT signé conforme au RFC 9068, la signature extérieure protège l’objet embarqué complet, y compris la trace d’audit, tant que le jeton reste intact et vérifié. Modifier cette trace casserait la signature extérieure. Il serait faux de présenter son exclusion de as_signature comme une absence totale d’intégrité.

Avec un jeton opaque, le serveur de ressources récupère les métadonnées par introspection RFC 7662 ou par une route dédiée. Le projet qualifie alors as_signature de seule protection d’intégrité de l’enregistrement et exige TLS. TLS protège la connexion et la réponse pendant la récupération. Après extraction, stockage ou transmission, il n’élargit pas rétroactivement l’objet du JWS détaché.

L’introspection décrit en outre un contexte actuel : l’état active dépend du serveur, la réponse peut varier selon le serveur de ressources et une mise en cache accepte une perte de fraîcheur. Elle ne devient pas, par nature, un reçu durable de transformation sémantique.

La politique n’est pas la preuve

Le projet compagnon consacré à Rego sépare utilement le « pourquoi » du « quoi ». La preuve explique pourquoi une opération a été autorisée ; l’objet frère rego_policy dit ce que l’agent peut faire et ce que le serveur de ressources évalue. La signature interne de confirmation ne lie ni l’URI de cette politique, ni son point d’entrée, ni ses entrées d’évaluation.

Un JWT extérieur intact peut lier la représentation combinée. Un système à jeton opaque doit définir comment les deux objets sont récupérés, conservés et rapprochés. Sans cette discipline, le mot « autorisé » fusionne l’écran, l’interprétation, la politique, la décision et l’effet, puis laisse au logiciel exécutant le pouvoir de combler les vides.

Un passeport d’interprétation proportionné

Pour une action à fort impact, un passeport d’interprétation devrait relier l’identifiant de preuve et de session, l’empreinte et la langue de l’écran, la proposition immuable, l’opération résolue, le différentiel sémantique, le composant qui l’a produit, la politique et son empreinte, les entrées d’évaluation, l’émetteur, l’audience, l’agent, le client, la décision du serveur, la requête réellement envoyée, le reçu d’exécution et l’effet observé séparément.

Cette proposition est l’analyse de Daniel Kade, pas une exigence de la révision 01. Les données sensibles peuvent rester dans des registres à accès contrôlé, reliés par empreinte. Une spécification minimale ne centralise pas tout : elle conserve les identifiants immuables indispensables à la reconstruction.

Sources and limits

Les observations ont été arrêtées au 30 septembre 2026, fuseau Asia/Shanghai. La révision 01 est un Internet-Draft individuel actif, non un RFC, un consensus du groupe OAuth ou une preuve d’adoption. La reproduction locale vérifie uniquement la construction du périmètre. Elle ne démontre ni faiblesse de JWS/JCS, ni modification en transit, ni défaut d’implémentation, ni dommage, ni action accomplie. Le projet peut évoluer, être remplacé ou expirer.