Summary

  • OpenCAPIF Release 5 connects separate CAPIF Core Functions so APIs can be shared across provider domains.
  • The route is controlled at every turn: CCF identity, mutual TLS, provider share settings, visibility rules and discovery before onboarding.

The API neighbour has a door now. Release 5 brought a clipboard.

ETSI announced OpenCAPIF 5.0.0 on 26 October. Its headline feature, CAPIF Interconnection, lets separate OpenCAPIF deployments discover and share service APIs across organisations. A consumer can reach an API hosted behind another CAPIF Core Function (CCF). That sentence sounds like a bridge. The release notes show the turnstiles.

The connection begins with an administrator of a local CCF. CCF-A contacts CCF-B over mutual TLS and presents its CCF identity, domain, certificate-authority information and public key. The peer records the relationship and returns its own identity. The systems then synchronize eligible API records. The implementation gives two independently run domains a defined way to recognize one another before they start exchanging service descriptions.

The sharing filter is specific. An API must be marked isShareable; its provider must name the peer domain in capifProvDoms; the API’s source cannot be the peer itself; and the existing publication path must not already include that peer. The copy sent to the neighbour is marked non-shareable, which stops it bouncing back through the same connection. The API travels with a route history, not a forwarding rumour.

Release 5 adds a second useful door: Open Discover. An invoker can check whether an API, version or endpoint exists before onboarding to that deployment. The caller needs a valid Register Service token. A developer can ask “is the thing here?” before completing the longer entry process.

Visibility Control decides what the answer contains. Providers and administrators can set selectors for providers, APIs and API Exposing Functions, define invoker exceptions, choose an allow-or-deny default, enable or disable a rule, and set its validity period. The Discover Service applies active rules to each request. A catalogue entry can therefore be visible to one invoker and absent for another, according to the provider’s settings.

The release also relaxes one naming collision: different API Exposing Functions (AEFs) may publish APIs with the same name. A duplicate from the same AEF still fails. The name is scoped to the thing that exposes it, instead of being treated as a universal reservation.

There is a meaningful standards boundary here. 3GPP introduced CAPIF interconnection in Release 16 and defines the CAPIF-6/6e reference points and security procedures. OpenCAPIF says the specifications leave implementation details of those interfaces open; its Release 5 flow is the SDG’s working proposal within the 3GPP architecture. The distinction matters because this release shows how one implementation handles the gap, down to the handshake and synchronization rules.

The project added 31 tests: 11 for interconnection, 12 for visibility, six for Open Discover and two for same-name APIs across AEFs. That is a map of the release’s work. The operational story sits in the sequence: establish trust, filter what may travel, let an invoker look, then keep each domain’s sharing decision in force.

Sources