IBM API GW should have a Option to choose Dynamic/Unique Scope Parameter for every new Token

Thank you Siva, for sharing this detailed use case. We appreciate the context around migrating from JMS MQ to an OAuth2-based inbound booking API and the requirements emerging from high-volume, production usage.

We understand the core ask is to support per-transaction token uniqueness, either by:

• Fetching a new OAuth2 token for every transaction (no caching), or

• Supporting a dynamic / unique scope parameter when requesting tokens, rather than a fixed scope value

This is an important consideration for customers with strict security, traceability, or regulatory requirements, especially when moving from stateful messaging (MQ) to stateless APIs.

From a platform perspective, we need to carefully evaluate the impact on token lifecycle management, performance, rate limits, and backward compatibility, while ensuring alignment with OAuth2 best practices and existing SCBN/API Gateway capabilities.

To better assess feasibility and prioritize this enhancement, we’d like to clarify a few points about the intended behavior and constraints.

Clarifying Questions

1. Primary driver: Is the requirement driven mainly by security/compliance, transaction traceability, or a trading partner mandate?

2. Expected behavior: Do you expect a new token per transaction always, or only when the scope value changes?

3. Scope semantics: What does the dynamic scope represent (e.g., transaction ID, booking ID, TP identifier), and must it be unique per request?

4. Token reuse rules: Is it acceptable to reuse an existing token until expiry when the scope remains unchanged, as described in your example?

5. Volume & performance: What is the expected transaction rate, and have you evaluated any latency or token service throttling concerns with per-transaction token generation?