Draft: draft-ietf-gnap-core-protocol

Commentary: 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 ? 
 am I right that becomes immediately invalid ? If it 's true , would n'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  ) . Thank you . 
 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 . 
 Rotating the Access Token :  '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 do n'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 :  '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 does n't necessarily have to be . 
 See my comment on pull request I think we need to find a single rotation recovery method . I collected my ideas here : 
 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 and other comments in this PR ? Thank you . 
 what do you mean by " more or less gracefully " ? 
 you can omit " more or less gracefully " , I wanted to know if  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 .
Paragraph (version B):
The "proof" method and parameters for the new key MUST be the same as
those established for the previous key.
Paragraph (version B):
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):
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.
Paragraph (version A):
A key presented by value MUST be a public key in at least one
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
value cryptographically derived from the public key.
Paragraph (version B):
A key presented by value MUST be a public key in at least one
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
value cryptographically derived from the public key.  See additional
discussion of public keys in security-symmetric.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
The verifier MUST validate both signatures before processing the
request for key rotation.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.