Problem description
There have been several discussion rounds on the format of the scope parameter in the access token request. The agreement for the short term solution describes a proprietary format and has been included in
(1) CAMARA-API-access-and-user-consent-management.md (IdentityAndConsentManagement/documentation/CAMARA-API-access-and-user-consent.md at main · camaraproject/IdentityAndConsentManagement (github.com)).
Another document describes the generic handling of access tokens. This is
(2) CAMARA-AuthN-AuthZ-Concept.md document (https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-AuthN-AuthZ-Concept.md ).

Here it is stated that: Access tokens should be signed and encoded as JWT (Json Web Token), with the bearer type specified.
In the very same document it is stated that the resulting token must be checked (and therefore contain claims) on:
• Expiry of the token (exp_claim)
• Issuer recognized as a trusted issuer (iss_claim)
• Consumer whitelisted in ACL list (azp_claim)

However, the format of scope claim as consequence of description in (1) for access and consent management and the handling of purpose are not documented. This needs to be agreed urgently, since the service implementations usually evaluate the content of the access token and therefore must know what to expect.

Even though the authorization request uses a custom format for the scope parameter (and includes the purpose in it), this is not allowed in the resulting access token. According to the standard RFC 8693: OAuth 2.0 Token Exchange (rfc-editor.org), 4.2, the value of the scope claim is a JSON string containing a space-separated list of scopes associated with the token, in the format described in Section 3.3 of [RFC6749].
From RFC 6749: The value of the scope parameter is expressed as a list of space-
delimited, case-sensitive strings. The strings are defined by the
authorization server. If the value contains multiple space-delimited
strings, their order does not matter, and each string adds an
additional access range to the requested scope.

Expected action
Thus the scope claim in the access token must have the exact same values as the scope strings defined in the API definition registered with the authorization server.
In case the API name as “bundle scope” is used in the scope request, this bundle scope must be extended to the individual list of scopes as contained in the API definition.

The purpose parameter should be included in the access token as well, but cannot be conveyed in the scope claim of the access token without breaking the standard RFC 8693. Thus the purpose parameter should be included in the access token in a separate claim.
Our proposal is to use “crn” claim describing the call reason. This is a public claim specified by JSON Web Token (JWT) (iana.org). It has been introduced with RFC-ietf-stir-passport-rcd-26 (draft-ietf-stir-passport-rcd-26 - PASSporT Extension for Rich Call Data).
Alternatively, a new claim, e.g. called “purpose” could be requested.

Additional context and example
An example for an access token generated on an authorize request for SIM-SwaP API would then look like:

GET /authorize?response_type=code&client_id=myApp&client_secret=0xahh23457& scope=“dpv:fraud-prevention#check-sim-swap” & redirect_url=aggregator_callback

{
"iss": https://mycsp.auth0.com/,
"sub": "+46772334567",
"aud": " https://mycsp.com/APIexposureService ",
"exp": 1490922820,
"iat": 1490886820,
“client_id”:0x3445a2,
“azp”:”coolApp”,
"scope": " check-sim-swap ",
"crn": " dpv:fraud-prevention "
}

When the request contains the API name instead of a single technical scope (as exemplified below), then the generated access token must contain the list of data scopes provided by the API.

GET /authorize?response_type=code&client_id=myApp&client_secret=0xahh23457& scope=“dpv:fraud-prevention#sim-swap” & redirect_url=aggregator_callback

{
"iss": https://mycsp.auth0.com/,
"sub": "+46772334567",
"aud": " https://mycsp.com/APIexposureService ",
"exp": 1490922820,
"iat": 1490886820,
“client_id”:0x3445a2,
“azp”:”coolApp”,
"scope": "check-sim-swap retrieve-sim-swap-date",
"crn": " dpv:fraud-prevention "
}

Additional context