Original text:
<del> If the request from the client is successful (i.e. correct and authorized), the AS returns an access token and optionally a refresh token (note that only certain grant types support refresh tokens).  It can also return additional parameters, referred to as "Access Information".  In addition to the response parameters defined by OAuth 2.0 and the PoP access token extension, this framework defines parameters that can be used to inform the client about capabilities of the RS, e.g.  the profile the RS supports. More information about these parameters can be found in tokenParams. </del>  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 <del> 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 In constrained environments it cannot be assumed that the client <del> and RS are part of a common key infrastructure.  Therefore the AS provisions credentials or associated information to allow mutual authentication between client and RS.  The resulting security association between client and RS may then also be used to bind these credentials to the access tokens the client uses. </del>  The message can also contain the following OPTIONAL parameters: <del> A "audience" element containing a suggested audience that the client should request at the AS (see audience for a discussion of this parameter). </del>  A "kid" element containing the key identifier of a key used in an existing security association between the client and the RS.  The In the example above, the response parameter "AS" points the receiver of this message to the URI "coaps://as.example.com/token" to request <del> access tokens.  The RS sending this response (i.e., RS) uses an internal clock that is not synchronized with the clock of the AS. Therefore it can not reliably verify the expiration time of access tokens it receives.  To ensure a certain level of access token freshness nevertheless, the RS has included a "cnonce" parameter (see cnonceParam) in the response. </del>  fig:as-info-cbor illustrates the mandatory to use binary encoding of the message payload shown in fig:as-info-payload. If HTTPS is used, JSON or CBOR payloads may be supported.  If JSON payloads are used, the semantics of Sections 4.1.3 and 4.1.4 of the OAuth 2.0 specification MUST be followed (with additions as described <del> below).  If CBOR payload is supported, the semantics described in this section MUST be followed. </del>  For the AS to be able to issue a token, the client MUST be authenticated and present a valid grant for the scopes requested. client and how the communication between client and AS is protected, fulfilling the requirements specified in oauthProfile. <del> The default name of this endpoint in an url-path is '/token', however implementations are not required to use this name and can define their own instead. </del>  The figures of this section use CBOR diagnostic notation without the integer abbreviations for the parameters or their values for

Reviewer comments:
This terminology decision was made in early days of OAuth = long time ago. Done. Done. Changed. I added a note that this confidentiality protection of the access token happens on top of the protection offered by the underlying communication security protocol. Text added. >-- Section 5 -- Text changed. >-- Section 5.1.1 -- >Could the word "unprotected" be better defined in "received on an unprotected channel" ? E.g., is it only about TLS ? Else, I like the implicit lack of trust. Text changed to "unsecured channel" >-- Section 5.1.2 -- I assume you mean "Section 5.3". Text added. >-- Section 5.5 -- >In "Since it requires the use of a user agent (i.e., browser)" is it "i.e." or "e.g." ? I cannot find this text in the document. >-- Section 5.6 -- OK OK. >-- Section 5.6.4.1 -- >In figure 11, would you mind adding the section ID in addition to RFC 6749 ? I failed to spot them in RFC 6749. Done. >-- Section 5.7.2 -- >It is a little unclear to me which profile must be used as 'profile' is optionnial? Should a default or any profile be used ? I cannot find this text. >-- Section 5.8.1 -- >Suggest to use the BCP14 "SHOULD" in the text "The default name of this endpoint in an url-path is '/authz-info'" Changed. >-- Section 10.2 -- >Is RFC 7049 really an informative reference as CBOR appears as the default encoding ? Changed to a normative reference and updated reference. All nits below have been addressed.
Comments addressed in this PR: URL
Merged

Revised text:
 <ins> If the request from the client has been successfully verified, authenticated, and authorized, the AS returns an access token and optionally a refresh token.  Note that only certain grant types support refresh tokens.  The AS can also return additional parameters, referred to as "Access Information".  In addition to the response parameters defined by OAuth 2.0 and the PoP access token extension, this framework defines parameters that can be used to inform the client about capabilities of the RS, e.g.  the profile the RS supports.  More information about these parameters can be found in tokenParams. </ins> 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  <ins> content is confidentiality protected.  Confidentiality protection of the access token content would be provided on top of confidentiality protection via a communication security protocol. </ins> The keying material necessary for establishing communication security between C and RS is dynamically established as part of the protocol In constrained environments it cannot be assumed that the client  <ins> and the RS are part of a common key infrastructure.  Therefore, the AS provisions credentials and associated information to allow mutual authentication between the client and the RS.  The resulting security association between the client and the RS may then also be used to bind these credentials to the access tokens the client uses. </ins> The message can also contain the following OPTIONAL parameters:  <ins> A "audience" element contains an identifier the client should request at the AS, as suggested by the RS.  With this parameter, when included in the access token request to the AS, the AS is able to restrict the use of access token to specific RSs.  See audience for a discussion of this parameter. </ins> A "kid" element containing the key identifier of a key used in an existing security association between the client and the RS.  The In the example above, the response parameter "AS" points the receiver of this message to the URI "coaps://as.example.com/token" to request  <ins> access tokens.  The RS sending this response uses an internal clock that is not synchronized with the clock of the AS.  Therefore, it can not reliably verify the expiration time of access tokens it receives. To ensure a certain level of access token freshness nevertheless, the RS has included a "cnonce" parameter (see cnonceParam) in the response.  (The hex-sequence of the cnonce parameter is encoded in CBOR-based notation in this example.) </ins> fig:as-info-cbor illustrates the mandatory to use binary encoding of the message payload shown in fig:as-info-payload. If HTTPS is used, JSON or CBOR payloads may be supported.  If JSON payloads are used, the semantics of Sections 4.1.3 and 4.1.4 of the OAuth 2.0 specification MUST be followed (with additions as described  <ins> below).  If the CBOR payload formaat is supported, the semantics described in this section MUST be followed. </ins> For the AS to be able to issue a token, the client MUST be authenticated and present a valid grant for the scopes requested. client and how the communication between client and AS is protected, fulfilling the requirements specified in oauthProfile.  <ins> The default name of this endpoint in an url-path SHOULD be '/token'. However, implementations are not required to use this name and can define their own instead. </ins> The figures of this section use CBOR diagnostic notation without the integer abbreviations for the parameters or their values for