Added flow to interconnection section

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

### Aquire Access token

### Creation of Security Context by invoker onboarded on different CCF than Provider

From the point of view of Invoker and Providers, the access to exposed APIs follow the same flows for one CCF, this means:

1. Provider will Register itself and publish APIs to their own CCF.

2. Invoker will onboard and discover APIs to their own CCF.

3. Invoker request creation of security context of any of APIs discovered.

From the point of view of all entities, the interaction will be the same, but when the Provider and Invoker are in differen CCFs, internally the flows change.

When Invoker request creation of Security Context to an API registered on interconnected CCF, then Invoker's CCF will request creation of security context con Provider's CCF. This will trigger creation of ACLs and some other events related.

![Interconnection Security Context Creation](../images/interconnection/01_Creation_of_Security_Context_Same_Vault.png)

After creation there will be 3 different flow involved depending on selSecurityMethod returned by Invoker's CCF:

* OAUTH: Access token will be used to access exposed API.

* PKI: Invoker must use their certificate to access exposed API.

* PSK: Invoker must derive they PSK key from connexion between invoker and CCF.

NOTE: PSK and PKI security methods imply Provider must implement AEF_security_API defined by 3GPP, because Invoker will begin the communication to exposed api by requesting POST to /check-authentication with [body](./check-authentication.json). 

We will see each security method flow in next sections.

#### OAUTH

For OAUTH security method,

* Provider only needs public key of its CCF (Provider's CCF).

* Invoker will request access token to its CCF (Invoker's CCF).

* Invoker's CCF will request internally to Provider's CCF the access token to be forwarded to Invoker.

* Invoker reach exposed API by including access token inside Authorization header at request.

![Interconnection Oauth](../images/interconnection/02_OAuth.png)

Summary:

In this scenario, Invoker's CCF acts as a gateway to forward request to Provider's CCF, because this token will be created by private certificate of Provider's CCF.

#### PKI

For PKI security method,

* Provider must implement AEF_Security_API, defined by 3GPP. The check-authentication endpoint must be requested from Invoker before initiate consumption of exposed API, indicating api_invoker_id.

* Provider will request security context of api_invoker_id to Provider's CCF, and Provider's CCF will request security context to Invoker's CCF and this security context will be forwarded to Provider, which includes the ca root to decode invoker's certificate.

* Provider will take authenticationInfo present at security_info array inside GET security context response and store it to be used later.

* Invoker reach exposed API by including its certificate.

* Provider validate invoker's certificate, and checks api_invoker_id at CN.

![Interconnection PKI](../images/interconnection/03_PKI.png)

#### PSK

For PSK security method,

* Invoker derived PSK when request creation of Security Context and store it to be used later.

* Provider must implement AEF_Security_API, defined by 3GPP. The check-authentication endpoint must be requested from Invoker before initiate consumption of exposed API, indicating api_invoker_id.

* Provider will request security context of api_invoker_id to Provider's CCF, and Provider's CCF will request security context to Invoker's CCF and this security context will be forwarded to Provider, which includes the ca root to decode invoker's certificate and PSK derived by Invoker's CCF.

* Provider will take authenticationInfo, and authorizationInfo present at security_info array inside GET security context response and store them to be used later.

* Invoker reach exposed API including PSK inside Authorization header.

* Provider validate invoker's PSK towards PSK present on authorizationInfo in security context obtained.

![Interconnection PSK](../images/interconnection/04_PSK.png)

... to be added

 No newline at end of file