Sending info for both grant types in Credential Offer

[paulbastian]

In the current specification, we have this example for Credential Offer (link):

{
   "credential_issuer": "https://credential-issuer.example.com",
   "credentials": [
      "UniversityDegreeCredential",
      "org.iso.18013.5.1.mDL"
   ],
   "grants": {
      "authorization_code": {
         "issuer_state": "eyJhbGciOiJSU0Et...FYUaBy"
      },
      "urn:ietf:params:oauth:grant-type:pre-authorized_code": {
         "pre-authorized_code": "adhjhdjajkdkhjhdj",
         "user_pin_required": true
      }
   }
}

I could not think of any possible scenario, where it makes sense to have both grant types in one credential offer, either I'm already authenticated or I'm not? Therefore I propose to delete one of the grants from the example.

[tlodderstedt]

The primary reason for allowing for multiple grants is interoperability. If the wallet is free to implement either authz code or pre-authz code, the issuer must support both and leave the decision to the wallet.

[paulbastian]

I'm not against supporting multiple grant types in credential offer in general. In just saying this particular example/combination seems weird and confusing. Can anyone sketch a use case for this?

[Sakurann]

I am not convinced with the use-case where the issuer sends both grants in the Offer... If the Issuer has generated the pre-auth code, I highly doubt the issuer can/willing to issuer the same credential using auth code flow. and if the issuer sent pre-auth code, but the wallet does not support it, the wallet has all the information to start auth code flow (credential issuer identifier and offered credential information), so this scenario technically does not need authorization_code object. if the issuer started auth code flow, but the wallet only supports pre-auth code, that's when it's dead-end. but it is a lot of work to turn authentication done at the authorization endpoint to the pre-auth code flow, so I am not sure how many issuers would do it for the wallets that only support pre-auth flow...

[paulbastian]

@Sakurann so you agree that examples should only use either auth code or preauth code flow?

[paulbastian]

This was resolved in #121