Change:
I went through the overview section and updated the text. The text is already good and only a few minor changes had to be made. I believe we may need to determine (some time in the future) whether it is worthwhile to combine the introduction with the text in the overview section since there is some overlap.
I spotted a few sentences that were missing a word to make sense. I'll go through and try to fix this on Monday, unless someone else manages before me. Otherwise the changes look fine.

Discussion:
Another building block is the lightweight web transfer protocol CoAP RFC7252 for those communication environments where HTTP is not appropriate.  CoAP typically runs on top of UDP which further reduces <del> overhead and message exchanges.  Transport layer security can be provided either by DTLS 1.2 RFC6347 or TLS 1.2 RFC5246.  Application layer security can be provided by OSCOAP I-D.selander-ace-object- security. </del> <ins> overhead and message exchanges.  While this specification defines extensions for the use of OAuth over CoAP, we do envision further underlying protocols to be supported in the future, such as MQTT or QUIC.  For communication security DTLS 1.2 RFC6347 or TLS 1.2 RFC5246.  Application layer security for CoAP can be provided by OSCOAP I-D.selander-ace-object-security. </ins> A third building block is CBOR RFC7049 for encodings where JSON RFC7159 is not sufficiently compact.  CBOR is a binary encoding <del> designed for extremely small code size and fairly small message size. OAuth 2.0 allows access tokens to use different encodings and this document defines such an alternative encoding.  The COSE message format I-D.ietf-cose-msg is also based on CBOR. A fourth building block is object security, which is already used in OAuth 2.0 with PoP tokens I-D.ietf-oauth-pop-architecture, but is here extended to so called "Client Tokens" (clientToken).  Also, this specification allows the use of object security instead of transport layer security between any nodes in the architecture.  A preferred compact secure message format is COSE I-D.ietf-cose-msg, which adds object security to CBOR-encoded data.  More details about applying COSE to CoAP can be found in OSCOAP I-D.selander-ace-object-security. </del> <ins> designed for small code and message size.  OAuth 2.0 allows access tokens to use different encodings and this document defines such an alternative encoding.  To protect these CBOR-encoded access tokens the CBOR encoded message syntax I-D.ietf-cose-msg is re-used. As a fourth building block we use proof-of-possession (PoP) tokens I- D.ietf-oauth-pop-architecture, which is an extension to the OAuth access tokens.  Additionally, those PoP tokens are extended with called "Client Tokens" (see clientToken).  As an additional security enhancement, this specification allows the use of object security instead of transport layer security between any nodes in the architecture.  A preferred compact secure message format is COSE I- D.ietf-cose-msg, which adds object security to CBOR-encoded data. More details about applying COSE to CoAP can be found in OSCOAP I- D.selander-ace-object-security. </ins> With the building blocks listed above, solutions satisfying various IoT device and network constraints are possible.  A list of

<del> The AS resource (in OAuth 2.0 called "endpoint") /token is the resource targeted by a Client requesting an access token for use when accessing a resource on the RS.  The client makes a POST request to /token on the AS and receives the access token in the POST response. </del> <ins> The AS hosts the /token endpoint that allows a client to request access tokens.  The client makes a POST request to the /token endpoint on the AS and receives the access token in the response (if the request was successful). </ins> <del> The AS resource /introspect is the resource targeted by an RS when requesting additional information regarding a received access </del> <ins> The token introspection endpoint, /introspect, is used by the RS when requesting additional information regarding a received access </ins> token.  The RS makes a POST request to /introspect on the AS and <del> receives such information in the POST response.  (See "Introspection" below.) </del> <ins> receives information about the access token contain in the response.  (See "Introspection" below.) </ins> <del> Access tokens are credentials used to access protected resources. An access token is a data structure representing authorization permissions issued to the client.  Access tokens are generated by the authorization server and consumed by the resource server.  The access token is opaque to the client. </del> <ins> Access tokens are credentials needed to access protected resources.  An access token is a data structure representing authorization permissions issued by the AS to the client.  Access tokens are generated by the authorization server and consumed by the resource server.  The access token content is opaque to the client. </ins> Access tokens can have different formats, and various methods of utilization (e.g., cryptographic properties) based on the security

corresponding private key for the proof of possession. The access token is protected against modifications using a MAC or <del> a digital signature of the AS.  The choice of PoP key does not necessarily imply a specific credential type for the integrity protection of the token.  More information about PoP tokens can be found in I-D.ietf-oauth-pop-architecture. </del> <ins> a digital signature, which is added by the AS.  The choice of PoP key does not necessarily imply a specific credential type for the integrity protection of the token.  More information about PoP tokens can be found in I-D.ietf-oauth-pop-architecture. </ins> In OAuth 2.0, the client specifies the type of permissions it is seeking to obtain (via the scope parameter) in the access request. <del> In turn, the AS may use the "scope" response parameter to inform the client of the scope of the access token issued.  As the client </del> <ins> In turn, the AS may use the scope response parameter to inform the client of the scope of the access token issued.  As the client </ins> could be a constrained device as well, this memo uses CBOR encoded <del> messages defined in oauthProfile to request scopes and to be informed what scopes the access token was actually authorized for by the AS. </del> <ins> messages for CoAP, defined in oauthProfile, to request scopes and to be informed what scopes the access token was actually authorized for by the AS. </ins> The values of the scope parameter are expressed as a list of space- delimited, case-sensitive strings, with a semantic that is

<del> The information carried in the access token in the form of type- value pairs is called parameters.  [FIXME: This gives the </del> <ins> Information carried in the access token, called claims, is in the form of type-value pairs.  [FIXME: This statement may give the </ins> impression that "parameter" is only used to describe the attributes in the access token and not in messages in general.] <del> An access token may for example include a parameter about the AS that issued the token (the "iss" parameter) and what audience the access token is intended for (the "aud" parameter).  The audience of an access token can be a specific resource or one or many resource servers.  The resource owner policies influence what parameters are put into the access token by the authorization server. </del> <ins> An access token may, for example, include a claim identifying the AS that issued the token (via the "iss" parameter) and what audience the access token is intended for (via the "aud" parameter).  The audience of an access token can be a specific resource or one or many resource servers.  The resource owner policies influence what claims are put into the access token by the authorization server. </ins> While the structure and encoding of the access token varies throughout deployments, a standardized format has been defined

where the authorization decisions are very dynamic and/or where the received access token itself is a reference rather than a self-contained token.  More information about introspection in <del> OAuth 2.0 can be found in I-D.ietf-oauth-introspection. </del> <ins> OAuth 2.0 can be found in RFC7662. </ins> 3.2.

called 'options'. CoAP supports application-layer fragmentation of the CoAP payloads <del> through blockwise transfers I-D.ietf-core-block.  However, this method does not allow the fragmentation of large CoAP options, therefore data encoded in options has to be kept small. </del> <ins> through blockwise transfers I-D.ietf-core-block.  However, block-wise transfer does not increase the size limits of CoAP options, therefore data encoded in options has to be kept small. </ins> Transport layer security for CoAP can be provided by DTLS 1.2 RFC6347 or TLS 1.2 RFC5246.  CoAP defines a number of proxy operations which

proxies, and also to support security for CoAP over different transport in a uniform way, is to provide security on application layer using an object-based security mechanism such as CBOR Encoded <del> Message Syntax (COSE) I-D.ietf-cose-msg. </del> <ins> Message Syntax I-D.ietf-cose-msg. </ins> One application of COSE is OSCOAP I-D.selander-ace-object-security, which provides end-to-end confidentiality, integrity and replay