Extending the technical scope from one technical scope to a parameters list of technical scopes.

[FrimanJan]

Issue #32 describes a short term solution on how to convey purpose and data scope on the access token request. The issue was closed with the agreement to open a new issue for the mid term solution, which is aligned to the standard and overcomes the short term limitations.

As of today the short term solution (documented in IdentityAndConsentManagement/documentation/CAMARA-API-access-and-user-consent.md at main · camaraproject/IdentityAndConsentManagement (github.com) describes the following format for sending in purpose and data scope in an access token / access code request:

dpv:\#\ • \ is coming from W3C DPV purpose definition • \ must be either: o one technical scope to limit the request to one API endpoint (this technical scope is described in the API spec YAML file) o one API name to cover the complete API (This API name is not described in the API spec YAML file as technical scope) – In this case the request covers all technical scopes of the API.

Going forward the limitation of one technical scope only must be lifted and sending in a list of technical scope parameters separated by “blank” must be possible. The target format is dpv:\<dpvValue>#\<technical scope 1> \<technical scope 2> … \

The resulting access token will contain the purpose (\<dpvValue) and the permitted scope list-

However, this applies to data scope only. In on access token request only one purpose (dpvValue) will be supported.

[bigludo7]

@FrimanJan In your proposal to allow a list of technical scope do you mean a list of technical scope for the same API or a list of technical scope that can cover distinct APIs ?

[Elisabeth-Ericsson]

To start with, it should be possible to specify technical scopes for the SAME API to avoid the non standard solution with the catch all scope. Furthermore, it should be noted, that the format of the access token generated for the request has not been specified yet. As documented in the standard, the resulting access token contains various claims, amongst them the list of permitted data scopes. Here this must be the list of data scopes as specified in the YAML file describing the API. As a consequence the AuthZ server must expand the "bundle scope", hidden behind the API name into a blank-separated list of the scopes defined for the API and put this list in the scope claim. A separate issue should be opened to discuss the final format of the access token.

[shilpa-padgaonkar]

+1 for lifting limitation of one technical scope only +1 to start with SAME API

[Elisabeth-Ericsson]

In rel 0.2 we need to start lifting the limitations from the short-term agreement. As documented in pull request #113, the scope parameter passed in the access token request should allow for multiple scopes, However, it must be assured that token is requested for exactly ONE purpose. The purpose and the resulting scopes (potentially a list) must be present in the access token response (if JWT format is used), other wise in the data structure referenced by an opaque access token.

[jpengar]

In rel 0.2 we need to start lifting the limitations from the short-term agreement. As documented in pull request #113, the scope parameter passed in the access token request should allow for multiple scopes, However, it must be assured that token is requested for exactly ONE purpose. The purpose and the resulting scopes (potentially a list) must be present in the access token response (if JWT format is used), other wise in the data structure referenced by an opaque access token.

As discussed in the last WG call (31/01), this issue would be part of the enhancement discussion for v0.3. In release 0.2, it's proposed to include a first version of the OIDC profile focusing on urgent issues/open questions that arise due to open interpretations of release 0.1. (e.g. clarify possible error codes, required fields that weren't clear, clarify whether private_key_jwt or client_secret_basic should be used since the current docs are ambiguous, etc).

[hdamker]

Just a short naive question: if the "openid" scope is mandatory doesn't that mean that there are always multiple scopes listed with blanks between?