Allow third-party services to intercept / change OCPI requests

[ewf-devops]

Original report by Christopher Burgahn (Bitbucket: [Christopher Burgahn](https://bitbucket.org/Christopher Burgahn), ).

---

What is the motivation / use case for the feature?

The current implementation of the OCN Service Interface (Permissions and their OCN Node implementation) allows forwarding of OCPI requests. A useful addition to that could be “interception / changing of OCPI requests”. Some third-party services may need the option to intercept and change OCPI requests that are sent between two OCPI parties via the OCN. An example could be that a location is PUT by the CPO to the eMSP. A location enhancement service is then intercepting this request, changing the lat. & long. to optimize it for the eMSP, and will then forward it to the eMSP.

What are the requirements (or acceptance criteria) for the feature?

• Third-party service (OCN Service) can define permissions on basis of the OCPI modules / interfaces in the permissions contract
• OCN Users can sign up for those permissions
• Based on given permissions the OCN Node intercepts OCPI requests and forwards them to the OCN Service
• The OCN Service is then allowed to sent a modified OCN request to the originally intended recipient of an OCPI request

Any suggested implementation approaches?

Needs to be discussed

[ewf-devops]

Original comment by Adam Staveley (Bitbucket: [Adam Staveley](https://bitbucket.org/Adam Staveley), GitHub: adamstaveley).

---

Had a few ideas about the implementation. We could have either:

• Service needs to forward the message to the original recipient and make sure it responds with the recipient’s response (not its own).
• Service responds to the sending OCN Node with the modified request and the sending OCN Node forwards it, responding to the sender with the recipient’s response.

I much prefer the first option as the second option is not compatible with OCPI (would require responding to a request with another request).

[ewf-devops]

Original comment by Adam Staveley (Bitbucket: [Adam Staveley](https://bitbucket.org/Adam Staveley), GitHub: adamstaveley).

---

As an aside, we might consider grouping permission IDs together (how status codes work). If we implement this we will have 0-40 IDs which aren’t very descriptive. A better approach could be to have:

• 1xxx codes for message forwarding
• 2xxx codes for message interception

and so on. This would also be compatible with the existing permissions smart contract which only requires that IDs are uint256.

[ewf-devops]

Original comment by John Henderson (Bitbucket: [John Henderson](https://bitbucket.org/John Henderson), GitHub: jrhender).

---

Interesting proposal, seems like a powerful feature!

@{5efc3c2c54020e0ba82c6e64} Good idea re the permission ID semantics. We could add 1000 to existing permissions to migrate or, at the very least, just have the newly defined permissions for interception start at 2xxx and leave the existing permissions as is.

Nice initial thinking on the implementation approaches 👍

For approach 1 (Service forwards message), I think that we would need to augment/modify the OCPI message format somehow, as when the OCN Node would forward the message to the service, the original destination party-id and country-code headers would be lost (as they would replaced with the service’s). We could, for instance, add HTTP headers like original-OCPI-to-country-code . I think this information would also often useful to a service when receiving a forwarded request (in addition to requests they are intercepting).

Approach 2 seems like more effort from an OCN Node standpoint but one advantage may be that it provides a simpler, more intuitive mental model of the service acting as a filter or middleware (at least I find that intuitive).

[ewf-devops]

Original comment by Adam Staveley (Bitbucket: [Adam Staveley](https://bitbucket.org/Adam Staveley), GitHub: adamstaveley).

---

@{5efed1cdf34eae0ba6f4d21c} yes, I was thinking something similar with the additional header. This wouldn’t affect normal usage of the OCN and would only require the service to accept it (which they should). The service would also change the from OCPI headers, so we might also consider an original sender header as well, for the original recipient’s benefit. All this can be gleaned from the signature, but as I think we discussed in our last developer call, the API to retrieve such information from the Notary needs to be improved. Additionally, whilst signatures are still optional, we should provide the headers as well.

[ewf-devops]

Original comment by Adam Staveley (Bitbucket: [Adam Staveley](https://bitbucket.org/Adam Staveley), GitHub: adamstaveley).

---

Btw, I wonder if we can automate the setting of these headers:

• Sending OCN Node automatically sets the Original-OCPI-To headers because they change the sender.
• If the service has not set the Original-OCPI-From headers, the OCN can automatically apply them (needs to figure it out from the signature).

And maybe OCPI-origin-to/from is better as it puts the application type first. We could also name it OCN-origin-to/from instead, so that users know this is an OCN-specific header.

[ewf-devops]

Original comment by John Henderson (Bitbucket: [John Henderson](https://bitbucket.org/John Henderson), GitHub: jrhender).

---

Notes from 2020-10 Developer Community call discussion:

• Possible use cases:

  • Dynamic pricing (MSP asks for pricing and answer is routed via DSO which can charge more underload) → This would require intercepting responses
  • Reservation service (MSP asks for state and a 3rd-party is able to provide this information)

• Intercepting response could be complicated as some use cases (such as the dynamic pricing use case above) may require data from multiple parties

• Another technique to “Approach 2” as suggested by Adam may be to use a callback URL

• Though signatures (i.e. a “history” API provided by the OCN Notary) would be an elegant technique for “Approach 1”, signatures are not currently mandatory in the OCN. However, signatures are highly encouraged in production and we could perhaps require that they be enabled for certain features. Signature history would be nice because it would allow for multiple hops.

• Additional example use cases would be helpful to determine all of the necessary requirements

‌