[OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

[Filip Skokan <[e-mail]>]

I've wondered about the decision to use a new scheme before
<https://github.com/danielfett/draft-dpop/issues/41#issuecomment-490096716> but
this time i'd like to challenge the immediate usability of the future spec
for one specific case - sender constraining public client Refresh Tokens.

If at all, it is going to take time for RS implementations to recognize the
new `DPoP` authorization scheme, let alone process it properly. In the
meantime, i'd still like to have the option to bind issued public client
refresh tokens using DPoP without affecting the access tokens. In doing so
i get an immediate win in sender constraining the refresh tokens but not
introducing a breaking change for the RS.


   - Do you see this as something an AS implementation is just free to do
   since it's both the issuer and recipient of a refresh token? Should this be
   somehow baked in the draft?
   - Do you think client registration metadata could be used to signal such
   intent?
   - Do you think the protocol should have signals in the messages
   themselves to say what the client wants to apply DPoP to?
   - What if AS and RS don't have a shared support DPoP JWS Algorithm? Do
   we disqualify such cases or allow for sending two proofs, one for the AS to
   bind refresh tokens to, one for the RS to bind access tokens to?


Best,
*Filip Skokan*