Resumen

  • Release 5 permite que distintas funciones centrales CAPIF compartan APIs de servicio entre dominios.
  • Cada intercambio pasa por identidad, TLS mutuo, filtros del proveedor y reglas que deciden qué descubre cada invocador.

El API vecino ya tiene puerta. La Release 5 llega con una carpeta para apuntar quién puede cruzarla.

ETSI anunció OpenCAPIF 5.0.0 el 26 de octubre. La función principal conecta despliegues CAPIF separados para que publiquen y descubran APIs entre organizaciones. Un invocador registrado en una función central CAPIF (CCF) puede utilizar un servicio expuesto detrás de otra CCF. El cambio no es solo una línea nueva en un catálogo: pone la relación entre dominios dentro del flujo operativo.

El administrador de una CCF local inicia la conexión. CCF-A contacta con CCF-B mediante TLS mutuo y envía su identificador, dominio, información de la autoridad certificadora y clave pública. El par registra la identidad recibida y devuelve la suya. Después sincronizan las APIs que cumplen las condiciones de publicación. Primero se establece quién está al otro lado; luego viaja el inventario.

El proveedor decide qué APIs entran en ese inventario. Cada una debe tener isShareable = true y nombrar los dominios permitidos en capifProvDoms. El origen no puede ser la CCF vecina y la ruta de publicación no puede incluir ya a ese par. La copia se registra como no compartible, para que no rebote de vuelta y forme un circuito sin sentido.

Open Discover resuelve una pregunta anterior al alta: ¿está disponible aquí el API, la versión o el endpoint que busco? El invocador puede consultarlo con un token válido del servicio Register, sin completar primero el proceso de onboarding. La consulta permite mirar el estante antes de pedir la llave del local.

Visibility Control define quién ve cada pieza. Los proveedores y administradores pueden crear selectores por proveedor, API o función AEF; añadir excepciones para invocadores; elegir una regla predeterminada de permitir o denegar; activar la regla y fijar su vigencia. Discover aplica las reglas vigentes a cada consulta. La visibilidad no tiene que ser igual para toda la clientela.

También cambia el alcance de los nombres. Dos funciones AEF distintas pueden publicar APIs con el mismo nombre. La misma AEF sigue sin poder duplicar el suyo. El identificador se interpreta junto con quien expone el servicio, y no como una reserva única para todo el despliegue.

La 3GPP incorporó la interconexión CAPIF en Release 16 y define los puntos CAPIF-6/6e y sus procedimientos de seguridad. Sus especificaciones dejan decisiones de implementación abiertas; OpenCAPIF explica que su flujo concreto es una propuesta del grupo SDG dentro de la arquitectura 3GPP. Release 5 hace visible esa decisión de ingeniería: cómo se intercambian identidades, cómo se filtra una API y cómo se sincroniza con un par.

El equipo suma 31 pruebas: 11 de interconexión, 12 de visibilidad, seis de Open Discover y dos para nombres repetidos entre AEF. El reparto describe dónde trabajó el proyecto. Para quien opera el sistema, la secuencia importa más: reconocer al par, limitar el intercambio y comprobar que una API sigue visible solo donde su proveedor la autorizó.

Sources