Résumé

  • Un projet individuel d'Internet-Draft définit client_attesters pour publier les attestateurs agréés par un client, sans transférer au client la politique de confiance du serveur d'autorisation.
  • Retirer un nom de cette liste agit sur les nouvelles authentifications après prise en compte du changement ; les grants et jetons déjà délivrés ne sont pas automatiquement révoqués.

Une liste que son propriétaire peut corriger est utile seulement si l'on sait à quel moment les autres cessent de consulter l'ancienne version. C'est la question que pose le nouveau projet Client Attester Endorsement. Son apport proposé est précis : permettre à l'éditeur des métadonnées d'un client OAuth de déclarer quels attestateurs peuvent parler pour ce client, puis de rétrécir cette délégation. Le texte ne promet pas que le geste de retrait efface tous les effets des décisions prises auparavant.

Le document de K. McGuinness, daté du 28 septembre 2026, est la première version d'un Internet-Draft individuel visant la filière Standards Track. Sa fiche IETF ne doit pas être lue comme l'annonce d'une norme achevée, d'une adoption par le groupe OAuth ou d'une exploitation en production. Le profil s'appuie sur le projet d'authentification par attestation et ne crée ni titre d'accès nouveau ni méthode d'authentification supplémentaire. Il tente de combler une relation manquante : qui a le droit d'attester pour tel client, distinct de la question de savoir si le serveur fait confiance à l'attestateur.

Le paramètre client_attesters peut apparaître dans l'enregistrement d'un client ou dans son Client ID Metadata Document. L'éditeur y nomme les attestateurs et leurs emplacements de clés de vérification. Ce pouvoir n'est pas une permission d'imposer ces clés au serveur. Selon la section 2.1 du projet, une attestation soumise à ce profil n'est acceptable que si les métadonnées autorisées approuvent actuellement son émetteur et si la politique du serveur d'autorisation l'admet pour ce client, avec une source de clés qu'il estime fiable. Le serveur peut réduire l'ensemble proposé ; il ne peut pas ajouter sous ce profil un attestateur que le client n'a pas approuvé. La double condition est le mécanisme, non une simple recommandation morale.

Le délai du retrait dépend ensuite de la manière dont cette information circule. Le projet oblige le serveur à fixer des durées maximales finies pour ses copies en cache des avals et des jeux de clés, puis à actualiser ou rejeter les copies expirées. Il ne fixe cependant pas de plafond universel. L'éditeur ne peut donc pas déduire du protocole seul que le retrait sera vu dans une heure, un jour ou une autre durée. Une durée prévisible doit figurer dans l'accord de confiance de la mise en œuvre. La règle concerne les copies, pas les enregistrements clients qui font autorité.

Une fois une modification obtenue ou enregistrée par le serveur, celui-ci doit l'appliquer à la présentation suivante ; un refus directement posé par sa politique prend effet sur les demandes suivantes sans attendre le cache.

Il reste une autre horloge, hors de la liste des attestateurs. La section 6.3 dit que le retrait est prospectif : il empêche de nouvelles authentifications du client sous l'aval retiré, sans annuler les grants ou les jetons d'accès déjà émis. Une demande de renouvellement qui exige une attestation repasse par le contrôle. Mettre réellement fin à l'accès demande de révoquer séparément les grants et les jetons concernés, puis d'arrêter les renouvellements. Avec l'introspection RFC 7662, un jeton révoqué peut être indiqué inactif ; un serveur de ressources qui vérifie localement les jetons dépend d'un autre mécanisme ou de leur expiration. Confondre ces deux horloges donnerait un procès-verbal de clôture prématuré.

Enfin, la provenance d'une attestation n'est pas nécessairement indépendante. Lorsque l'éditeur peut choisir l'attestateur et ses clés, il peut également exploiter cet attestateur lui-même ; la déclaration ne constitue alors pas une garantie extérieure à l'éditeur. Et le seul fait de publier client_attesters n'oblige pas à produire une attestation si la politique accepte une autre méthode d'authentification. Ces réserves appartiennent au texte du projet ; elles ne décrivent aucun incident constaté.

Pour contrôler un retrait, je demanderais une preuve de l'ancienne et de la nouvelle liste, l'identité du responsable de l'édition, la politique de confiance du serveur, l'âge de ses copies, la première présentation refusée, puis l'inventaire des accès déjà accordés et de leur révocation effective. Cette fiche serait une pratique éditorialement suggérée, pas un format prescrit par l'IETF. Elle ferait apparaître le point essentiel : publier une décision n'est pas démontrer que tous ceux qui doivent l'exécuter l'ont exécutée.

Sources