Résumé

  • À l’ordre du jour du 24 septembre, l’action IANA #1451183 demande à Deb Cooley de trouver des experts pour les registres de métadonnées d’enregistrement dynamique des clients, de méthodes d’authentification au point de terminaison de jetons et de réponses d’introspection. La tâche remonte au 30 avril et figure encore dans le suivi actualisé le 17 septembre.
  • Le procès-verbal du 30 avril précise « additional designated experts ». Les trois tableaux IANA indiquent toujours Justin Richer. Une demande de renfort n’établit ni vacance ni interruption du service.
  • Il faut suivre séparément la décision de nomination, la liste des experts publiée par IANA, l’examen d’une proposition sur la liste ouverte et l’inscription définitive d’un nom.

Un titre administratif peut produire une fausse alerte technique. « Designated experts needed » est une catégorie de suivi de l’IESG, non un bulletin annonçant que les registres OAuth ne peuvent plus recevoir de demandes. Le même dossier, dans le compte rendu du 30 avril, porte sur la recherche de personnes supplémentaires. Au moment de cette lecture, IANA affiche un titulaire dans chacun des trois registres. C’est la coexistence de ces deux traces publiques, et non une prétendue panne, qui mérite l’attention.

Ces registres ne constituent pas une seule liste indifférenciée. L’un catalogue les informations qu’un client peut communiquer lors de son enregistrement dynamique. Un autre donne les noms des méthodes d’authentification auprès du point de terminaison de jetons. Le troisième tient les noms des champs de réponse d’introspection destinés à traverser les frontières entre services. Une proposition peut concerner l’un sans modifier les deux autres. Ajouter un expert n’équivaut donc pas automatiquement à changer une ligne de registre : il faut préciser le périmètre de la nomination.

Les RFC qui fondent ces tableaux prescrivent une procédure. RFC 7591 et RFC 7662 prévoient un examen de deux semaines sur la liste des extensions OAuth et réservent l’instruction des mises à jour d’IANA aux experts désignés. La discussion publique, l’avis de l’expert et la publication d’une entrée sont trois événements distincts. Le nombre de téléconférences pendant lesquelles l’IESG conserve sa tâche ne mesure pas le délai d’une demande particulière. Aucun des documents cités ne fournit ici un arriéré chiffré, une candidature refusée ou une faute imputable au titulaire nommé.

Le contrôle utile est un rapprochement de versions. Quand une décision de l’IESG apparaîtra, le lecteur devra pouvoir voir quels tableaux sont concernés, la date de la décision, puis la date à laquelle IANA actualise éventuellement les noms affichés. Pour chaque demande concrète, il faudra encore relier le fil de discussion, la décision d’examen et l’entrée publiée. Un tel reçu de continuité est une proposition éditoriale de Daniel Kade ; il ne prétend pas être une nouvelle règle officielle.

Le problème est autant institutionnel qu’opérationnel. Une liste de noms partagée évite que des implémentations indépendantes donnent des sens incompatibles au même identifiant. Mais inscrire un nom ne décide pas de son adoption dans les systèmes déployés. Préserver cette frontière entre coordination, décision locale et usage réel permet de demander du renfort sans transformer l’IESG en gestionnaire supposé de chaque déploiement OAuth.

Sources