OIDC4VCI should allow authorization pending for authz code grant type

[Oliver Terbu]

In the current spec, there is no standardized way for a wallet to initiate an OIDC4VCI flow with the credential issuer to support deferred authorization. This is because:

• There is no standardized endpoint for the wallet to retrieve a credential offer from the credential issuer if pre-authz code flow should be used for deferred authorization. The issuer will need to know where to send the credential offer after the pre-authz code got issued.
• Authz code cannot be used with deferred authorization.

For reference, there are two ways to support deferred issuance: 1) deferred authorization via authorization pending error response from token endpoint which applies to pre-authz code flow only, 2) deferred credential endpoint where the credential endpoint would return an acceptance token (or as proposed in a pending PR a transaction id).

Wallets and issuers that support pre-authz code flow and authorization code flow with deferred issuance would need to implement two different ways of handling that (see 1) and 2) above). For that reason, we should add deferred authorization also to the authorization code grant type to unify that behaviour. Currently, deferred authorization is only possible with pre-authz code flow.

[Michael Jones]

Having multiple ways to do something is generally a red flag and can result in interop problems. How can we get down to one way to support deferred issuance?

[Daniel Fett]

I see that the transaction_id is not included in the possible responses of the pre-auth code flow, but I couldn’t find normative language preventing deferred issuance (this seems to be a separate issue).

What is the purpose of the authorization_pending/slow_down responses if we have deferred issuance?

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VCI