Deferred Issuance: Is it applicable after access_token and/or refresh_token expiration?

[babisRoutis]

Let's assume that a wallet using some flow (authorization code or pre-authorized code) has obtained an access_token and possibly a refresh_token. It, then, calls the credential endpoint and gets back a transaction_id.

I think, it is clear that wallet can query deferred endpoint, as long as access_token has not been expired, and if a refresh_token has been provided, perhaps it could also get a fresh tokens and extend the time window that can place such a query.

But what happens in case where the corresponding credential has not been prepared and

• access_token is expired and (there is no refresh_token) or
• refresh_token is expired ?

Is it possible to obtain an access_token again for this specific transaction_id?

Given that probably it won't be possible for a wallet to poll continuously the deferred endpoint, is it implied that transaction_id is bound to the lifecycle of access_token (and/or refresh_token), or can be used to realize a "come back for your credential, tomorrow" scenario"?

[peppelinux]

it is clear that wallet can query deferred endpoint, as long as access_token has not been expired, and if a refresh_token has been provided, perhaps it could also get a fresh tokens and extend the time window that can place such a query.

The transaction_id may appear useless if the AT lifetime allows an issuance in the future, because the wallet will obtain the credential the the credential endpoint without the deferred flow.

a credential endpoint may return an error with an error description by saying "the credential is not ready yet, come back tomorrow".

how the wallet instance is informed that it has to refresh that AT? the answer could be: until it has an AT that is not linked on an obtained credential (therefore internal transaction state)

[babisRoutis]

it is clear that wallet can query deferred endpoint, as long as access_token has not been expired, and if a refresh_token has been provided, perhaps it could also get a fresh tokens and extend the time window that can place such a query.

The transaction_id may appear useless if the AT lifetime allows an issuance in the future, because the wallet will obtain the credential the the credential endpoint without the deferred flow.

a credential endpoint may return an error with an error description by saying "the credential is not ready yet, come back tomorrow".

how the wallet instance is informed that it has to refresh that AT? the answer could be: until it has an AT that is not linked on an obtained credential (therefore internal transaction state)

So Giuseppe, let's see if I got your reply correct:

To implement the "come back tomorrow" scenario you are suggesting that there are two options:

• Either issuer informs the wallet / holder (with an error) that the issuance process should start from the beginning, tomorrow. In the meanwhile issuer should start preparing for this credential, or
• Wallet should query from time - to - time issuer using the transaction_id and a suitable AT (long-lived or an AT that can be refreshed)

If my understanding is correct, then I guess that the answer to my initial question is that should the access_token / refresh_token expire, wallet cannot use the deferred endpoint (no option to exchange transaction_id for an AT)

[jogu]

Yes, standard OAuth2 behaviour applies here.

If an access token has expired (which the wallet can either know from the expires_in it received with the access token, or by the deferred endpoint returning a suitable 401 Unauthorized http error) then the wallet needs to use the refresh token to get a new access token.

If the refresh token has expired or there isn't one, then the wallet can't retrieve the credential and would need to start the flow again at the authorization endpoint or with a new pre-authorised code.

In general it is of course sensible that the authorization server is configured so that the wallet gets access that lasts at least as long as the deferred credential issuance might take.

[babisRoutis]

Yes, standard OAuth2 behaviour applies here.

If an access token has expired (which the wallet can either know from the expires_in it received with the access token, or by the deferred endpoint returning a suitable 401 Unauthorized http error) then the wallet needs to use the refresh token to get a new access token.

If the refresh token has expired or there isn't one, then the wallet can't retrieve the credential and would need to start the flow again at the authorization endpoint or with a new pre-authorised code.

In general it is of course sensible that the authorization server is configured so that the wallet gets access that lasts at least as long as the deferred credential issuance might take.

Dear @jogu & @peppelinux

Thank you both for your replies. They confirmed my understanding that for a deferred issuance scenario the use of deferred endpoint is bound to the AT/RT expiration time, or to put it in other words there is no option to re-authorize the issuance.