Change:
supported format.  If a key is sent in multiple formats, all the key format values MUST be equivalent.  Note that while most formats present the full value of the public key, some formats present a <del> value cryptographically derived from the public key. </del> <ins> value cryptographically derived from the public key.  See additional discussion of public keys in security-symmetric. </ins> Additional key formats are defined in IANA.

Discussion:
Adds a provision for rotating keys on access token requests. If a client needs to dynamically rotate its request key, this would happen through a client instance management API that is not defined in the core protocol.
To edit notification comments on pull requests, go to your .
Changing the parameters of the proof method really is the same level of function as changing the proof method entirely. Would you claim the parameters apply to the new key or the old key? And what if the proofing method makes it impossible to apply two signatures (for example) with different parameters? It opens up a can of worms to allow it to vary, and I think we need to cut all of that off.
I'm wondering if there are legit cases in the wild when as AS prohibits its clients to perform key rotation on their own. If so, how it will notify the clients?
NAME am I right that becomes immediately invalid? If it's true, wouldn't be nice to have here some way to rotate them more or less gracefully? It could be useful when there are multiple running instances of the client and it's tough, or even impossible, to update the keys on all these instances immediately (just as an example, the client instance could be deployed as a service in K8S). Thank you.
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.
Rotating the Access Token: Editor's note: If the client is using its own key as the proof, like with a bearer access token, the AS is going to need to know if the client's key has been rotated. We don't have a mechanism for rotating the token's key or the client's key yet either - so that could occur through this management function as well.
See discussion at
Token key rotation is covered by , and a non-bound token would use whatever's currently tied to the client at the AS, whatever that is.
Continuing a Grant Request: Editor's note: We need to have a secure way to rotate the key used for the continuation here. In most cases this will be a rotation for the client instance, since a client without an instance record would likely just present a new key for a new request.

In that case it could go with the client management, above - but it doesn't necessarily have to be.
See my comment on pull request URL I think we need to find a single rotation recovery method. I collected my ideas here: URL
This is close to what I was thinking about. I would also add as a reference what is doing on key rotation, for discussion purposes.
Key rotation is now handled on the continuation access token, not as part of the grant update. See
Could you answer on URL and other comments in this PR? Thank you.
what do you mean by "more or less gracefully" ?
NAME you can omit "more or less gracefully", I wanted to know if GNAP allows to address the use case I provided and
Indeed the idea currently is that previous-key is replaced by the new key, for all what's coming afterwards. I know of some systems that allow a delay during which both versions coexist, is that what you're after ?
There are plenty of systems where both, or even more versions coexist until an administrator or a client itself decides to remove/invalidate previous keys. That's correct. The same approach arguably is even way more valuable for . BTW, are you planning to allow them to rotate their own keys? You are writing these specs, and IMO, you still have time to add & embed these features into the core of GNAP.