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

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1375

Original Reporter: 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.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

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)

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: 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.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

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.

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

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.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: 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.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

@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.

[Sakurann]

discussed using Retry-After HTTP header parameter, but decided not to because it has to be used with error code 503 and be used when server is unavailable.

[schlagtim]

Hi everyone,

I would propose to make the interval parameter mandatory and not optional:

1. Making interval an optional value only increases implementation complexity without any benefits
   • Holder implementations would become simpler as they in general either take interval into account or ignore it (which they can do anyways)
2. Making interval mandatory might improve overall implementation quality of Issuers as they will have to take frequent re-occurring requests into account in their implementations (looking at this from a infrastructure and security angle). This also somewhat applies to Holder implementations.

[Sakurann]

the current situation is:

1. there is an interval parameter for when to call back the token endpoint. (might disappear based on the outcome of the issue #60)
2. there is an interval parameter in deferred credential error response.
3. there is no parameter indicating how long the wallet should wait until sending deferred request after receiving transaction_id in the credential or batch response.

I think it is worth introducing interval in credential/batch responses.

[jogu]

There is this text in 3.4 that implies that interval parameter exists in the credential response:

If the Credential Issuer requires more time to issue a Credential, the Credential Issuer may return a Transaction ID and a time interval in the Credential Response. The Wallet may send a Deferred Credential Request with the Transaction ID to obtain a Credential after the specified time interval has passed, as defined in Section 9.

We should either fix that text or introduced the parameter Kristina mentions above.

[Sakurann]

wg discussion

• interval in deferred issuance does not go away even when events endpoint gets introduced in 1.1 - interval just becomes bigger
• make existing interval parameter MUST and not SHOULD. not introducing a new parameter.
• additional feedback on deferred error codes might come