Résumé

  • Le groupe de travail Open Cloud Mesh a adopté le protocole d’intégration ; draft-ietf-ocm-integration-protocol-00 a été publié le 11 septembre 2026. Il s’agit encore d’un Internet-Draft évolutif, pas d’une norme achevée.
  • Trois modes répartissent l’état, la révocation et la disponibilité entre le serveur OCM et les serveurs de protocole. Un serveur de jetons distinct peut lui aussi recevoir une autorité sensible.
  • La transparence recherchée concerne le pair distant. Pour rendre la délégation redevable en interne, Daniel Kade propose une cartographie locale et protégée des rôles ; ce n’est pas une exigence du projet.

L’adoption change le responsable du texte

Le journal du Datatracker date du 11 septembre la version -00 du groupe et la relie à la série individuelle qu’elle remplace. Le message annonçant le résultat est prudent : les deux documents adoptés sont de bons points de départ et continueront d’évoluer. Le groupe de travail prend donc la main sur la rédaction ; il n’a ni publié un RFC ni certifié un déploiement.

Ce changement institutionnel accompagne une proposition technique concrète. Dans la version de groupe 00, le serveur OCM conserve le rôle de serveur émetteur vis-à-vis de la fédération. Derrière cette façade, des serveurs de protocole peuvent fournir WebDAV, SSH/SFTP ou une application interactive. Rien n’impose qu’ils utilisent le même logiciel, la même machine ou la même infrastructure.

La première version de groupe ne se contente pas de renommer la version individuelle 01. Elle ajoute notamment un modèle de menace. Celui-ci place les serveurs OCM, les serveurs de protocole appairés et l’éventuel serveur de jetons dans le périmètre de confiance : ils sont supposés non compromis et capables d’appliquer correctement leurs politiques locales. Le texte protège contre un attaquant sur le réseau ; il ne promet pas qu’un composant de confiance compromis restera sûr.

Le choix du mode décide du moment où une révocation agit

Dans le mode provisionné, le serveur OCM crée à l’avance un enregistrement de partage sur le serveur de protocole, au moyen d’un canal signé. À la fin du partage, une requête de révocation ordonne l’arrêt du service et la libération des ressources associées. C’est le seul mode prévu pour SSH et le plus adapté lorsqu’une application crée une session ou un environnement propre à chaque partage.

Le mode autonome supprime cette API entrante. Les données nécessaires voyagent dans une revendication ocm_ip d’un JWT signé. Le serveur de protocole n’a pas besoin de conserver un état par partage, mais un jeton déjà émis reste valable jusqu’à son expiration. Une commande « ne plus partager » n’est donc pas instantanée par nature. Le projet interdit de mêler ce chemin et le mode provisionné pour un même partage, afin qu’un ancien jeton ne contourne pas silencieusement une révocation.

Le mode avec introspection fait vérifier chaque justificatif par un point de terminaison conforme au RFC 7662. Il sert à conserver la compatibilité avec des serveurs destinataires qui présentent encore le secret partagé historique. En contrepartie, chaque accès non mis en cache dépend du serveur OCM ou de son serveur de jetons, et une réponse positive en cache retarde l’effet d’une révocation.

Ainsi, « compatible OCM-IP » ne décrit pas une propriété unique. Le mode choisi détermine où résident l’état et les métadonnées, quel service devient indispensable à chaque requête et quelle horloge gouverne la fin effective d’un droit.

Une architecture volontairement indétectable de l’extérieur

Le projet impose une frontière nette : le serveur destinataire ne doit pas avoir à connaître OCM-IP. L’adresse annoncée peut aboutir au serveur OCM, à un proxy inverse ou à un serveur de protocole séparé. Au niveau OCM, le résultat doit rester celui d’un accès ordinaire. Aucun indicateur de capacité ne permet au pair de découvrir la délégation.

Cette discrétion n’abolit pas la configuration locale. L’appairage est réalisé hors bande par les opérateurs. Il associe des protocoles, des types de ressources, des modes, des domaines, des points de terminaison et des URL de jeux de clés. Le serveur de protocole doit conserver une liste d’émetteurs OCM autorisés et refuser les autres.

Les signatures de messages HTTP, les JWK publiées et les JWT donnent une forme vérifiable à cette relation. Une signature correcte relie une assertion à une clé ; la liste d’autorisation et le partage relient cette assertion à un pouvoir limité. Cela ne reconstitue pas la décision humaine ou automatisée qui a ajouté un serveur, remplacé une clé ou prolongé une durée de jeton.

La délégation d’un serveur de jetons montre pourquoi la distinction est importante. Le projet permet au serveur OCM de ne garder que la logique de fédération, tandis que l’accès aux ressources et l’émission des justificatifs sont assurés ailleurs. Le serveur de jetons reçoit alors le pouvoir de signer et les informations sur les identités et les partages nécessaires à sa tâche. Une telle autorité mérite une trace qui ne dépende pas seulement de la configuration présente.

Les registres IANA n’ont encore rien attribué

Le texte demande deux inscriptions de ocm_ip : une revendication JWT et un membre de réponse d’introspection OAuth. Il précise que ces inscriptions doivent intervenir lorsque le document sera devenu RFC. Au moment de la vérification, ni le registre JWT de l’IANA ni les registres des paramètres OAuth ne contiennent cette chaîne exacte.

Ce constat ne révèle aucun retard. Il sépare simplement la phase de rédaction de la phase d’exécution. Un essai fondé sur le projet doit citer sa révision ; l’adoption par le groupe ne transforme pas un nom demandé en valeur normalisée.

Conserver la carte que le pair n’a pas à voir

L’opérateur émetteur pourrait tenir une carte de responsabilité de délégation protégée. Elle associerait à chaque serveur OCM, serveur de protocole et serveur de jetons son rôle, les protocoles et ressources concernés, le mode choisi, les identifiants de point de terminaison et de clé, la période d’effet, l’autorité qui a validé la modification, le résultat de la révocation ou du nettoyage, le contact d’incident et l’emplacement des preuves.

Daniel Kade avance ici cette méthode pour l’analyse éditoriale ; aucun texte de l’IETF ou d’OCM ne l’impose. Cette carte ne doit pas être insérée telle quelle dans un jeton ni livrée au pair. Une quittance publique peut se limiter à un identifiant opaque, une classe de rôle, une période et un résultat contrôlé. Les noms internes, les identités personnelles, la topologie sensible et tout secret restent protégés.

La carte n’accorde aucun accès. Elle mémorise une décision et une observation ; l’appairage et les clés en vigueur restent l’autorité technique. Lors d’un remplacement, une nouvelle entrée pointe vers l’ancienne. Une révocation provisionnée distingue la réception de la demande de la destruction effective d’une session. L’expiration d’un JWT distingue le passage du temps de la preuve qu’aucune copie n’est encore utilisée.

Ce partage des fonctions rejoint le Policy Mirror de Heng Lu : l’acteur, la règle et la preuve ne doivent pas parler les uns à la place des autres. La Minimum Initial Specification permet de garder un noyau commun étroit tout en laissant aux opérateurs une comptabilité locale plus riche. La transparence pour le pair et la mémoire pour l’opérateur peuvent donc coexister.

Sources

  1. Protocole d’intégration OCM, version WG 00
  2. Fiche actuelle du Datatracker
  3. Historique du document
  4. Annonce du résultat de l’adoption
  5. Version individuelle 01
  6. Groupe de travail Open Cloud Mesh
  7. Compte rendu OCM de l’IETF 126
  8. Protocole OCM de base, version WG 06
  9. RFC 9421 — signatures de messages HTTP
  10. RFC 7517 — JSON Web Key
  11. RFC 7662 — introspection OAuth 2.0
  12. RFC 7519 — JSON Web Token
  13. Registre JWT de l’IANA
  14. Registres OAuth de l’IANA
  15. Heng Lu — The Policy Mirror
  16. Heng Lu — Minimum Initial Specification