OpenID4VCI: simplification of deferred issuance

[Takahiko Kawasaki]

By returning "error":"authorization_pending" (or something similar) instead of issuing an acceptance token (instead of returning "acceptance_token":"..."), the process of deferred issuance can be simplified. The credential issuer would not have to manage acceptance tokens and would not have to implement the deferred credential endpoint.

The token endpoint in CIBA POLL/PING modes and Device Flow (RFC 8628) returns "error":"authorization_pending" until it gets ready to issue tokens.

[Torsten Lodderstedt]

Thanks for bringing this up.

The initial idea of this endpoint was that the issuer can start a transaction with the credential request (storing the request along with the proof and so on) and the wallet could pick the result up once it is available. The acceptance token allows the issuer to determine the respective transaction with means at its discretion.

If the issuer responds with an error, the wallet would need to send the full credential request again (and again). I’m not sure how the credential issuer would determine what are sub-sequent requests for the same credential and what are new requests.

Any ideas?

[Takahiko Kawasaki]

The points Torsten kindly explained sound convincing. Thank you.

[Kristina Yasuda]

I think this was addressed in PR #488. pending close