Original text:
access token, the client instance MUST present both the new key and previous key in the access token rotation request.  The client instance makes an HTTP POST as a JSON object with the following <del> fields: </del>  The "proof" method and parameters for the new key MUST be the same as those established for the previous key. <del> The client instance MUST prove possession of both keys simultaneously in the rotation request.  The means of doing so varies depending on the proofing method in use.  For example, the HTTP Message Signatures proofing method uses multiple signatures in the request as described in httpsig-rotate, as shown in this example. </del>  An attempt to change the "proof" method or parameters, including an attempt to rotate the key of a bearer token (which has no key), MUST Signature Algorithm is applied using the following RSA key (presented here in JWK format):  7.3.1. This method is indicated by the method value "httpsig" and can be new key. For example, the following request to the token management endpoint <del> for rotating a token value contains both the old and new keys in the request.  The message is first signed using the old key and the resulting signature is placed in "sig1": </del>  The signer then creates a new signature using the new key using the signature value as its input to the signature base.  Since the When keys are rotated, there could be a delay in the propagation of that rotation to various components in the AS's ecosystem.  The AS <del> can define its own policy regarding the timeout of the "previous_key", either making it immediately obsolete or allowing for a limited grace period during which both the "previous_key" and the current key can be used for signing requests.  Such a grace period can be useful when there are multiple running copies of the client that are coordinated with each other.  For example, the client </del>  software could be deployed as a cloud service with multiple orchestrated nodes.  Each of these copies is deployed using the same key and therefore all the nodes represent the same client instance to Narrowly restricting the exposure opportunities for exploit at the AS in terms of time, place, and method makes exploit significantly more difficult, especially if the exception happens only once.  For <del> example, the AS can reject requests from the "previous_key" (or any previous one before it) to cause rotation to a new key, or at least ensure that the rotation happens to the same known key. </del>  See also the related considerations for token values in security- network-management.

Reviewer comments:
To edit notification comments on pull requests, go to your .
The "previous_key" element added in is not necessary in practice because the AS should always be able to look up the current key value based on the access token, and the signature using the previous key proves possession of that key separate from any presentation of the key value or reference.
Makes sense

Revised text:
access token, the client instance MUST present both the new key and previous key in the access token rotation request.  The client instance makes an HTTP POST as a JSON object with the following  <ins> field: </ins> The "proof" method and parameters for the new key MUST be the same as those established for the previous key.  <ins> The client instance MUST prove possession of both the currently-bound key and the newly-requested key simultaneously in the rotation request.  Specifically, the signature from the previous key MUST cover the value or reference of the new key, and the signature of the new key MUST cover the signature value of the old key.  The means of doing so varies depending on the proofing method in use.  For example, the HTTP Message Signatures proofing method uses multiple signatures in the request as described in httpsig-rotate, as shown in this example. </ins> An attempt to change the "proof" method or parameters, including an attempt to rotate the key of a bearer token (which has no key), MUST Signature Algorithm is applied using the following RSA key (presented here in JWK format): <ins> Key proofing methods SHOULD define a mechanism to allow the rotation of keys discussed in rotate-access-token-key.  Key rotation mechanisms MUST define a way for presenting proof of two keys simultaneously with the following attributes: The value of or reference to the new key material MUST be signed by the existing key.  Generally speaking, this amounts to using the existing key to sign the body of the message. The signature of the old key MUST be signed by the new key. Generally speaking, this means including the signature value of the old key under the coverage of the new key. </ins> 7.3.1. This method is indicated by the method value "httpsig" and can be new key. For example, the following request to the token management endpoint  <ins> for rotating a token value contains both the new key in the request. The message is first signed using the old key and the resulting signature is placed in "sig1": </ins> The signer then creates a new signature using the new key using the signature value as its input to the signature base.  Since the When keys are rotated, there could be a delay in the propagation of that rotation to various components in the AS's ecosystem.  The AS  <ins> can define its own policy regarding the timeout of the previously- bound key, either making it immediately obsolete or allowing for a limited grace period during which both the previously-bound key and the current key can be used for signing requests.  Such a grace period can be useful when there are multiple running copies of the client that are coordinated with each other.  For example, the client </ins> software could be deployed as a cloud service with multiple orchestrated nodes.  Each of these copies is deployed using the same key and therefore all the nodes represent the same client instance to Narrowly restricting the exposure opportunities for exploit at the AS in terms of time, place, and method makes exploit significantly more difficult, especially if the exception happens only once.  For  <ins> example, the AS can reject requests from the previously-bound key (or any previous one before it) to cause rotation to a new key, or at least ensure that the rotation happens to the same known key. </ins> See also the related considerations for token values in security- network-management.