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.
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?