Résumé

  • Le projet individuel Capability Language Core, daté du 27 septembre, ajoute allow_unresolved aux réponses « autoriser » et « refuser » pour les droits d’un agent.
  • Une contrainte d’heure ou de réseau reconnue mais non évaluée doit parvenir à l’exécutant; les trois implémentations citées ont le même auteur et ne prouvent pas une validation indépendante.

La difficulté n’est pas de décrire une limite, mais de savoir qui la contrôle au moment décisif. Une permission peut porter une plage horaire ou un périmètre réseau parfaitement lisible par un programme. Si le moteur commun ne connaît ni l’environnement d’exécution ni la règle locale d’évaluation, sa réponse ne saurait être un feu vert définitif. C’est sur ce passage entre calcul et action que le texte de Jijie Wei place une troisième réponse.

Le document draft-wei-capability-language-core-00 a été publié le 27 septembre 2026 comme Internet-Draft individuel, avec une ambition de statut Experimental. Le Datatracker le classe I-D Exists et précise qu’une telle soumission ne vaut pas approbation de l’IETF. Il ne s’agit donc ni d’un RFC ni d’une technologie dont l’adoption serait démontrée. Son objet est une langue minimale et transportable pour identifier une capacité, décider si une permission couvre une opération, combiner plusieurs permissions et rendre un verdict stable.

L’article 8.4 du projet pose une distinction difficile à contourner. Les contraintes de temps et de réseau dont la syntaxe est reconnue, mais que le noyau v1 ne sait pas évaluer, ne disparaissent pas au cours du calcul. Elles figurent dans la liste unresolved et imposent le verdict allow_unresolved. Cette valeur n’est pas un synonyme de allow. Le composant qui applique la politique doit confirmer chacune des obligations avant d’exécuter; à défaut, il refuse. Si plusieurs conditions subsistent, une seule vérification favorable ne libère pas les autres.

Le projet fournit ensuite une fonction Resolve. Pour chaque obligation, le consommateur renvoie une réponse satisfaite, violée ou inconnue; le noyau en tire une nouvelle décision. La fonction organise le retour d’information, sans observer elle-même tous les réseaux ni certifier le contexte horaire d’un déploiement. La question de gouvernance devient très concrète: un adaptateur qui réduit toutes les réponses autres que deny à un simple oui efface la distinction que le texte vient d’introduire. Il s’agit d’un risque de conception, pas de l’annonce d’une faille constatée.

Le texte se garde aussi de promettre un système complet. La confiance accordée à l’émetteur, la vérification cryptographique du support, le cycle d’exécution et la forme d’un reçu restent hors de son périmètre. RFC 9396 permet déjà de porter des détails d’autorisation OAuth; le projet CLC l’évoque comme possibilité de transport, sans que ce RFC l’ait adopté. Confondre une représentation de droit avec la preuve d’identité ou la preuve d’exécution reviendrait à sauter plusieurs contrôles distincts.

Le projet rapporte 123 vecteurs de test et 1 184 cas de propriétés pour sa partie autorisation, exécutés dans trois langages. Le même auteur se trouve derrière les trois implémentations, ce que le document reconnaît: leur concordance vérifie la cohérence du texte mais ne remplit pas le seuil de deux implémentations indépendantes. La classe CLC-A est revendiquée comme base; la classe relative aux preuves, CLC-E, ne l’est pas. Ce degré de franchise est utile, à condition de ne pas transformer une batterie de tests en certification d’interopérabilité.

Sources