For both put-token and delete-token

For error conditions related to the content of the request, e.g., unsupported token type, malformed request etc., a detailed description SHOULD NOT be provided in the error field, in line with general best practice for security-related protocols.

//

That’s a bit harsh. I think it is worth differentiating between a totally botched request and a token that is structurally sound but isn’t valid for the scope or has expired. That doesn’t substantially lower the security bar, but does reduce support cost.