Problems in Authorization Code with scope and mutliple Credential Datasets

[paulbastian]

Imagine a basic scenario where a Wallet wants to request multiple Credentials with different Credential Datasets, e.g. multiple ePrescriptions. The challenge is how a Wallet knows how many Credential Requests to do.

Within Authorization Code Flow with authorization_details, the Wallet can deduct the number of Credential Datasets from the Token Response with credential_identifiers array size.

Within Authorization Code Flow with scope, this method does not work (as it is specific to authorization_details) and the Wallet may need to send requests until it gets an error, which seems to be insufficient.

Proposal could be to allow credential_identifiers for all flows. Changes discussed in #294 are also relevant.

[babisRoutis]

@paulbastian Completely agree

Scopes not supporting credential_identifiers is a common problem for organizations that try to implement VCI by leveraging existing authorization servers that typically don't support authorization_details,

Yet, I wish there was an option to send credential_identifiers via a credential offer. In this way, wallet could inform its holder that the offer is about a specific number of ePrescriptions, before asking his consensus to proceed with the issuance.

[peppelinux]

I would also add the evidence that using a set of scopes defined withing a framework, such as a large global network, national or small one shared within one or few domains, we're technically able to specify any kind of credential type (and format) without the requirement of using authorization details

an example could be the set of digital credentials of interest for a national public sector network. These will be uniquely identified, even better using not colliding URIs, and used efficiently within the scope parameter, enabling the preexisting plugin systems already implemented in the ASs for the authorization by scopes instead of a more complex one using authorization details

eg:

scope=https://eid.gov.example.com/health/card/00 https://eid.gov.example.com/mdl/iso/1

[babisRoutis]

@peppelinux I have the impression though that this proposed use of scopes cannot be used when issuance requires one or more credential_identifiers (like in the prescription example mentioned above), given that scopes are advertised via (static) metadata.

[peppelinux]

@babisRoutis I use these elements in my analysis

1. scope is an authorization request parameter usable with the authorization endpoint
2. scope is a multivalued field, therefore it can carry multiple values
3. scope is flexible, since we can use common scopes used in the oauth/openid framework or new ones specified in whatever framework or use user claim names and therefore it may use credential identifier as well
4. it can also be asserted within the metadata of the participants, scopes_supported in recommended in openid connect discovery and scope in OAuth 2.0 Dynamic Client Registration Protocol for the RP

[babisRoutis]

@babisRoutis I use these elements in my analysis

1. [scope](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.1) is an authorization request parameter usable with the authorization endpoint

2. scope is a multivalued field, therefore it can carry multiple values

3. scope is flexible, since we can use common scopes used in the oauth/openid framework or new ones specified in whatever framework or use user claim names and therefore it may use credential identifier as well

4. it can also be asserted within the metadata of the participants, `scopes_supported` in recommended in openid connect discovery and `scope` in OAuth 2.0 Dynamic Client Registration Protocol for the RP

Dear @peppelinux
Yes all the points that you mention make sense.

Yet this issue was about how to convey (if needed) the credential_identifiers. By not using authorization_details - that is, favoring scopes - there is no way currently for the issuer to communicate those credential identifiers to the wallet.

I got the impression that you were proposing to "encode" into scope those identifiers.

[peppelinux]

Yet this issue was about how to convey (if needed) the credential_identifiers. By not using authorization_details - that is, favoring scopes - there is no way currently for the issuer to communicate those credential identifiers to the wallet.

the VCI metadata are suitable for this. The Wallet Instance discovers within the eidas federation the credentials available for each VCI. This is the purpose of the metadata allowing a good interoperability between the entities.

[paulbastian]

How scope is currently designed in VCI, it is a 1:1 relationship to Credential Configuration. You could do a separate Credential Configuration to "simulate" Credential Dataset, but this seems contradictory to the terminology that we agreed upon.

For me it would be okay to use scope for simple use cases that inhernetly only have one Credential Dataset and use authorization_details for more complex scenarios. I just wanted to highlight the limitations that I currently see with scopes. Is it fish or meat, i.e. is it Credential Configuration or Credential Dataset?

[peppelinux]

the scope of my request is to obtain the PID, therefore I put the PID identifier into the scope parameters, within the request.

I would say that it aims to be the simplest thing we may have, or at least try to achieve this kind of simplicity, without creating conflicts with any other more complex configurations

[paulbastian]

Using scope for PID is fine, as there is usually only one Credential Dataset for the PID issuance.

For other use cases like ePrescription, you may not want 5000 Credential Configurations but instead 5000 potential Credential Datasets, otherwise your metadata may explode.

[Sakurann]

Yet, I wish there was an option to send credential_identifiers via a credential offer. In this way, wallet could inform its holder that the offer is about a specific number of ePrescriptions, before asking his consensus to proceed with the issuance.

@babisRoutis there is already an option to pass credential_configuration_ids in credential offer? and there is a proposal in #294 to allow using credential_configuration_ids in credential request.

[Sakurann]

How scope is currently designed in VCI, it is a 1:1 relationship to Credential Configuration.

@paulbastian as we discussed, there are also implementations that use the same scope value for the same credential_configuration_ids

[babisRoutis]

Yet, I wish there was an option to send credential_identifiers via a credential offer. In this way, wallet could inform its holder that the offer is about a specific number of ePrescriptions, before asking his consensus to proceed with the issuance.

@babisRoutis there is already an option to pass credential_configuration_ids in credential offer? and there is a proposal in #294 to allow using credential_configuration_ids in credential request.

Hi @Sakurann My wish was about credential_identifiers, not credential_configuration_ids :smile:

In this thread, we discussed some problems of having to use (as an constraint) an ordinary authorization server.

Currently (d13), if you have to implement an issuance process that requires the use of credential identifiers (same credential_cfg_id, different data), and in addition if you have to use a legacy server, then you are facing a dead-end.

Hence I find too restrictive that you can get those identifiers only via authorization_details.

I am already facing this problem, and the temporary workaround iis to use a custom endpoint that exchanges the access_token with the authorization_details (sort of) that the legacy server cannot provide and then call the issuance endpoint. But this is a deviation from VCI that I would really like to avoid.

[paulbastian]

How scope is currently designed in VCI, it is a 1:1 relationship to Credential Configuration.

@paulbastian as we discussed, there are also implementations that use the same scope value for the same credential_configuration_ids

The sentence is confusing, did you mean different? Can you lay out an example where a scope maps to multiple credential configuration ids? I guess it involves legacy AS? ;)

[Sakurann]

@paulbastian yes, I meant same scope value with different credential configuration id. the use case is where different credentials use the same data set about the user that is identified with the same scope value at the AS

[Sakurann]

this should be resolved with #392

discussed in a WG:

when scopes were used in the authorization response,

• if AS is capable of returning credential_identifiers parameter in the token response, wallet MUST use that in the credential request.
• if AS is NOT capable of returning credential_identifiers parameter in the token response, wallet MUST use credential_configuration_id in the credential request.