Original text:
4. The ACE framework is based on the OAuth 2.0 protocol interactions <del> using the /token and /introspect resources.  A client obtains an access token from an AS using /token and presents the token to an RS to gain access to a protected resource.  Alternatively, or additionally, the RS can use an obtained access token with the AS /introspect resource to get information about the state and content of the access token.  These interactions are shown in fig:protocolFlow.  An overview of various OAuth concepts is provided in oauth2Overview. </del>  The consent of the resource owner, for giving a client access to a protected resource, can be pre-configured authorization policies or and the requesting party (= client owner) are not shown in fig:protocolFlow. <del> The ACE framework supports a wide variety of communication security between client, authorization server, and resource server.  We assume that the client has been registered to an AS.  Registration means that the two share credentials, configuration parameters and that some form of authorization has taken place.  These credentials are used to protect the token request by the client and the token response from AS to the client. It is also assumed that the RS has been registered with the AS. Established keying material between the AS and the RS allows the AS to apply cryptographic protection to the access token to ensure that its content cannot be modified, and if needed, that the content is confidentiality protected. </del>  The keying material necessary for establishing communication security between C and RS is dynamically established as part of the protocol At the start of the protocol there is an optional discovery step where the client discovers the resource server and the resources this server hosts.  In this step the client might also determine what <del> permissions are needed to access the protected resource.  The exact procedure SHOULD be defined in the ACE profile and depends on the protocols being used and the specific deployment environment.  In Bluetooth Smart, for example, advertisements are broadcasted by a peripheral, including information about the supported services.  In CoAP, as a second example, a client can makes a request to "/.well- known/core" to obtain information about available resources, which are returned in a standardized format as described in RFC6690. </del>  <del> FIXME: consider include client token in figure </del>  <del> The client makes an access token request to the /token resource at the AS.  This memo assumes the use of PoP tokens (see </del>  oauth2Overview for a short description) wherein the AS binds a key to an access token.  The client may include permissions it seeks to obtain, and information about the credentials it wants to use <del> (e.g. symmetric/asymmetric cryptography or a reference to a </del>  specific credential). If the AS successfully processes the request from the client, it <del> returns an access token.  It also includes various parameters, which we call "Client Information".  In addition to the response parameters defined by OAuth 2.0 and the PoP token extension, we consider new kinds of response parameters in tokenParams, including information on which profile the client should use with the resource server(s) that it has just been authorized to access. Communication security between client and RS may be based on pre- provisioned keys/security contexts or dynamically established. </del>  The RS authenticates the client via the PoP token; and the client authenticates the RS according to the profile that was specified <del> in the Client Information.  FIXME: Could we say that client and RS mutually authenticates using the security protocol of the profile and the keys obtained in access token or client information. </del>  The client interacts with the RS to request access to the protected resource and provides the access token.  The protocol to <del> use between the client and the RS is not restricted to CoAP; HTTP, HTTP/2, Bluetooth Smart etc., are also possible candidates. </del>  Depending on the device limitations and the selected protocol this exchange may be split up into two parts: A resource server may be configured to introspect the access token <del> by including it in a request to the /introspect resource at that </del>  AS.  Token introspection over CoAP is defined in introspectionResource and for HTTP in RFC7662. The AS validates the token and returns the most recent parameters, such as scope, audience, validity etc. associated with it back to the RS.  The RS then uses the received parameters to process the <del> request to either accept or to deny it.  FIXME: Mention client token. </del>  request and returns a response with the appropriate response code. The RS uses the dynamically established keys to protect the response, according to used communication security protocol. <del> FIXME: Mention client token. </del>  5.

Reviewer comments:
I have reviewed the protocol section and have made some minor edits. I believe the section is looking good. There were only two items that I believe are worthwhile to discuss: I prefer to use the term endpoint for the /token and /introspect rather than calling them resource. The term endpoint is used in the terminology section and aligns with OAuth. The client token is mentioned in this section and even after looking at the text later in the document I didn't really understood the concept.
Looks good to me. Does anyone else have a strong opinion on the use of "endpoint" vs "resource"? We might need to put a note into the text somewhere to clarify, since CoAP IMHO uses "endpoint" with a slightly different meaning.

Revised text:
4. The ACE framework is based on the OAuth 2.0 protocol interactions  <ins> using the /token and /introspect endpoints.  A client obtains an access token from an AS using the /token endpoint and subsequently presents the access token to an RS to gain access to a protected resource.  The RS, after receiving an access token, may present it to the AS via the /introspect endpoint to get information about the state and content of the access token.  In other deployments the RS may process the access token locally without the need to contact an AS.  These interactions are shown in fig:protocolFlow.  An overview of various OAuth concepts is provided in oauth2Overview. </ins> The consent of the resource owner, for giving a client access to a protected resource, can be pre-configured authorization policies or and the requesting party (= client owner) are not shown in fig:protocolFlow.  <ins> This framework supports a wide variety of communication security mechanisms between the ACE entities, such as client, authorization server, and resource server.  We assume that the client has been registered (also called enrolled or onboarded) to an AS using a mechanism defined outside the scope of this document.  In practice, various techniques for onboarding have been used, such as factory- based provisioning or the use of commissioning tools.  Regardless of the onboarding technique, this registration procedure implies that the client and the AS share credentials, and configuration parameters.  These credentials are used to mutually authenticate each other and to protect messages exchanged between the client and the AS. It is also assumed that the RS has been registered with the AS, potentially in a similar way as the client has been registered with the AS.  Established keying material between the AS and the RS allows the AS to apply cryptographic protection to the access token to ensure that its content cannot be modified, and if needed, that the content is confidentiality protected. </ins> The keying material necessary for establishing communication security between C and RS is dynamically established as part of the protocol At the start of the protocol there is an optional discovery step where the client discovers the resource server and the resources this server hosts.  In this step the client might also determine what  <ins> permissions are needed to access the protected resource.  The detailed procedures for this discovery process may be defined in an ACE profile and depend on the protocols being used and the specific deployment environment. In Bluetooth Low Energy, for example, advertisements are broadcasted by a peripheral, including information about the primary services. In CoAP, as a second example, a client can makes a request to "/.well-known/core" to obtain information about available resources, which are returned in a standardized format as described in RFC6690. </ins>  <ins> (FIXME: The Client Token is missing in the figure.) </ins>  <ins> The client makes an access token request to the /token endpoint at the AS.  This framework assumes the use of PoP tokens (see </ins> oauth2Overview for a short description) wherein the AS binds a key to an access token.  The client may include permissions it seeks to obtain, and information about the credentials it wants to use  <ins> (e.g., symmetric/asymmetric cryptography or a reference to a </ins> specific credential). If the AS successfully processes the request from the client, it  <ins> returns an access token.  It also returns various parameters, referred as "Client Information".  In addition to the response parameters defined by OAuth 2.0 and the PoP token extension, further response parameters, such as information on which profile the client should use with the resource server(s).  More informatino about these parameters can be found in in tokenParams. </ins> The RS authenticates the client via the PoP token; and the client authenticates the RS according to the profile that was specified  <ins> in the Client Information.  (FIXME: Could we say that client and RS mutually authenticates using the security protocol of the profile and the keys obtained in access token or client information.) </ins> The client interacts with the RS to request access to the protected resource and provides the access token.  The protocol to  <ins> use between the client and the RS is not restricted to CoAP. HTTP, HTTP/2, QUIC, MQTT, Bluetooth Low Energy, etc., are also viable candidates. </ins> Depending on the device limitations and the selected protocol this exchange may be split up into two parts: A resource server may be configured to introspect the access token  <ins> by including it in a request to the /introspect endpoint at that </ins> AS.  Token introspection over CoAP is defined in introspectionResource and for HTTP in RFC7662. The AS validates the token and returns the most recent parameters, such as scope, audience, validity etc. associated with it back to the RS.  The RS then uses the received parameters to process the  <ins> request to either accept or to deny it.  (FIXME: Mention client token.) </ins> request and returns a response with the appropriate response code. The RS uses the dynamically established keys to protect the response, according to used communication security protocol.  <ins> (FIXME: Mention client token.) </ins> 5.