Clarify boundness

Co-authored-by: Joe DeCock <[email protected]>

IdentityServer/v7/docs/content/tokens/refresh.md

@@ -50,7 +50,11 @@ The [Duende.AccessTokenManagement](https://github.com/DuendeSoftware/Duende.Acce
 ## Binding refresh tokens
 Refresh tokens are a high-value target for attackers, because they typically have a much higher lifetime than access tokens.
 
-It is recommended that a refresh token is either bound to the client via a client secret or using [Proof of Possession]({{< ref "pop" >}}).
+However, refresh tokens for _confidential clients_ are bound to that client; they can only be used by the client they are issued to and the client is required to authenticate itself in order to do so. An attacker able to obtain a refresh token issued to a confidential client cannot use it without the client's credentials.
+
+Refresh tokens issued to public clients are not bound to the client in the same way since the client cannot authenticate itself. Instead, we recommend that such refresh tokens be sender-constrained using [Proof of Possession]({{< ref "pop" >}}).
+
+You can further reduce the attack surface of refresh tokens using the following techniques.
 
 #### Consent
 We encourage you to request consent when a client requests a refresh token, as it not only makes the user aware of the action being taken, but also provides them with an opportunity to opt-out if they choose.