Change:
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

Discussion:
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.