Require refresh tokens

[Edmund Jay]

Comments from TL regarding for pull request #39

https://bitbucket.org/openid/connect/pull-requests/39/merging-cp-into-ca#comment-238239634

• why is the refresh token optional? It’s good security practice and not requiring it makes interop difficult.

‌

[Kristina Yasuda]

I might be remembering it wrong, but I think at some point we discussed that it might not be a good idea to use Refresh Token with VC issuance because

1/ issuance of the same credential more than once within the same issuance request does not make sense since it is the user requesting the issuance, and if the user would want another credential, it would start the issuance flow from the beginning;

2/ for a deferred issuance, it would make more sense to issue something like an acceptance token to the user so that the user can come back to the Issuer to fetch a credential once it is ready. (Nat pointed to Ping/Push callback in CIBA OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0)

(cc: @Torsten Lodderstedt )

[Torsten Lodderstedt]

I see the following use cases for refresh tokens:

• request issuance of a credential with different format
• request issuance of a credential bound to different key material
• requesting a new credential because the previous credential expired (might require new approval but could be useful if the issuer wants to issue pretty short living credentials)
• requesting single use credential (because the key/proof method does not support non-co-relatable identifiers towards verifiers).
• request issuance of particular credential out of several approved credentials (esp. needed if credential issuance is an operation issuing a single credential at a time)

‌

[Torsten Lodderstedt]

on CIBA: CIBA allows deferred issuance of the access token since the OP needs to reach out to the user OOB. That might be the same as deferred credential issuance but it does not need to be. I feel more comfortable with decoupling token and credential issuance (now).

[Thomas Bellebaum]

I feel like the burden of interoperability is merely shifted from the IdA to the IA, since the latter would be forced to implement refresh tokens just because of this very proposal. In general, an IdA supporting Refresh Tokens will likely have an easier time dealing with them not being issued, than an IA dealing with Clients that require one.
Also important: In some cases, IAs will likely want to only issue VCs once. Think e.g. about an environment where due to privacy concerns one wants to minimize interactions with centralized infrastructure. There, refresh tokens are of less value.

[Nat Sakimura]

So, maybe we leave the text as is? That means that there is going to be some optionality. We need to put some guidance text around it explaining when and why you may want to have a particular choice and what are the consequences.

[Michael Jones]

I don’t see a compelling case to require something that’s normally optional. That said, some profiles and trust frameworks could require it. This could be said in a note in the spec.

[Torsten Lodderstedt]

I suggest to describe use cases for refresh tokens in an implementation considerations section.

[Edmund Jay]

fixes #1311 - Require refresh tokens

Removes mention of refresh tokens and add section for implementation considerations

→ <<cset 2cc0e4e858ff>>