[ID-2] Credential Issuance: `retry_in` parameter for deferred credentials

[Thomas Bellebaum]

Moved to here from Github.

It seems unclear to me how often the client should retry to retrieve a token that could not yet be issued.
Maybe an option for the server to specify when it expects to be able to deliver the requested credential would be helpful.
This parameter (let's call it retry_in) would (optionally or mandatory) be returned with the acceptance_token at the credential endpoint, and at the deferred credential endpoint whenever the credential could not yet be delivered.

[Kristina Yasuda]

Discussed during 2021-12-16 SIOP call.

We discussed that if we are to use polling, this parameter makes sense. it was suggested renaming it to retry_after.

It was also raised that we may want to reconsider polling and get the client to a request to the Issuer instead. (response to which would be valid only during the session lifetime)

[Thomas Bellebaum]

To add an example use case:
COVID Rapid testing takes a predictable time of around 15 minutes until a result is determined. Approx. 2-3 minutes later, the result should be available online, after an employee of the testing facility has manually registered the result.
Current implementations used widely throughout Germany then notify the user via email, ask them to authenticate, and then issue an EU test certificate (usually directly to an app on the user’s phone).

A mechanism for automatic retrieval of tests would be useful here from a user experience perspective.

[Kristina Yasuda]

I agree we need this parameter.

Currently, there are only below two:

• `authorization_pending`: OPTIONAL. JSON Boolean. In pre-authorized code flow, the Token Request is still pending as the issuer is waiting for the end user interaction to complete. The client SHOULD repeat the Token Request. Before each new request, the client MUST wait at least the number of seconds specified by the "interval" response parameter. ToDo: clarify boolean.

• `interval`: OPTIONAL. The minimum amount of time in seconds that the client SHOULD wait between polling requests to the token endpoint in pre-authorized code flow. If no value is provided, clients MUST use 5 as the default.

‌

[David W Chadwick]

I think the whole deferred issuance model is misguided and fundamentally wrong. The deferred protocol should be removed from the specification. My reasoning is as follows:

if I apply for a credential that takes time to issue, such as a UK DBS check with the police, then I would make the application on line with my browser, enter all the details that are needed (including scanning various documents), and the application session would then end. Only after all the checks have been completed (which can take days or weeks) will the system notify me (perhaps by email or letter) that the process is complete and my certificate is ready for collection. I can then enter the credential issuance protocol and download my credential immediately. There is no need for a deferred issuance protocol.

[Thomas Bellebaum]

@David There might be a use case for issuance processes which take only minutes (say someone needs to manually verify some inputs against a legacy database, or the COVID test takes ~15 min). In those cases, logging back in can be very inconvenient, especially if you are in an area with limited internet connection, so you are happy if your device can make a single request rather than you having to navigate a (potentialy complex) website.

[David W Chadwick]

@Thomas. Your German use case example seems to support my assertion that performing the COVID test, having it analysed, and then getting an email notification when the result is ready to install in your wallet, means that deferred issuance is not needed. I dont see how the actual COVID test can be done online (you cannot pass a swab through email), so authentication is only needed once when you pick up the certificate.

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VCI