Change:
6.1. <del> The client instance makes an HTTP POST to the token management URI, sending the access token in the appropriate header and signing the request with the appropriate key. </del> <ins> If the client instance has an access token and that access token expires, the client instance might want to rotate the access token. Rotating an access token consists of issuing a new access token in place of an existing access token, with the same rights and properties as the original token, apart from an updated expiration time. To rotate an access token, the client instance makes an HTTP POST to the token management URI, sending the access token in the appropriate header and signing the request with the appropriate key. </ins> The AS validates that the token presented is associated with the management URL, that the AS issued the token to the given client instance, and that the presented key is appropriate to the token. <del> If the access token has expired, the AS SHOULD honor the rotation request to the token management URL since it is likely that the client instance is attempting to refresh the expired token.  To support this, the AS MAY apply different lifetimes for the use of the token in management vs. its use at an RS.  An AS MUST NOT honor a rotation request for an access token that has been revoked, either by the AS or by the client instance through the revoke-access-token. </del> <ins> Note that in many cases, the access token will have expired for regular use.  To facilitate token rotation, the AS SHOULD honor the rotation request of the expired access token since it is likely that the client instance is attempting to refresh the expired token.  To support this, the AS MAY allow a longer lifetime for token management compared to its use at an RS.  An AS MUST NOT honor a rotation request for an access token that has been revoked or otherwise disabled. </ins> If the token is validated and the key is appropriate for the request, the AS MUST invalidate the current access token associated with this <del> URL, if possible, and return a new access token response as described in response-token-single, unless the "multi_token" flag is specified in the request.  The value of the access token MUST NOT be the same as the current value of the access token used to access the management API.  The response MAY include an updated access token management URL as well, and if so, the client instance MUST use this new URL to manage the new access token.  [[ See issue #101 [29] ]] [[ See issue #102 [30] ]] [[ See issue #103 [31] ]] </del> <ins> URL, if possible.  Note that stateless access tokens can make proactive revocation difficult within a system, see security- stateless-tokens. The AS responds with an HTTP 200 with a JSON body consisting of the rotated access token in the "access_token" field described in response-token-single.  The value of the access token MUST NOT be the same as the current value of the access token used to access the management API.  The response MUST include an access token management URL, and the value of this URL MAY be different from the URL used by the client instance to make the rotation call.  The client instance MUST use this new URL to manage the rotated access token. The access rights in the "access" array for the rotated access token MUST be included in the response and MUST be the same as the token before rotation.  If the client instance requires different access rights, the client instance can request a new access token by creating request or by continue-modify. [[ See issue #103 [29] ]] </ins> 6.2.

Discussion:
update token rotation response and requirements add considerations for the difficulties of rotating and revoking stateless tokens add considerations on rotation in unreliable networks
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 2284ffefdc540b8743400e9463fb65fc99070d4a Inspect the deploy log: Browse the preview:
Rotation the Access Token: Editor's note: The net result is that the client's always going to use the management URL that comes back. But should we let the server omit it from the response if it doesn't change? That seems like an odd optimization that doesn't help the client.
Close by making inclusion of URI REQUIRED.
Rotating the Access Token: Editor's note: We could also use different verbs to signal whether or not the old token should be kept around or not, instead of using a token flag to do this.
Keep "MUST if possible" here. If you want two access tokens, use the grant API not the token rotation API. The rotation mechanism should be for getting a new value for an existing token and replacing it, not for minting entirely new separate tokens (which is what the grant continuation/update API is for). We need to keep "if possible" for the case of using stateless tokens (fully self-contained JWTs), and add a discussion on when it might not be possible.
a few minor comments