Open OIDF-automation opened 1 year ago
OIDF-automation
commented
1 year ago 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?
OIDF-automation
commented
1 year ago 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?
Sakurann
commented
1 year ago authorization_pending might be removed based on the outcome of #60. blocked by that issue
Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1924
Original Reporter: 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:
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.