Better support for modern occ communication (i.e. case actions) patterns (REST/OAuth)

Topic of this request are the "case actions" (occ communication) from Safer Payments to any external systems to send/receive data from a cases. Mainly it focuses on the lack of abilities for the “HTTP method” message type that lacks any modern features.

(1) Limited support for modern and common API technologies:

Many modern APIs use the REST/JSON pattern. It is common for those APIs that, depending on the desired action, some data/query parameters is sent either as part of the URI and/or by a custom HTTP Header.

e.g. something like

GET /account/{accountnumber}/status
when READING from a backend system.

or e.g.

POST /account/{accountnumber}/status
when writing to a backend system.

Sometimes sensitive information are moved to a custom HTTP Header. However there are many examples were no personal data is exchanged in this way.

(2) Limited support for authentication:

Most modern API are using OAuth or API-Keys for authentication. Basic Auth does rarely exist anymore, Client certificates are still common but get superseded (or combined!) by API-Keys and/or OAuth patterns.

Problem:

It is impossible to call modern standard APIs with this limited configuration options for HTTP messages. You require some intermediate/proxy application that – technically - rewrites the message from Safer Payments to some proper standard and probably extends the authentication as well.

• (1) Safer Payments OCC configuration settings for HTTP messages currently allows only sending POST messages to backend systems and does only support (dynamic) data in the body of the message. It is not possible to change the HTTP Method (POST/PUT/DELETE/GET). It is also not possible to add custom HTTP headers in a call and to place dynamic data (using the template syntax with curly brackets) anywhere else than in the message body.
  

• (2) Safer Payments only supports Client certificates and Basic Auth. There is no option for using API-Keys or OAuth, at least the server-to-server communication with Client-ID & Key (Client credential flow) should be supported.

Solution:

Provide a more modern OCC / “HTTP method” message type, that:

• Allows the change of the HTTP Method (e.g. POST/PUT/DELETE/GET)

• Allows dynamic parameters in the URI of the target resource as well (not only body template, but additionally to using the body template).

• Allows the addition of HTTP headers for a HTTP request and also support dynamic parameters in those HTTP headers.

• Allow the usage of API-Keys (probably can be solved with feature (3) as well, as API-Keys are nothing else than custom http headers with a static ID).

• This is the most complex and probably a different topic: Add support for at least the OAuth 2.0 Client-credentials flow that is commonly used for server-to-server communication.