Deployed 6e211373 to develop in public with MkDocs 1.6.1 and mike 2.2.0

    </span>

  </a>

</li>

        <li class="md-nav__item">

  <a href="#specification-compliance-and-extensions" class="md-nav__link">

    <span class="md-ellipsis">

        Specification Compliance and Extensions

    </span>

  </a>

</li>

        <li class="md-nav__item">

    </span>

  </a>

    <nav class="md-nav" aria-label="Implementation Approach">

      <ul class="md-nav__list">

          <li class="md-nav__item">

  <a href="#interconnection-establishment-and-syncronization" class="md-nav__link">

    <span class="md-ellipsis">

        Interconnection establishment and syncronization

    </span>

  </a>

</li>

          <li class="md-nav__item">

  <a href="#key-features" class="md-nav__link">

  <a href="#discover" class="md-nav__link">

    <span class="md-ellipsis">

        Key Features

        Discover

    </span>

  </a>

</li>

          <li class="md-nav__item">

  <a href="#specification-compliance-and-extensions" class="md-nav__link">

  <a href="#publish" class="md-nav__link">

    <span class="md-ellipsis">

        Specification Compliance and Extensions

        Publish

    </span>

  </a>

</li>

          <li class="md-nav__item">

  <a href="#aquire-access-token" class="md-nav__link">

    <span class="md-ellipsis">

        Aquire Access token

    </span>

  </a>

</li>

      </ul>

    </nav>

</li>

    </ul>

    </span>

  </a>

</li>

        <li class="md-nav__item">

  <a href="#specification-compliance-and-extensions" class="md-nav__link">

    <span class="md-ellipsis">

        Specification Compliance and Extensions

    </span>

  </a>

</li>

        <li class="md-nav__item">

    </span>

  </a>

    <nav class="md-nav" aria-label="Implementation Approach">

      <ul class="md-nav__list">

          <li class="md-nav__item">

  <a href="#interconnection-establishment-and-syncronization" class="md-nav__link">

    <span class="md-ellipsis">

        Interconnection establishment and syncronization

    </span>

  </a>

</li>

          <li class="md-nav__item">

  <a href="#key-features" class="md-nav__link">

  <a href="#discover" class="md-nav__link">

    <span class="md-ellipsis">

        Key Features

        Discover

    </span>

  </a>

</li>

          <li class="md-nav__item">

  <a href="#specification-compliance-and-extensions" class="md-nav__link">

  <a href="#publish" class="md-nav__link">

    <span class="md-ellipsis">

        Specification Compliance and Extensions

        Publish

    </span>

  </a>

</li>

          <li class="md-nav__item">

  <a href="#aquire-access-token" class="md-nav__link">

    <span class="md-ellipsis">

        Aquire Access token

    </span>

  </a>

</li>

      </ul>

    </nav>

</li>

    </ul>

<h1 id="opencapif-interconnection">OpenCAPIF Interconnection</h1>

<h3 id="overview">Overview</h3>

<p>OpenCAPIF Interconnection is a new functionality designed to enable seamless communication and service integration between multiple Common API Framework (CAPIF) domains, following the 3GPP specifications for CAPIF-4 and beyond. This implementation represents the first version of interconnection capabilities within the OpenCAPIF ecosystem.</p>

<h3 id="implementation-approach">Implementation Approach</h3>

<p>This implementation adheres to the 3GPP Common API Framework specifications while addressing areas where the standards provide limited definition or flexibility. We have adapted and extended the specification-defined interfaces to accommodate the specific architectural requirements of OpenCAPIF, ensuring compatibility with existing deployments while enabling cross-domain service discovery and invocation.</p>

<h3 id="key-features">Key Features</h3>

<h2 id="overview">Overview</h2>

<p>3GPP Release 16 introduced CAPIF Interconnection to enable distributed deployments and interactions between different API providers. This enhancement allowed multiple CCFs — either of the same or different trust domains — to seamlessly interact, discover services, and publish APIs with one another. At the same time, CAPIF Interconnection enables API invokers to utilize the service APIs from 3rd party API providers.</p>

<p>According to the specifications, CAPIF-6 or CAPIF-6e reference points have been defined to enable communication between two CCFs. Through those interfaces CCFs can: </p>

<ul>

<li><strong>Cross-Domain Service Connectivity</strong>: Facilitates secure communication between CAPIF domains with standardized authentication and authorization mechanisms</li>

<li><strong>Service Discovery and Registration</strong>: Enables services to be discovered and registered across interconnected domains following 3GPP guidelines</li>

<li><strong>Adaptive Implementation</strong>: Custom implementations for specification gaps, designed to be interoperable and extensible for future standard updates</li>

<li>publish, retrieve, update and unpublish service APIs information</li>

<li>discover service APIs</li>

<li>obtain security information for the API invoker upon accessing the service API, and </li>

<li>provide authorization for the API invoker prior to accessing the service API.</li>

</ul>

<h3 id="specification-compliance-and-extensions">Specification Compliance and Extensions</h3>

<p>More information on CAPIF Interconnection can be found on the following Technical Specification documents:</p>

<ul>

<li>3GPP TS 23.200</li>

<li>6.2.2 Functional model description to support CAPIF interconnection</li>

<li>8.25 Support for CAPIF interconnection</li>

<li>3GPP TS 33.122</li>

<li>5.3 Functional security model supporting interconnection</li>

<li>6.13 Security procedures for CAPIF interconnection</li>

</ul>

<h2 id="specification-compliance-and-extensions">Specification Compliance and Extensions</h2>

<p>Our approach balances strict adherence to 3GPP standards with pragmatic engineering solutions. Where the 3GPP specifications do not fully define implementation details, we have made informed design decisions that:</p>

<ul>

<li>Maintain backward compatibility with existing OpenCAPIF implementations</li>

<li>Provide clear extension points for future standardization updates</li>

<li>Ensure robust security and reliability across domain boundaries</li>

</ul>

<h2 id="implementation-approach">Implementation Approach</h2>

<p>OpenCAPIF implementation of interconnection adheres to the 3GPP specifications while addressing areas where the standards provide limited definition. We have adapted and extended the specification-defined interfaces to accommodate the specific architectural requirements of OpenCAPIF, ensuring compatibility with existing deployments while enabling cross-domain service discovery and invocation.</p>

<p>OCF Release 5 implements a functional version of CAPIF interconnection capability, including all the neccessary steps described below.</p>

<h3 id="interconnection-establishment-and-syncronization">Interconnection establishment and syncronization</h3>

<p>Interconnection establishment is initiated by the CAPIF administrator of a local CCF (CCF-A), using the "/request" API, towards a peer CCF (CCF-B).

More specifically:</p>

<p>POST /helper/interconnection/request with { "dstProvDom": "CCF-B host:port" }</p>

<ol>

<li>If dstProvDom is already in interconnected → 409.</li>

<li>CCF-A calls CCF-B: POST https://{dstProvDom}/helper/interconnection/establish over mTLS, sending CCF-A’s ccfId, domain, CA, and public key.</li>

<li>CCF-B stores A in interconnected and replies with B’s own identity.</li>

<li>CCF-A stores that reply, then runs sync (below).</li>

</ol>

<p>CCF administrator (either A or B) can also tear down the connection between the two CCFs</p>

<p>DELETE /helper/interconnection/request/{peerCcfId}</p>

<ol>

<li>Peer DELETE /establish/{localCcfId}</li>

<li>On success, drop services whose apf_id is the peer CCF, pull that CCF from pubApiPath.ccfIds, delete the interconnected row.</li>

</ol>

<p>After establishing the interconnection, the CCFs have to syncronize the state of the shared APIs. This is managed via the "/sync" API.</p>

<p>POST /helper/interconnection/sync from CCF-A to CCF-B.</p>

<p>On "/sync", the receiving CCF:</p>

<ol>

<li>Looks up the caller in interconnected by dstProvDom (404 if missing).</li>

<li>

<p>Publishes (to the interconnected CCF) every local API that matches:</p>

</li>

<li>

<p>shareableInfo.isShareable == true</p>

</li>

<li>peer domain in shareableInfo.capifProvDoms</li>

<li>apf_id is not the peer CCF (no bounce-back)</li>

<li>peer CCF not already in pubApiPath.ccfIds</li>

</ol>

<p>POST https://{dstProvDom}/published-apis/v1/{srcProvDom}/service-apis.</p>

<ol>

<li>The payload sets shareableInfo.isShareable = false so the peer does not re-share.</li>

<li>Records the peer in pubApiPath.ccfIds</li>

</ol>

<p>When CCF-B answers, CCF-A does the same in the other direction.</p>

<p><em>CAPIF-related 3GPP standards have not yet defined exact procedures of CAPIF-6(e) interface. All the above API definition and flows are a proposed implementation of OpenCAPIF SDG contortium.</em> </p>

<p><img alt="CAPIF Interconnection" src="../../images/interconnection/CAPIF_Interconnection_Establishment.png" /></p>

<h3 id="discover">Discover</h3>

<p>Discover API has no interconnection-specific logic. It only queries the local service_api_descriptions collection and returns matching APIs. shareableInfo, pubApiPath, and ccfId appear because they are part of the 3GPP ServiceAPIDescription schema, and Discover includes them in the response</p>

<h3 id="publish">Publish</h3>

<p>When the interconnection capability is enabled in CCFs, the publish API flow (POST) includes the following: </p>

<ol>

<li>Normal duplicate / feature checks.</li>

<li>

<p>Read shareableInfo:</p>

</li>

<li>

<p>isShareable is false or missing → local publish only.</p>

</li>

<li>

<p>isShareable is true → take capifProvDoms.</p>

</li>

<li>

<p>For each domain, look up interconnected by dst_prov_dom. Unknown domain → skip. Known domain → POST the copy to that peer’s Publish API (same URL as sync, isShareable: false).</p>

</li>

<li>If any peer fails → withdraw copies already accepted, do not store locally, return 500.</li>

<li>On success, store locally and set pubApiPath.ccfIds to the peers that got a copy.</li>

<li>If the caller’s apfId contains "CCF" (incoming from a peer), that CCF is also appended to the path.</li>

<li>Cert/APF checks are skipped when the client CN is superadmin or starts with CCF. Interconnected publications have no local APF cert entry.</li>

</ol>

<p><img alt="Interconnection Publish POST" src="../../images/interconnection/CAPIF_Publish_after_interconnection.png" /></p>

<p>In case of a PUT / PATCH request:</p>

<p>Peers are aligned before the local write:</p>

<ul>

<li>domains removed from capifProvDoms → DELETE on those peers</li>

<li>domains kept → PUT the new definition</li>

<li>domains added → POST</li>

<li>sharing turned off → unpublish from all previous domains</li>

</ul>

<p>Peer copies are found by old apiName, because each peer assigns its own apiId. If any peer cannot be aligned, the local API is left unchanged.</p>

<p>In case of a DELETE request:</p>

<p>Unpublish from peers first, then delete locally. If a peer is unreachable, the local copy stays so the two CCFs do not drift.</p>

<p><img alt="Interconnection Publish PUT PATCH DELETE" src="../../images/interconnection/CAPIF_Publish_update_and_delete_across_CCFs.png" /></p>

<h3 id="aquire-access-token">Aquire Access token</h3>

<p>... to be added</p>