Summary

  • La révision 01 envoie un JWT signé par son émetteur dans Authorization: DPoP et réutilise la preuve DPoP habituelle, y compris htu, htm, jti, le nonce et ath.
  • Une preuve valide ne dit pas si la valeur est un jeton d’accès ou un Credential. Le serveur doit distinguer les deux par un iss déjà approuvé et un typ explicitement autorisé.
  • Lier une clé à une requête ne crée ni audience absente, ni statut actuel, ni autorisation locale, ni preuve du résultat produit par le service.

La case est la même, pas le contrat

Le projet part d’un avantage réel : un serveur de ressources compatible avec RFC 9449 sait déjà recevoir une valeur liée à une clé. Le Holder place donc le Credential entier dans l’emplacement du jeton et signe une preuve séparée. ath reste le hachage SHA-256 des octets US-ASCII de la valeur reçue. Le serveur vérifie signature, fraîcheur, méthode, URI, unicité de jti, nonce éventuel, puis rapproche la clé de preuve de cnf.jkt ou de l’empreinte de cnf.jwk.

Cette chaîne établit la cohérence de la présentation. Elle ne choisit pas sa sémantique. Un jeton d’accès JWT conforme à RFC 9068 porte une audience et le type at+jwt. Le Credential proposé doit porter un type défini par le déploiement, différent de at+jwt et des types d’ID Token. Si un serveur accepte les deux, iss et typ commandent deux branches de validation distinctes. Le même aspect sur le réseau n’autorise pas une branche commune par défaut.

L’adresse de la requête n’est pas son audience

htu et htm prouvent que la clé confirmée a servi pour cette méthode et cette URI. Ils ne disent pas quels serveurs l’Émetteur avait voulu autoriser à interpréter le Credential. Cette décision appartient à aud, quand il existe, et seul l’Émetteur le fixe.

Le projet permet d’omettre aud. Le Credential devient alors présentable à tout serveur de ressources qui fait déjà confiance à l’Émetteur. Le Holder choisit une destination, mais ce choix ne fabrique pas une restriction d’audience. Une organisation qui partage un fournisseur d’identité entre plusieurs services agrandit donc le rayon de réutilisation, même si chaque service conserve sa propre politique d’autorisation.

Le texte impose précisément de ne pas déduire l’accès de la seule validité du Credential. La preuve de possession répond à « cette clé présente cette valeur ici ». La politique locale doit encore répondre à « ce sujet peut-il effectuer cette opération maintenant ? ».

Le statut porte l’horloge

Un Credential peut vivre bien plus longtemps qu’un jeton d’accès. Le projet recommande alors une information de statut. Si elle est présente, le vérificateur doit la consulter et refuser un statut invalide. Un Credential long sans statut peut aussi être refusé par politique locale.

La liste de statut peut être mise en cache ; sa durée de cache devient le délai effectif de révocation. Une signature valide, une preuve DPoP fraîche et une liste ancienne sont trois observations différentes. L’absence d’appel à l’Émetteur sur le chemin critique réduit la latence et la visibilité directe de l’usage, mais une récupération de statut trop fréquente peut recréer cette visibilité.

Une présentation sans sélection

Le Credential est envoyé entier. Chaque vérificateur voit toutes ses claims, et la signature stable permet de corréler les présentations. Les en-têtes peuvent aussi finir dans les journaux d’accès ou dans des proxys. TLS protège le transport ; il ne retire pas une claim excessive et n’efface pas une copie déjà journalisée.

Quand le serveur doit découvrir les Credentials disponibles, demander un sous-ensemble de claims ou recueillir le consentement d’une personne, OpenID4VP reste le mécanisme adapté. Ici, l’appelant logiciel connaît déjà le serveur et le Credential attendu. Même un SD-JWT VC ne peut être utilisé que sous la forme de son JWT signé, sans disclosures.

La Minimum Initial Specification de Lu Heng éclaire ce choix : réutiliser un mécanisme minimal n’oblige pas à fusionner les décisions futures. Running-Code Primacy exige ensuite les reçus effectivement produits par le serveur : type choisi, Émetteur autorisé, audience, âge du statut, version de politique et résultat observable.

Sources and limits

Ces sources n’établissent ni adoption par le groupe OAuth, ni consensus IETF, ni RFC, implémentation, interopérabilité, déploiement d’agents, révocation réelle, décision d’accès ou résultat de service. L’Article RFC 9449 existant conserve la thèse générale de la contrainte d’émetteur ; celui-ci traite uniquement du changement de modèle derrière un format identique.