Original text:
Moreover, implementers of this specification need to be aware that if other authentication mechanisms are used to set up OSCORE between the same client and RS, that do not rely on AS assigning identifiers, <del> collisions may happen and need to be mitigated. </del>  Note that in oscore-setup C sets the Sender ID of its Security Context to the clientId value received and the Recipient ID to the abbreviations. The same CWT token as in ex2, using the value abbreviations defined <del> in I-D.ietf-ace-oauth-authz and I-D.ietf-ace-cwt-proof-of-possession and encoded in CBOR is shown in ex2-cbor. </del>  NOTE TO THE RFC EDITOR: before publishing, it should be checked (and in case fixed) that the values used below (which are not yet Note that a client may be required to re-POST the access token in order to complete a request, since an RS may delete a stored access <del> token at any time, for example due to all storage space being consumed.  This situation is detected by the client when it receives an AS Request Creation Hints response. </del>  ex3 shows an example of the request sent from the client to the RS, with payload in CBOR diagnostic notation without the tag and value abbreviations.  The access token has been truncated for readability.  4.1.1. This parameter MUST be sent from the client to the RS, together with with payload in CBOR diagnostic notation without the tag and value abbreviations.  As specified in section 5.8.1 of I-D.ietf-ace-oauth-authz, when receiving an updated access token with updated authorization information from the client (see c-as), it is recommended that the RS simplifies for the RS to keep track of authorization information for a given client. <del> As specified in section 5.8.3 of I-D.ietf-ace-oauth-authz, the RS must notify the client with an error response with code 4.01 (Unauthorized) for any long running request before terminating the session, when the access token expires. </del> 4.2.1. This parameter MUST be sent from the RS to the Client if the ace error message to requests received that correspond to a Security Context with an expired token. <del> If the exchange was an update of access rights, i.e., a new Security Context was derived from a client that already had a Security Context in place, the RS is RECOMMENDED to delete the old Security Context after OSCORE verification and verification of access rights succeed. The RS MUST delete the Security Context if it deletes the access token associated to it.  If the exchange was an update of access rights, i.e., a new Security Context was derived from a client that already had a Security Context in place, the RS is RECOMMENDED to delete the old Security Context after OSCORE verification succeeds. The RS MUST delete the Security Context if it deletes the access token associated to it. </del> 4.4. The RS MUST follow the procedures defined in section 5.8.2 of I- There are a number of scenarios where a client or RS needs to discard the OSCORE security context, and acquire a new one. <del> The client MUST discard the current security context associated with </del>  an RS when: the Sequence Number space ends. the access token associated with the context expires. the client receives a number of 4.01 Unauthorized responses to <del> OSCORE requests using the same security context.  The exact number </del>  needs to be specified by the application. the client receives a new nonce in the 2.01 (Created) response (see rs-c) to a POST request to the authz-info endpoint, when re- posting a (non-expired) token associated to the existing context. <del> The RS MUST discard the current security context associated with a </del>  client when: the Sequence Number space ends. the access token associated with the context expires.  7. This document specifies a profile for the Authentication and 9.5. The following registration is done for the CWT Confirmation Methods <del> Registry following the procedure specified in section 7.2.1 of I- D.ietf-ace-cwt-proof-of-possession: </del>  Confirmation Method Name: "osc" Confirmation Method Description: OSCORE_Security_Context carrying

Reviewer comments:
OCF comments.
check that re-sending token triggers nonces exchange and new security context derived.
add a implementation note about namespaces for identifiers in case several methods are used (EDHOC, ACE, others)

Revised text:
Moreover, implementers of this specification need to be aware that if other authentication mechanisms are used to set up OSCORE between the same client and RS, that do not rely on AS assigning identifiers,  <ins> collisions may happen and need to be mitigated.  A mitigation example would be to use distinct namespaces of identifiers for different authentication mechanisms. </ins> Note that in oscore-setup C sets the Sender ID of its Security Context to the clientId value received and the Recipient ID to the abbreviations. The same CWT token as in ex2, using the value abbreviations defined  <ins> in I-D.ietf-ace-oauth-authz and RFC8747 and encoded in CBOR is shown in ex2-cbor. </ins> NOTE TO THE RFC EDITOR: before publishing, it should be checked (and in case fixed) that the values used below (which are not yet Note that a client may be required to re-POST the access token in order to complete a request, since an RS may delete a stored access  <ins> token (and associated Security Context) at any time, for example due to all storage space being consumed.  This situation is detected by the client when it receives an AS Request Creation Hints response. Reposting the same access token will result in deriving a new OSCORE Security Context to be used with the RS, as different nonces will be used. </ins> ex3 shows an example of the request sent from the client to the RS, with payload in CBOR diagnostic notation without the tag and value abbreviations.  The access token has been truncated for readability. <ins> If the client has already posted a valid token, has already established a security association with the RS, and wants to update its access rights, the client can do so by posting the new token (retrieved from the AS and containing the update of access rights) to the /authz-info endpoint.  The client MUST protect the request using the OSCORE Security Context established during the first token exchange.  The client MUST only send the access token in the payload, no nonce is sent.  After proper verification (see rs-c), the RS will replace the old token with the new one, maintaining the same Security Context. </ins> 4.1.1. This parameter MUST be sent from the client to the RS, together with with payload in CBOR diagnostic notation without the tag and value abbreviations. <ins> As specified in section 5.8.3 of I-D.ietf-ace-oauth-authz, the RS must notify the client with an error response with code 4.01 (Unauthorized) for any long running request before terminating the session, when the access token expires. If the RS receives the token in a OSCORE protected message, it means that the client is requesting an update of access rights.  The RS MUST discard any nonce in the request, if any was sent.  The RS MUST check that the "kid" of the "cnf" parameter of the new access token matches the OSCORE Security Context used to protect the message.  If that's the case, the RS MUST discard the old token and associate the new token to the Security Context identified by "kid".  The RS MUST respond with a 2.01 (Created) response protected with the same Security Context, with no payload.  If any verification fails, the RS MUST respond with a 4.01 (Unauthorized) error response. </ins> As specified in section 5.8.1 of I-D.ietf-ace-oauth-authz, when receiving an updated access token with updated authorization information from the client (see c-as), it is recommended that the RS simplifies for the RS to keep track of authorization information for a given client.  4.2.1. This parameter MUST be sent from the RS to the Client if the ace error message to requests received that correspond to a Security Context with an expired token.  4.4. The RS MUST follow the procedures defined in section 5.8.2 of I- There are a number of scenarios where a client or RS needs to discard the OSCORE security context, and acquire a new one.  <ins> The client MUST discard the current Security Context associated with </ins> an RS when: the Sequence Number space ends. the access token associated with the context expires. the client receives a number of 4.01 Unauthorized responses to  <ins> OSCORE requests using the same Security Context.  The exact number </ins> needs to be specified by the application. the client receives a new nonce in the 2.01 (Created) response (see rs-c) to a POST request to the authz-info endpoint, when re- posting a (non-expired) token associated to the existing context.  <ins> The RS MUST discard the current Security Context associated with a </ins> client when: the Sequence Number space ends. the access token associated with the context expires. <ins> the client has successfully replaced the current security context with a newer one by posting an access token to the unprotected /authz-info endpoint at the RS, e.g., by re-posting the same token, as specified in c-rs. Whenever one more access token is successfully posted to the RS, and a new Security Context is derived between the client and RS, messages in transit that were protected with the previous Security Context might not pass verification, as the old context is discarded.  That means that messages sent shortly before the client posts one more access token to the RS might not successfully reach the destination. Analogously, implementations may want to cancel CoAP observations at the RS registered before the Security Context is replaced, or conversely they will need to implement a mechanism to ensure that those observation are to be protected with the newly derived Security Context. </ins> 7. This document specifies a profile for the Authentication and 9.5. The following registration is done for the CWT Confirmation Methods  <ins> Registry following the procedure specified in section 7.2.1 of RFC8747: </ins> Confirmation Method Name: "osc" Confirmation Method Description: OSCORE_Security_Context carrying