Clarify RFC 6750 expectations for SimSwap service API auth failures

[Dusty-IAM]

Problem description
There seems to be a gap in how SimSwap service API authentication failures are currently interpreted. For authorization and token endpoints, CAMARA ICM already points to OAuth2 / OIDC / CIBA behavior. The point here is different: this is about protected resource / service API calls using Bearer access tokens, where the relevant baseline is RFC 6750.

RFC 6750 requires WWW-Authenticate: Bearer challenge semantics for missing / invalid credentials on protected-resource calls, but it does not define one mandatory JSON body format for those failures.

In practice, many implementations handle token authentication in a gateway or resource-server security layer in front of the business service. Because of that, assuming an additional CAMARA-style error body as default behavior for these authentication failures is not always practical. It also forces customizations on critical edge gateways that operators usually want to keep as lean and standard as possible. CAMARA’s own access-and-consent guidance also reflects the separation between access-token based API access and the business logic behind the API.

Expected behavior
The SimSwap specification and/or tests should make it explicit that, for service API authentication failures, RFC 6750 Bearer challenge semantics remain the baseline expectation.

• missing Authorization header → 401 + Bearer challenge
• invalid / expired token → 401 + Bearer challenge with invalid_token
• insufficient scope → 403

The ask is not to forbid additional CAMARA error bodies, but to avoid assuming such bodies as the default behavior of vendor products for protected-resource authentication failures, especially if that would require extra customization on gateway components whose default behavior is already RFC-compliant

Additional context
In our use case, the vendor product in front of the service is RFC-compliant, and there are also public reports from other products where deviations from RFC 6750 protected-resource semantics for invalid/expired Bearer tokens are treated as bugs rather than expected behavior.