The client key should not be bound to the refresh token

Solid Specification Interoperability
1

Dear all,

With the use case expressed in 1, it is clear to me that the client key should be considered to be stored in the user’s browser storage, just like the access token. They are used together for every request, except for the token endpoint request. However, it should be possible for the refresh token never to be sent to the browser. As such, the refresh token should not be bound to the client key.

There is a practical problem left: the token request. In this situation, it inconvenient to generate the DPoP proof in the browser, then find a way to send it to the server side, and then make the token request from there. This is because the DPoP proof is used in two really different ways, first to convey a key, and then to check the possession of a key. I suggest to find another way to convey the key for the token request, other than using the DPoP proof mechanism.

What do you think?

2

You should raise this kind of question on GitHub - solid/authentication-panel: GitHub repository for the Solid Authentication Panel which is the place the specs governing tokens are written and people most knowledgeable about the Solid authentication process hang out.