Draft: draft-ietf-gnap-core-protocol

Commentary: To edit notification comments on pull requests , go to your . 
 The " previous_key " element 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
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
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
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
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
the AS.  In such cases, it can be difficult, or even impossible, to
update the keys on all these copies in the same instant.
Paragraph (version B):
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
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
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
the AS.  In such cases, it can be difficult, or even impossible, to
update the keys on all these copies in the same instant.
Paragraph (version A):
The need for accommodating such known delays in the system needs to
be balanced with the risk of allowing an old key to still be used.
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
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.
Paragraph (version B):
The need for accommodating such known delays in the system needs to
be balanced with the risk of allowing an old key to still be used.
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
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.