Draft: draft-ietf-ace-oauth-authz

Commentary: This terminology decision was made in early days of OAuth = long time ago . Done . Done . Changed . I a note that this confidentiality protection of the access token happens on top of the protection offered by the underlying communication security protocol . Text . -- 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 . -- Section 5.5 -- In " Since it requires the use of a user agent ( i.e. , browser ) " is it " i.e. " or " e.g. " ? I can not 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 can not 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 : 
 Merged
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.
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.
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.
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.  Confidentiality protection of
the access token content would be provided on top of confidentiality
protection via a communication security protocol.
In constrained environments it cannot be assumed that the client
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.
In constrained environments it cannot be assumed that the client
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.
A "audience" element containing a suggested audience that the
client should request at the AS (see audience for a discussion of
this parameter).
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.
In the example above, the response parameter "AS" points the receiver
of this message to the URI "coaps://as.example.com/token" to request
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.
The endpoint may, however, be exposed over HTTPS as in classical
OAuth or even other transports.  A profile MUST define the details of
the mapping between the fields described below, and these transports.
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
below).  If CBOR payload is supported, the semantics described in
this section MUST be followed.
The endpoint may, however, be exposed over HTTPS as in classical
OAuth or even other transports.  A profile MUST define the details of
the mapping between the fields described below, and these transports.
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
below).  If the CBOR payload formaat is supported, the semantics
described in this section MUST be followed.
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.
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.