[OAUTH-WG] DPoP key rotation

[Dmitry Telegin <[e-mail]>]

Hi,

I'm Dmitry Telegin, I'm currently working on DPoP implementation in
Keycloak on behalf of my company, Backbase. Takashi Norimatsu of Hitachi
supervises this process as the head of the Keycloak FAPI SIG.

With the current DPoP design, once the keypair has been generated on the
user agent and the initial token set has been obtained (using
authorization_code grant), the whole chain of the subsequent access/refresh
tokens will be bound to this particular keypair. That means, the keypair
should be persisted on the user agent for the duration of the session.

OTOH, sessions could be rather long-lived, especially if we take offline
tokens [1] into account. In a nutshell, offline access provides a
non-expiring refresh token. This could be highly relevant e.g. for mobile
applications that would employ offline tokens to help users avoid logging
in every time.

The longer the session lasts, the higher the probability of key leakage is.
Currently, the only way to switch to a new DPoP keypair is to start a new
session (i.e. log in again). Do you think it might be worth incorporating
some sort of key rotation concept into DPoP design?

The most obvious way to perform key rotation is to do that during token
refresh. For that, we could make the refresh_token grant honour the
additional DPoP proof that would supersede the current one. From the
technical PoV, it could be as easy as supplying two proofs within the DPoP
header:

DPoP: eyJ0eXAiO... eyJ0eXAiO...

Or we can go with a single (old) DPoP proof, containing the new proof
(to supersede the current one) as a claim (or vice versa).

We'd appreciate any feedback from the WG. Also apologize if this ML is
not the appropriate place to discuss issues like this.

Regards,

Dmitry Telegin

Senior Backend Engineer, Backbase R&D B.V.

[1] https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess