openid
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?
I think we'd have to decide whether to support this in the unsigned DC API request case, in which case we'd probably need some new rules around validation of response_uri. (Having the credential returned to any url provided to the API call seems like it'd be dangerous.)
It feels like doing this might lose some of the session binding properties of the DC API if we're not careful.
It'd probably also be necessary to allow 'state' in the DC API (it's currently not allowed) so that the verifier can determine what session the response is for.
I generally feel a bit uncomfortable with a credential potentially being released a "significant" time after the user was interacting with the verifier and kind of wonder if it'd be better to just signal to the verifier that a credential might be available now and it might want to make a new VP request to get it?
I'm curious if this sounds reasonable and is something the group would be interested in supporting?
My intuition is no.
I think we'd have to decide whether to support this in the unsigned DC API request case, in which case we'd probably need some new rules around validation of
response_uri. (Having the credential returned to any url provided to the API call seems like it'd be dangerous.)
Yeah, that makes sense to me, as you need to have some trust that the credential is going to the 'right' spot (which the DC API previously takes care of for you).
It feels like doing this might lose some of the session binding properties of the DC API if we're not careful.
I think it mostly makes it the same as a 'vanilla' redirect flow (with the benefit of a trusted origin, and better UX)?
It'd probably also be necessary to allow 'state' in the DC API (it's currently not allowed) so that the verifier can determine what session the response is for.
I generally feel a bit uncomfortable with a credential potentially being released a "significant" time after the user was interacting with the verifier and kind of wonder if it'd be better to just signal to the verifier that a credential might be available now and it might want to make a new VP request to get it?
This certainly would be interesting, but seems more challenging, as you'd have to communicate and store, essentially, a way to redirect back to the verifier session.
I'm curious what the concerns are? (User can, and probably should, consent again before the release). Are the concerns about the staleness of the url, or encryption key leaks? What time period do you consider 'very'
It feels like doing this might lose some of the session binding properties of the DC API if we're not careful.
I think it mostly makes it the same as a 'vanilla' redirect flow (with the benefit of a trusted origin, and better UX)?
I agree with what you said but (as I think we both agree on) careful thought is definitely needed due to the loss of that session binding. I really hope it doesn't have implications for the mdoc session transcript...
I'm curious what the concerns are? (User can, and probably should, consent again before the release). Are the concerns about the staleness of the url, or encryption key leaks? What time period do you consider 'very'
I'm not sure exactly where the boundary lies, but any time period over 2 days starts to risk the user having forgotten what they were doing, lost their device, decided they don't actually want the credential anymore, etc.