Skip to Main Content
IBM Data and AI Ideas Portal for Customers

This portal is to open public enhancement requests against products and services offered by the IBM Data & AI organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas

Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

IBM Employees should enter Ideas at

Status Submitted
Workspace IBM Safer Payments
Components Technical
Created by Guest
Created on Feb 20, 2024

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.


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.


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.

Needed By Quarter