Potential improvements for the big picture of issuance flows

[paulbastian]

I've tried to summarize all issuance options regarding the use of:

• authorization_details / scope
• credential_identifiers

It seems that there are many possible combinations to do issuance with OpenID4VCI, in my opinion it may be too many and we should consider consolidation.

My observations:

• scope is an easy/uncomplicated way to do most use cases 👍
  • no support for different Credential Datasets but thats ok
  • it is weird that Credential Request uses format +format specific parameters instead of scope 🤔
• authorization_details enables the Wallet to choose between different Credential Datasets 👍
  • authorization_details has two options: credential_configuration_id vs format + format specific parameter 🤔
  • when authorization_details is used credential_identifiers is still optional 🤔
  • this means that Credential Request depends on the Token Response 👎
• in preAuth Code Flow, we have a third option, providing credential_configuration_ids, but probably fine
  • its unclear which Credential the Wallet is requesting if multiple IDs are provided
  • credential_identifiers cannot be used, because it is not authorization_details flow 👎
  • Credential Datasets cannot be requested 👎

Proposals:
1: make credential_identifiers mandatory
2: enable credential_identifiers for Pre-Auth Code Flow
3: enable authorization_details with credential_configuration_id in Token Request for Pre-Auth Code Flow
4: consider using scope in Credential Request

[babisRoutis]

Proposals:
1: make credential_identifiers mandatory
2: enable credential_identifiers for Pre-Auth Code Flow
3: enable authorization_details with credential_configuration_id in Token Request for Pre-Auth Code Flow
4: consider using scope in Credential Request

2,3. This would bring in par (functional-wise) the two flows, I guess. Totally, agree.
4. I think that there isn't one-to-one relationship between a scope and a credential (That is,there could multiple credential_configuration_ids that use the same scope)

In general, I feel that VCI has too many alternatives that make it complex without a good reason.
As you pointed out,

• why have two ways of assembling an authorization_details? Some claim backward compatibility reasons, but I find that this not so strong argument given the extended changes introduced to d13 compared to d12.
• why credential_configuration_id has not replaced format+format specific parameters in the credential request?
  Some people claim in order to have the ability to request credentials that are not advertised via metadata. Frankly though I don't get why it is easier to know (out of bounds) format+format specific parameters instead of a credential_configuration_id

[Sakurann]

we brushed-up Paul's original proposals in the in-person WG:

1a: make credential_identifiers mandatory in credential request for RAR (can still use format/credential_config_id in authorization req)
1b: make credential_identifiers mandatory in credential request and authorization request for RAR (cannot use format/credential_config_id in authorization req)
2: enable returning credential_identifiers from the token endpoint for Pre-Auth Code Flow when RAR is used
3: enable authorization_details with credential_configuration_id in Token Request for Pre-Auth Code Flow (already enabled by RAR)
4: consider using credential_configuration_id in Credential Request when scope is used in the authorization request

[Sakurann]

(personally agree to all the above)

[paulbastian]

There weren't any opposing arguments in today's DCP call, but we were also short on time. Feedback is appreciated to know that the working group is in favour of the suggested changes, e.g. give thumbs up.

[David-Chadwick]

We found in our initial implementation (prior to OpenID4VCI being created) that the credential_identifier was essential in the request due to the possibility of an issuer issuing two credentials of the same type with the same properties but different values. So I fully support the use of this parameter.

[paulbastian]

Implementers Feedback from IDunion Hackathon 2024 is that implementers are confused when implementing Credential Request, because they usually don't find the credential specific parameters in the Annex and rather expected to use the credential_configuration_id instead of vct for SD-JWT VC

[Sakurann]

Paul to do a PR on points 1-3 and on point 4, discussed in a WG, there is rough consensus that it is a good idea to use credential_configuration_id in the credential request (tho credential_identifiers from the token andpoint are probably preferred...)
so the credential request would look like this:

{
  "credential_configuration_id": "org.iso.18013.5.1.mDL",
   "proof": {
      "proof_type": "cwt",
      "cwt": "..."
   }
}

[paulbastian]

we brushed-up Paul's original proposals in the in-person WG:

1a: make credential_identifiers mandatory in credential request for RAR (can still use format/credential_config_id in authorization req) 1b: make credential_identifiers mandatory in credential request and authorization request for RAR (cannot use format/credential_config_id in authorization req) 2: enable returning credential_identifiers from the token endpoint for Pre-Auth Code Flow when RAR is used 3: enable authorization_details with credential_configuration_id in Token Request for Pre-Auth Code Flow (already enabled by RAR) 4: consider using credential_configuration_id in Credential Request when scope is used in the authorization request

@Sakurann The initial proposal was to replace Credential Request format with scope, in your comment I see proposal to replace format with credential_configuration_id. Was there a discussion on the advantages of either of the solutions?