Original text:
the client's pre-registered record.  See additional considerations regarding client instance impersonation in security-impersonation.  2.3.1. If the client instance has an instance identifier that the AS can use the JSON Web Token (JWT) format and the related JSON Object Signing And Encryption (JOSE) cryptography suite.  13. The privacy considerations in this section are modeled after the list

Reviewer comments:
Added security considerations for cuckoo token,
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 31f2c2dc7998639fe7801edeaa8334eef14d0963 Inspect the deploy log: Browse the preview:
Client instance uses different keys with each AS Stolen token bound to different keys, RS will reject Client has strong binding between RS and AS used Attacker can’t convince client to use “wrong” AS

Revised text:
the client's pre-registered record.  See additional considerations regarding client instance impersonation in security-impersonation. <ins> A client instance that is capable of talking to multiple AS's SHOULD use a different key for each AS to prevent a class of mix-up attacks as described in security-cuckoo. </ins> 2.3.1. If the client instance has an instance identifier that the AS can use the JSON Web Token (JWT) format and the related JSON Object Signing And Encryption (JOSE) cryptography suite. <ins> 12.27. If a client instance can request tokens at multiple AS's, and the client instance uses the same keys to make its requests across those different AS's, then it is possible for an attacker to replay a stolen token issued by an honest AS from a compromised AS, thereby binding the stolen token to the client instance's key in a different context.  The attacker can manipulate the client instance into using the stolen token at an RS, particularly at an RS that is expecting a token from the honest AS.  Since the honest AS issued the token and the client instance presents the token with its expected bound key, the attack succeeds. This attack has several preconditions.  In this attack, the attacker does not need access to the client instance's key and cannot use the stolen token directly at the RS, but the attacker is able to get the access token value in some fashion.  The client instance also needs to be configured to talk to multiple AS's, including the attacker's controlled AS.  Finally, the client instance needs to be able to be manipulated by the attacker to call the RS while using a token issued from the stolen AS.  The RS does not need to be compromised or made to trust the attacker's AS. To protect against this attack, the client instance can use a different key for each AS that it talks to.  Since the replayed token will be bound to the key used at the honest AS, the uncompromised RS will reject the call since the client instance will be using the key used at the attacker's AS instead with the same token.  When the MTLS key proofing method is used, a client instance can use self-signed certificates to use a different key for each AS that it talks to, as discussed in security-mtls-patterns. Additionally, the client instance can keep a strong association between the RS and a specific AS that it trusts to issue tokens for that RS.  This strong binding also helps against some forms of security-mixup.  Managing this binding is outside the scope of GNAP core, but it can be managed either as a configuration element for the client instance or dynamically through rs-request-without-token. The details of this attack are available in HELMSCHMIDT2022 with additional discussion and considerations. </ins> 13. The privacy considerations in this section are modeled after the list