Deferred Flow when AT expires

[fmarino-ipzs]

Currently, the Deferred Flow is only allowed if the WI has a valid Access Token, according to the latest draft of OID4VCI. We should clarify how to use deferred flow in case of expired AT.
The Refresh Token seems to be a good mechanism but we should consider:

1. DPoP RT
2. Refresh Token Rotation mechanism

Moreover:

• regarding point 1, we should analyze the UX implications
• we should clarify the scope of the RT beyond deferred flow (e.g. for re-issuance/renewal of a Digital Credential)

[fmarino-ipzs]

Regarding point 1 and UX implications: even if we would not consider the use of DPoP for RT, we would still have a DPoP AT to be used for the Credential Endpoint, therefore requiring user involvement during the deferred (or in the even more general case during a re-issuance/renewal of a Credential).
WDYT?

[peppelinux]

I am in favor of using DPoP for RT

a wallet http request to a third endpoint could be hijacked and the refresh token therefore stolen. DPoP is the security solution that definitively mitigates this

[peppelinux]

I am ok to use the same cnf of the AT for the RT too, or at least to not mandate to use different cryptographic materials for AT and RT

[asharif1990]

I think from the security prespective and following the BCPs it is a good strategy to have the DPoP RT. Regarding the UX implications, You can pre-generate the DPoP proof and control their validity based on the server-provided Nonce and use them in the background without user involvement.

regarding other use-cases. I agree with you @fmarino-ipzs.

[grausof]

I agree with the use of DPoP. I don't see any major complications on the UX side, once the app is opened and the wallet is unlocked, the app is able to perform all the cryptographic operations necessary for a refresh. From a technical point of view, no user consent is necessary, but if required from a legal point of view it could be a one-shot consent for reissuance.