Issue with providing the right granular purpose and not over-provisioning access

[questsin]

Issue with providing the right granular purpose and not over-provisioning access

Running into a pure OAuth 2.0 scope syntax problem: need granular CAMARA permissions (“purpose” + specific operation) in a single scope token, but the separator you choose must not conflict with URL encoding or the OAuth scope grammar. More important if using 3rd party out of the box IDPs with brittle scope patterns and consent management.

Legacy Example (original 1 camara scope)
GET/authorize?response_type=code&scope=openid dpv:FraudPreventionAndDetection#sim-swap:check dpv:FraudPreventionAndDetection#sim-swap:retrieve-date offline_access&client_id=s6BhdRkqt3&state=af0ifjsldkj&redirect_uri=https://client.example.org/cbHTTP/1.1Host:server.example.com

New Example (1 camara scope)
GET/authorize?response_type=code&scope=openid dpv:FraudPreventionAndDetection sim-swap:check sim-swap:retrieve-date offline_access&client_id=s6BhdRkqt3&state=af0ifjsldkj&redirect_uri=https://client.example.org/cbHTTP/1.1Host:server.example.com

New Example (2 camara scopes)
GET/authorize?response_type=code&scope=openid dpv:FraudPreventionAndDetection sim-swap:check sim-swap:retrieve-date dpv:IdentityVerification number-verification:device-phone-number offline_access&client_id=s6BhdRkqt3&state=af0ifjsldkj&redirect_uri=https://client.example.org/cbHTTP/1.1Host:server.example.com

Original scopes had “#” like dpv:FraudPreventionAndDetection#sim-swap:check, this was one scope. But “#” isn’t url friendly

New way suggested using spaces like “ “ but this is a reserved as a scope delimiter. Causing over provisioning.

Suggestion to use another delimiter like “-“ and not “:”

Example (original 1 camara scope)
GET/authorize?response_type=code&scope=openid dpv:FraudPreventionAndDetection-sim-swap:check dpv:FraudPreventionAndDetection-sim-swap:retrieve-date offline_access&client_id=s6BhdRkqt3&state=af0ifjsldkj&redirect_uri=https://client.example.org/cbHTTP/1.1Host:server.example.com

[jpengar]

@questsin Thanks for raising this issue. Based on the current CAMARA ICM specifications, I believe this topic mainly stems from a misunderstanding of the existing constraints and design principles.

As discussed in yesterday's ICM meeting (https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/431423509/2025-12-17+ICM+Minutes), let me add the following comments raised during the call for the record:

• At present, CAMARA explicitly allows only one purpose per access token. This is a normative constraint defined in the interoperability profile. As a result:

  • Examples that combine multiple purposes within a single scope string are not valid under the current CAMARA model.
  • Introducing multiple purposes using separators (e.g., different delimiters for scopes vs. purposes) is not supported and would be ambiguous, as it would be unclear which scope applies to which purpose.

• The current format:

  • Uses space-separated scope values, as defined by OAuth.
  • Assumes a single purpose context per authorization request and per access token.

Allowing multiple purposes within the same token is precisely why mechanisms such as Rich Authorization Requests (RAR) are being discussed separately in the WG.