Change:
case the RS needs to have a mechanism in place to disambiguate identifiers or mitigate their effect. <del> Note that C should set the Sender ID of its security context to the </del> <ins> Note that C should set the Sender ID of its Security Context to the </ins> clientId value received and the Recipient ID to the serverId value, and RS should do the opposite. <del> Figure 1 shows an example of such an AS response, in CBOR diagnostic </del> <ins> ex1 shows an example of such an AS response, in CBOR diagnostic </ins> notation without the tag and value abbreviations. <del> Figure 2 shows an example CWT, containing the necessary OSCORE parameters in the 'cnf' claim, in CBOR diagnostic notation without tag and value abbreviations. Note that the proof-of-possession required to bind the access token to the client is implicitly performed by generating the shared OSCORE context using the pop-key as master secret, both on the client and RS side.  An attacker using a stolen token will not be able to generate a valid OSCORE context and thus not be able to prove possession of the pop-key. </del> <ins> ex2 shows an example CWT, containing the necessary OSCORE parameters in the 'cnf' claim, in CBOR diagnostic notation without tag and value abbreviations. </ins> <del> 3. </del> <ins> If the client has requested an update to its access rights using the same OSCORE Security Context, and the token associated with it is not expired, the AS MAY omit the master secret and server identifier both in the COSE_Key in the 'cnf' parameter and in the token.  The client identifier needs to be provisioned, in order for the RS to identify the previously generated Security Context. </ins> <del> As specified in the ACE framework (section 5.6 of I-D.ietf-ace-oauth- authz), the Client and AS can also use CoAP instead of HTTP to communicate via the token resource.  This section specifies how to use OSCORE between Client and AS together with CoAP.  The use of OSCORE for this communication is OPTIONAL in this profile, other security protocols (such as DTLS) MAY be used instead. </del> <ins> ex5 shows an example of such an AS response, in CBOR diagnostic notation without the tag and value abbreviations. </ins> <del> The client and the AS are expected to have pre-established security contexts in place.  How these security contexts are established is out of scope for this profile.  Furthermore the client and the AS communicate using OSCORE (I-D.ietf-core-object-security) through the introspection resource as specified in section 5.7 of I-D.ietf-ace- oauth-authz. </del> <ins> ex6 shows an example CWT, containing the necessary OSCORE parameters in the 'cnf' claim for update of access rights, in CBOR diagnostic notation without tag and value abbreviations. </ins> 4. <del> As specified in the ACE framework (section 5.7 of I-D.ietf-ace-oauth- authz), the RS and AS can also use CoAP instead of HTTP to communicate via the introspection resource.  This section specifies how to use OSCORE between RS and AS.  The use of OSCORE for this communication is OPTIONAL in this profile, other security protocols (such as DTLS) MAY be used instead. The RS and the AS are expected to have pre-established security contexts in place.  How these security contexts are established is out of scope for this profile.  Furthermore the RS and the AS communicate using OSCORE (I-D.ietf-core-object-security) through the introspection resource as specified in section 5.7 of I-D.ietf-ace- oauth-authz. </del> <ins> The following subsections describe the details of the POST /authz- info request and response between client and RS.  The client posts the token that includes the materials provisioned by the AS to the RS, which can then use Section 3.2 of I-D.ietf-core-object-security to derive a security context based on a shared master secret and a set of other parameters, established between client and server. Note that the proof-of-possession required to bind the access token to the client is implicitly performed by generating the shared OSCORE Security Context using the pop-key as master secret, for both client and RS.  An attacker using a stolen token will not be able to generate a valid OSCORE context and thus not be able to prove possession of the pop-key. 4.1. The client MUST use CoAP and the Authorization Information endpoint as described in section 5.8.1 of I-D.ietf-ace-oauth-authz to transport the token to the RS. The authz-info endpoint is not protected, nor are the responses from this endpoint. The access token MUST be encrypted, since it is transferred from the client to the RS over an unprotected channel. ex3 shows an example of the request sent from the client to the RS. 4.2. The RS MUST follow the procedures defined in section 5.8.1 of I- D.ietf-ace-oauth-authz: the RS MUST verify the validity of the token. If the token is valid, the RS MUST respond to the POST request with 2.01 (Created).  This response MAY contain an identifier of the token (e.g., the cti for a CWT) as a payload, in order to allow the client to refer to the token.  If the token is valid but is associated to claims that the RS cannot process (e.g., an unknown scope) the RS MUST respond with a response code equivalent to the CoAP code 4.00 (Bad Request).  In the latter case the RS MAY provide additional information in the error response, in order to clarify what went wrong.  The RS MAY make an introspection request to validate the token before responding to the POST request to the authz-info endpoint. Additionally, the RS MUST generate a nonce (N1) with a good amount of randomness, and include it in the payload of the 2.01 (Created) response as a CBOR byte string.  This profile RECOMMENDS to use a nonce of 64 bits.  The RS MUST store this nonce as long as the access token related to it is still valid. ex4 shows an example of the response sent from the RS to the client. 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. 4.3. Once receiving the 2.01 (Created) response from the RS, following the POST /authz-info request, the client MUST extract the nonce N1 from the CBOR byte string in the payload of the response.  The client MUST generate itself a nonce (N2) with a good amount of randomness.  This profile RECOMMENDS to use a nonce of 64 bits.  Then, the client MUST set the ID Context of the Security Context created to communicate with the RS to the concatenation of N1 and N2, in this order: ID Context = N1 | N2, where | denotes byte string concatenation.  The client MUST set the Master Secret, Sender ID and Recipient ID from the parameters received from the AS in as-c.  The client MUST set the AEAD Algorithm, Master Salt, HKDF and Replay Window from the parameters received from the AS in as-c, if present.  In case these parameters are omitted, the default values are used as described in section 3.2 of I-D.ietf-core-object-security.  After that, the client MUST derive the complete Security Context following section 3.2.1 of I-D.ietf-core-object-security.  From this point on, the client MUST use this Security Context to communicate with the RS when accessing the resources as specified by the authorization information. The client then uses this Security Context to send requests to RS using OSCORE.  In the first request sent to the RS, the client MUST include the kid context, with value ID Context, i.e. N1 concatenated with N2.  The client needs to make sure the RS receives the kid context, possibly adding the kid context to later requests, until it receives a valid OSCORE response from the RS using the same Security Context. When the RS receives this first OSCORE-protected request, it MUST extract the kid context from the message first.  Then, it needs to verify that the first part of the kid context corresponds to the nonce N1 it previously sent, and that it is followed by a non-zero- length byte string.  If that is verified, the RS MUST set the ID Context to the kid context value.  Then, the RS MUST set the Master Secret, Sender ID and Recipient ID from the parameters received from the client in the access token in c-rs.  The RS MUST set the AEAD Algorithm, Master Salt, HKDF and Replay Window from the parameters received from the client in the access token in c-rs, if present.  In case these parameters are omitted, the default values are used as described in section 3.2 of I-D.ietf-core-object-security.  After that, the RS MUST derive the complete Security Context following section 3.2.1 of I-D.ietf-core-object-security, and MUST associate this Security Context with the authorization information from the access token.  Then, the RS MUST delete the nonce N1 from memory. The RS then uses this Security Context to verify the request and send responses to RS using OSCORE.  If OSCORE verification fails, error responses are used, as specified in section 8 of I-D.ietf-core- object-security.  Additionally, if OSCORE verification succeeds, the verification of access rights is performed as described in section tok-ver.  The RS MUST NOT use the Security Context after the related token has expired, and MUST respond with a unprotected 4.01 (Unauthorized) error message. 4.4. The RS MUST follow the procedures defined in section 5.8.2 of I- D.ietf-ace-oauth-authz: if an RS receives a OSCORE-protected request from a client, then it processes according to I-D.ietf-core-object- security.  If OSCORE verification succeeds, and the target resource requires authorization, the RS retrieves the authorization information from the access token associated to the Security Context. The RS then MUST verify that the authorization information covers the resource and the action requested. The response code MUST be 4.01 (Unauthorized) in case the client has not used the Security Context associated with the access token, or if RS has no valid access token for the client.  If RS has an access token for the client but not for the resource that was requested, RS MUST reject the request with a 4.03 (Forbidden).  If RS has an access token for the client but it does not cover the action that was requested on the resource, RS MUST reject the request with a 4.05 (Method Not Allowed). </ins> 5. <ins> As specified in the ACE framework (section 5.7 of I-D.ietf-ace-oauth- authz), the requesting entity (RS and/or client) and the AS communicates via the introspection or token endpoint.  The use of CoAP and OSCORE for this communication is RECOMMENDED in this profile, other protocols (such as HTTP and DTLS or TLS) MAY be used instead. If OSCORE is used, the requesting entity and the AS are expected to have pre-established security contexts in place.  How these security contexts are established is out of scope for this profile. Furthermore the requesting entity and the AS communicate using OSCORE (I-D.ietf-core-object-security) through the introspection endpoint as specified in section 5.7 of I-D.ietf-ace-oauth-authz and through the token endpoint as specified in section 5.6 of I-D.ietf-ace-oauth- authz. 6. </ins> This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework I-D.ietf- ace-oauth-authz.  Thus the general security considerations from the

Discussion:
restructuring for readability adding a section for protocol overview adding examples for each message adding details about updating clients rights (request new token with only scope different) where before there were ref to the framework, explicitly state all the normative text add mechanism during OSCORE Setup for making sure the context is not reused on the server if token is re-posted after it has been lost/removed (nonces) added section about access rights verification between OSCORE layer and CoAP (handling of the resource) layer