Change:
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.

Discussion:
[[ See issue #103 [13] ]] <ins> 6.1.1. If the client instance wishes to bind a new presentation key to an 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 fields: The "proof" method and parameters for the new key MUST be the same as those established for the previous key. 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. 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 result in an error returned from the AS. </ins> 6.2. If the client instance wishes to revoke the access token proactively,

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.

required message components.  The verifier MUST validate the signature against the expected key of the signer. <ins> 7.3.1.1. When rotating a key using HTTP Message Signatures, the message, which includes the new public key value or reference, is first signed with the old key.  The message is then signed again with the new key, including the signature from the old key under the signature of the new key. For example, the following request to the token management endpoint 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": The signer then creates a new signature using the new key using the signature value as its input to the signature base.  Since the existing signature covers the required parts of the message, they do not need to be repeated. This signature is then added to the message: The verifier MUST validate both signatures before processing the request for key rotation. </ins> 7.3.2. This method is indicated by the method value "mtls".  This method

first-use.  See security-mtls and security-mtls-patterns for some additional considerations for this key proofing method. <ins> 7.3.2.1. Since it is not possible to present two client authenticated certificates to a mutual TLS connection simultaneously, dynamic key rotation for this proofing method is not defined.  Instead, key rotation for MTLS-based client instances is expected to be managed through deployment practices, as discussed in security-mtls-patterns. </ins> 7.3.3. This method is indicated by the method value "jwsd".  This method

ath with a new header that upgrades the algorithm, and possibly defining a new header that indicates the HTTP content's hash method. <ins> 7.3.3.1. When rotating a key using Detached JWS, the message, which includes the new public key value or reference, is first signed with the old key using a JWS object with "typ" header value "gnap-binding- rotation+jwsd".  The value of the JWS object is then taken as the payload of a new JWS object, to be signed by the new key. </ins> 7.3.4. This method is indicated by the method value "jws".  This method

ath with a new header that upgrades the algorithm, and possibly defining a new header that indicates the HTTP content's hash method. <ins> 7.3.4.1. When rotating a key using Attached JWS, the message, which includes the new public key value or reference, is first signed with the old key using a JWS object with "typ" header value "gnap-binding- rotation+jwsd".  The value of the JWS object is then taken as the payload of a new JWS object, to be signed by the new key. </ins> 8. GNAP provides a rich structure for describing the protected resources