Draft: draft-ietf-ace-oauth-authz

Commentary: 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 .
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
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.
A third building block is CBOR RFC7049 for encodings where JSON
RFC7159 is not sufficiently compact.  CBOR is a binary encoding
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.
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
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.
A third building block is CBOR RFC7049 for encodings where JSON
RFC7159 is not sufficiently compact.  CBOR is a binary encoding
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.
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.
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.
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).
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.
The access token is protected against modifications using a MAC or
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.
In OAuth 2.0, the client specifies the type of permissions it is
seeking to obtain (via the scope parameter) in the access request.
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
could be a constrained device as well, this memo uses CBOR encoded
messages defined in oauthProfile to request scopes and to be
informed what scopes the access token was actually authorized for
by the AS.
The access token is protected against modifications using a MAC or
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.
In OAuth 2.0, the client specifies the type of permissions it is
seeking to obtain (via the scope parameter) in the access request.
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
could be a constrained device as well, this memo uses CBOR encoded
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.
The information carried in the access token in the form of type-
value pairs is called parameters.  [FIXME: This gives the
impression that "parameter" is only used to describe the
attributes in the access token and not in messages in general.]
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.
Information carried in the access token, called claims, is in the
form of type-value pairs.  [FIXME: This statement may give the
impression that "parameter" is only used to describe the
attributes in the access token and not in messages in general.]
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.
Introspection is a method for a resource server to query the
authorization server for the active state and content of a
received access token.  This is particularly useful in those cases
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
OAuth 2.0 can be found in I-D.ietf-oauth-introspection.
Introspection is a method for a resource server to query the
authorization server for the active state and content of a
received access token.  This is particularly useful in those cases
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
OAuth 2.0 can be found in RFC7662.
CoAP supports application-layer fragmentation of the CoAP payloads
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.
CoAP supports application-layer fragmentation of the CoAP payloads
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.
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
requires transport layer security to be terminated at the proxy.  One
approach for protecting CoAP communication end-to-end through
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
Message Syntax (COSE) I-D.ietf-cose-msg.
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
requires transport layer security to be terminated at the proxy.  One
approach for protecting CoAP communication end-to-end through
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
Message Syntax I-D.ietf-cose-msg.