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*
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
