Change:
"authorization", "confidentiality", "(data) integrity", "message authentication code", and "verify" are taken from RFC4949. <del> Since we describe exchanges as RESTful protocol interactions HTTP RFC7231 offers useful terminology. </del> <ins> RESTful terminology follows HTTP RFC7231. </ins> Terminology for entities in the architecture is defined in OAuth 2.0 <del> RFC6749 and I-D.ietf-ace-actors, such as client (C), resource server (RS), and authorization server (AS).  It is assumed in this document that a given resource on a specific RS is associated to a unique AS. </del> <ins> RFC6749, such as client (C), resource server (RS), and authorization server (AS).  It is assumed in this document that a given resource on a specific RS is associated to a unique AS. </ins> 2. <del> The use of OSCORE for arbitrary CoAP messages is specified in I- D.ietf-core-object-security.  This section defines the specific uses and their purpose for securing the communication between a client and a resource server, and the parameters needed to negotiate the use of this profile with the token resource at the authorization server as specified in section 5.6 of I-D.ietf-ace-oauth-authz. </del> <ins> This section gives an overview on how to use the ACE Framework I- D.ietf-ace-oauth-authz to secure the communication between a client and a resource server using OSCORE I-D.ietf-core-object-security. The parameters needed to negotiate the use of this profile with the token resource at the authorization server as specified in section 5.6 of I-D.ietf-ace-oauth-authz are described in detail in the following sections. This profile requires a client to retrieve an access token from the AS for the resource it wants to access on a RS, using the token endpoint, as specified in section 5.6.1 of I-D.ietf-ace-oauth-authz. To determine the AS in charge of a resource hosted at the RS, the client C MAY send an initial Unauthorized Resource Request message to the RS.  The RS then denies the request and sends the address of its AS back to the client C as specified in section 5.1 of I-D.ietf-ace- oauth-authz.  The access token request and response MUST be confidentiality-protected and ensure authenticity.  This profile RECOMMENDS the use of OSCORE between client and AS, but TLS or DTLS MAY be used additionally or instead. Once the client has retrieved the access token, it forwards it to the RS using the authz-info endpoint and mechanisms specified in section 5.8.1. of I-D.ietf-ace-oauth-authz.  If the access token is valid, the RS replies to this request with a 2.01 (Created) response, which contains a nonce N1. After receiving the nonce N1, the client generates a nonce N2, concatenates it with N1 and sets the ID Context in its Security Context (see section 3 of I-D.ietf-core-object-security) to N1 concatenated with N2.  The client then derives the complete Security Context from the ID Context plus the parameters received from the AS. Finally, the client sends a request protected with OSCORE to the RS. This message contains the ID Context value.  When receiving this request after the 2.01 (Created) response, the server extract the ID Context from it, verifies that the first part is equal to the nonce N1 it previously sent, and if so, sets its own ID Context and derives the complete Security Context from it plus the parameters received in the AS, following section 3.2 of I-D.ietf-core-object-security.  If the request verifies, then this Security Context is stored in the server, and used in the response, and in further communications with the client, until token expiration.  The client will not include the ID Context value in further requests. An overview of the profile flow for the OSCORE profile is given in prof-overview. 3. </ins> <del> 2.1. </del> <ins> The following subsections describe the details of the POST /token request and response between client and AS.  Section 3.2 of I-D.ietf- core-object-security defines how to derive a security context based on a shared master secret and a set of other parameters, established between client and server, which the client receives from the AS in this exchange.  The proof-of-possession key (pop-key) provisioned from the AS MUST be used as master secret in OSCORE. </ins> <del> A client requests a token at an AS via the /token resource.  This follows the message formats specified in section 5.6.1 of I-D.ietf- </del> <ins> 3.1. The client-to-AS request is specified in Section 5.6.1 of I-D.ietf- </ins> ace-oauth-authz. <del> The AS responding to a successful access token request as defined in section 5.6.2 of I-D.ietf-ace-oauth-authz can signal that the use of OSCORE is REQUIRED for a specific access token by including the "profile" parameter with the value "coap_oscore" in the access token response.  This means that the client MUST use OSCORE towards all resource servers for which this access token is valid, and follow oscore-only to derive the security context to run OSCORE. </del> <ins> If the client wants to update its access rights using the same OSCORE Security Context, it MUST include in its POST /token request a cnf object carrying the Sender ID in the kid field.  This identifier can be used by the AS to determine the shared secret to construct the proof-of-possession token and therefore MUST specify a symmetric key that was previously generated by the AS as a shared secret for the communication between the client and the RS. The client MUST send this POST /token request over a secure channel that guarantees authentication, message integrity and confidentiality (see introsp). An example of such a request, in CBOR diagnostic notation without the tag and value abbreviations is reported in ex0 3.2. After verifying the POST /token request and that the client is authorized to obtain an access token corresponding to its access token request, the AS responds as defined in section 5.6.2 of I- D.ietf-ace-oauth-authz.  It signals that the use of OSCORE is REQUIRED for a specific access token by including the "profile" parameter with the value "coap_oscore" in the access token response. This means that the client MUST use OSCORE towards all resource servers for which this access token is valid, and follow oscore-setup to derive the security context to run OSCORE. </ins> The error response procedures defined in section 5.6.3 of the ACE framework are unchanged by this profile. <del> Note the the client and the authorization server MAY OPTIONALLY use OSCORE to protect the interaction via the /token resource.  See c-as for details. 2.2. Section 3.2 of I-D.ietf-core-object-security defines how to derive a security context based on a shared master secret and a set of other parameters, established between client and server.  The proof-of- possession key (pop-key) provisioned from the AS MAY, in case of pre- shared keys, be used directly as master secret in OSCORE. If OSCORE is used directly with the symmetric pop-key as master secret, then the AS MUST provision the following data, in response to the access token request: </del> <ins> Moreover, the AS MUST provision the following data: </ins> a master secret <del> the sender identifier </del> <ins> a client identifier </ins> <del> the recipient identifier </del> <ins> a server identifier </ins> Additionally, the AS MAY provision the following data, in the same <del> response.  In case these parameters are omitted, the default values are used as described in section 3.2 of I-D.ietf-core-object- security. </del> <ins> response. </ins> an AEAD algorithm <del> a KDF algorithm </del> <ins> an HKDF algorithm </ins> a salt

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