Résumé

  • OpenCAPIF 5.0.0 permet à plusieurs fonctions centrales CAPIF de partager des API entre domaines.
  • L’échange passe par l’identité du pair, TLS mutuel, le choix du fournisseur et des règles qui filtrent ce que chaque invocateur peut découvrir.

Une API peut enfin passer chez le voisin. Elle ne part pas avec une valise anonyme.

ETSI a annoncé OpenCAPIF 5.0.0 le 26 octobre. Le changement central est l’interconnexion CAPIF : deux déploiements séparés peuvent se découvrir et publier des API de service à travers leurs domaines. Un invocateur rattaché à un CCF peut utiliser une API fournie derrière un autre CCF. La promesse tient en une ligne ; le mécanisme occupe plusieurs étapes.

L’administrateur d’un CCF local lance la demande. Le CCF-A contacte le CCF-B sous TLS mutuel et transmet son identifiant, son domaine, les informations de son autorité de certification et sa clé publique. Le pair enregistre A et répond avec sa propre identité. Les deux fonctions centrales synchronisent ensuite les API qui remplissent les critères de partage. La frontière entre organisations devient une relation technique vérifiable.

Le filtre repose sur des champs précis. Le fournisseur doit déclarer isShareable = true et nommer les domaines autorisés dans capifProvDoms. L’API ne doit pas provenir du CCF pair et son chemin de publication ne doit pas déjà contenir ce CCF. La copie reçue est marquée non partageable. Elle ne repart donc pas vers son expéditeur en faisant le tour du pâté de maisons.

Open Discover règle une autre perte de temps. Avant l’adhésion à un déploiement, un invocateur peut vérifier si une API, une version ou un point d’accès y existe. Un jeton valide du service Register suffit pour cette recherche. Le développeur peut vérifier la présence de l’API avant de remplir tout le dossier d’entrée.

La visibilité détermine ensuite qui voit quoi. Les fournisseurs et administrateurs peuvent cibler un fournisseur, une API ou une fonction AEF, ajouter des exceptions pour certains invocateurs, choisir une règle par défaut d’autorisation ou de refus, l’activer et limiter sa durée. Le service Discover applique les règles actives à chaque demande. Deux personnes ne reçoivent pas forcément le même catalogue.

La Release 5 autorise aussi des API de même nom si elles viennent de fonctions AEF différentes. Le doublon reste refusé au sein d’une même AEF. Le nom décrit une API dans son contexte d’exposition ; il n’occupe plus toute la plateforme à lui seul.

La frontière des normes mérite une phrase claire. La 3GPP a introduit l’interconnexion CAPIF dans la Release 16 et définit les points CAPIF-6/6e ainsi que les procédures de sécurité. Les spécifications laissent des détails d’implémentation ouverts ; l’équipe OpenCAPIF présente donc son flux comme une proposition de mise en œuvre dans l’architecture 3GPP. La version 5 rend cette proposition concrète : certificats échangés, APIs filtrées, copies synchronisées et retrait possible.

Le projet ajoute 31 tests : 11 sur l’interconnexion, 12 sur la visibilité, six sur Open Discover et deux sur les noms identiques entre AEF. Le chiffre éclaire le travail livré. La vraie nouveauté tient au partage gouverné : chaque API a une destination, chaque invocateur une visibilité, chaque relation un début et une fin.

Sources