Add sequence diagrams

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.

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: 

- publish, retrieve, update and unpublish service APIs information

- discover service APIs

- obtain security information for the API invoker upon accessing the service API, and 

- provide authorization for the API invoker prior to accessing the service API.

More information on CAPIF Interconnection can be found on the following Technical Specification documents:

- 3GPP TS 23.200

  - 6.2.2 Functional model description to support CAPIF interconnection

  - 8.25 Support for CAPIF interconnection

  - 6.13 Security procedures for CAPIF interconnection

## Specification Compliance and Extensions

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:

- Provide clear extension points for future standardization updates

- Ensure robust security and reliability across domain boundaries

## Implementation Approach

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.

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

DELETE /helper/interconnection/request/{peerCcfId}

1. Peer DELETE /establish/{localCcfId}

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

1. Looks up the caller in interconnected by dstProvDom (404 if missing).

2. Publishes (to the interconnected CCF) every local API that matches:

- shareableInfo.isShareable == true

- peer domain in shareableInfo.capifProvDoms

- apf_id is not the peer CCF (no bounce-back)

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

4. The payload sets shareableInfo.isShareable = false so the peer does not re-share.

5. Records the peer in pubApiPath.ccfIds

1. The payload sets shareableInfo.isShareable = false so the peer does not re-share.

2. Records the peer in pubApiPath.ccfIds

When CCF-B answers, CCF-A does the same in the other direction.

_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._ 

*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.* 

![CAPIF Interconnection](../images/interconnection/CAPIF_Interconnection_Establishment.png)

### Discover

1. Normal duplicate / feature checks.

2. Read shareableInfo:

- isShareable is false or missing → local publish only.

- isShareable is true → take capifProvDoms.

3. 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).

4. If any peer fails → withdraw copies already accepted, do not store locally, return 500.

5. On success, store locally and set pubApiPath.ccfIds to the peers that got a copy.

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

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

1. 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).

2. If any peer fails → withdraw copies already accepted, do not store locally, return 500.

3. On success, store locally and set pubApiPath.ccfIds to the peers that got a copy.

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

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

![Interconnection Publish POST](../images/interconnection/CAPIF_Publish_after_interconnection.png)

In case of a PUT / PATCH request:

Peers are aligned before the local write:

- domains removed from capifProvDoms → DELETE on those peers

- domains kept → PUT the new definition

- domains added → POST

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

![Interconnection Publish PUT PATCH DELETE](../images/interconnection/CAPIF_Publish_update_and_delete_across_CCFs.png)

### Aquire Access token

... to be added

 No newline at end of file