Fix some typos and rephrase

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

### Creation of Security Context

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

For Invokers and Providers belonging to a common CCF, the access to exposed APIs follow the same flows:

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

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

3. Invoker request creation of a security context for any of APIs discovered to its own CCF.

1. Provider registers itself and publishes APIs to the CCF.

2. Invoker onboards and discovers APIs to the CCF.

3. Invoker requests creation of a security context for 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. The internal flow will be explained below.

However, when Provider and Invoker belong to different CCFs, internally the flows change. The specific flows are explained below.

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.

When Invoker requests creation of security context for an API published on interconnected CCF, then Invoker's CCF will request creation of security context from the Provider's CCF. This will trigger creation of Access Control Lists (ACLs) and some other related events.

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

On next section the flows involved depending on security method selected will be detailed.

On next section the flows involved on security method selection will be detailed.

### Consume Provider's API

Previous section created the security context to allow communicaction from Invoker and Provider's API. There will be 3 different flow involved depending on **selSecurityMethod** returned by Invoker's CCF:

There are 3 different flows involved, depending on **selSecurityMethod** returned by Invoker's CCF:

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

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

* **PSK**: Invoker must derive the PSK key from connexion between invoker and CCF at context creation.

* **PSK**: Invoker must derive the PSK key from the connection between invoker and CCF at context creation.

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

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

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

* Invoker will request an 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.

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

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

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. [body](./check-authentication.json)

* Provider must implement *AEF_Security_API*, defined by 3GPP. The *check-authentication* endpoint must be requested from Invoker before initiating consumption of any exposed API, indicating api_invoker_id. [body](./check-authentication.json)

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

* Invoker reaches exposed API by including its own certificate.

* Provider validates invoker's certificate, and checks api_invoker_id at the Common Name (CN) field.

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

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. [body](./check-authentication.json)

* Invoker derives PSK when requests creation of Security Context and stores it to be used later.

* Provider must implement *AEF_Security_API*, defined by 3GPP. The *check-authentication* endpoint must be requested from Invoker before initiating consumption of exposed API, indicating api_invoker_id. [body](./check-authentication.json)

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

* Invoker reaches exposed API including PSK inside Authorization header.

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

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