FR: Deferred Presentation over DC API

This is a feature request for a use case we are looking into. It is of interest when:

• The Verifier is happy to accept a response within a relatively long window (e.g. many existing KYC, account recovery, account verification may take 24 hours or more), but wants to have reasonable confidence that it will get a verfication
• A wallet does not have a credential, but has the potentially to get one from pre-registered issuers (e.g. an EUDI Wallet may be installed, but the user has not yet issued their PID). Additionally, the authorization or credential issuance is deferred.

The flow today would be something like:

• The Verifier calls DC API with a request.
• No registered wallet has credentials but one or more wallets believe they can authenticate the user to an issuer with credentials that may be able to.
• User selects a wallet and/or issuer and performs issuance per OpenId4VCI (specifics is out of scope)
• If the credential is issued synchronously it can be returned as a response as if it is always there
• If it is deferred, currently we are stuck (and would have to return an error).

The proposed flow would instead allow a response to be returned indicating that the full credential response will be deferred. At some point later after issuance completes, with proper consent, the presentation can be completed in a back channel.

The benefits

• Verifiers are encouraged to call the API even when total coverage of existing credentials is low, and need to fall back to existing mechanisms less often.
• Users end up with a re-usable credential, benefiting them for future presentations.

Both of these help solve the bootstrapping problem that otherwise exists for deferred issuance credentials. Doing it through the standard (vs wallets attempting to create side channels) provides a better user experience and better inter-op.

Proposed Solution

My proposal to solve this is to leverage the existing 'direct_post.jwt' response mechanism within the context of the DC API. To do this, request_uri and request_uri_method may optionally be included in a request with dc_api response_mode. DC API may then either return the response (in band) or return a response code indicating that it will come as a post sometime later.

I'm curious if this sounds reasonable and is something the group would be interested in supporting?

No repository files or tests are identified. Start by reviewing the existing direct_post.jwt response mechanism and the DC API request fields request_uri and request_uri_method. Done would require an agreed specification for deferred response signaling and later back-channel presentation after OpenID4VCI issuance.