Draft: draft-ietf-ace-oauth-authz

Commentary: Looks good . But I can not for my life figure out what you changed in the cwt - pop reference . Probably just your editor replacing a LF with CR LF .
Note that the term "endpoint" is used here following its OAuth
definition, which is to denote resources such as /token and
/introspect at the AS and /authz-info at the RS.  The CoAP RFC7252
definition, which is "An entity participating in the CoAP protocol"
is not used in this memo.
Note that the term "endpoint" is used here following its OAuth
definition, which is to denote resources such as token and introspect
at the AS and authz-info at the RS.  The CoAP RFC7252 definition,
which is "An entity participating in the CoAP protocol" is not used
in this memo.
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).
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.
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 AS and consumed by the RS.  The access
token content is opaque to the client.
The ACE framework is based on the OAuth 2.0 protocol interactions
using the /token and /introspect endpoints.  A client obtains an
access token from an AS using the /token endpoint and subsequently
presents the access token to a RS to gain access to a protected
resource.  The RS, after receiving an access token, may present it to
the AS via the /introspect endpoint to get information about the
access token.  In other deployments the RS may process the access
token locally without the need to contact an AS.  These interactions
are shown in fig:protocolFlow.  An overview of various OAuth concepts
is provided in oauth2Overview.
The ACE framework is based on the OAuth 2.0 protocol interactions
using the token and introspect endpoints.  A client obtains an access
token from an AS using the token endpoint and subsequently presents
the access token to a RS to gain access to a protected resource.  The
RS, after receiving an access token, may present it to the AS via the
introspect endpoint to get information about the access token.  In
other deployments the RS may process the access token locally without
the need to contact an AS.  These interactions are shown in
fig:protocolFlow.  An overview of various OAuth concepts is provided
in oauth2Overview.
The client makes an access token request to the /token endpoint at
the AS.  This framework assumes the use of PoP tokens (see
oauth2Overview for a short description) wherein the AS binds a key
to an access token.  The client may include permissions it seeks
to obtain, and information about the credentials it wants to use
(e.g., symmetric/asymmetric cryptography or a reference to a
specific credential).
The client makes an access token request to the token endpoint at
the AS.  This framework assumes the use of PoP tokens (see
oauth2Overview for a short description) wherein the AS binds a key
to an access token.  The client may include permissions it seeks
to obtain, and information about the credentials it wants to use
(e.g., symmetric/asymmetric cryptography or a reference to a
specific credential).
A resource server may be configured to introspect the access token
by including it in a request to the /introspect endpoint at that
AS.  Token introspection over CoAP is defined in
introspectionEndpoint and for HTTP in RFC7662.
A resource server may be configured to introspect the access token
by including it in a request to the introspection endpoint at that
AS.  Token introspection over CoAP is defined in
introspectionEndpoint and for HTTP in RFC7662.
Note: These conditions ensure that RS can handle requests
autonomously once access was granted and a secure channel has been
established between C and RS.  The /authz-info resource MUST NOT be
protected as specified above, in order to allow clients to upload
access tokens to RS (cf.  tokenAuthInfoEndpoint).
Unauthorized Resource Request messages MUST be denied with a client
error response.  In this response, the Resource Server SHOULD provide
proper AS Information to enable the Client to request an access token
from RS's Authorization Server as described in asInfo.
Note: These conditions ensure that RS can handle requests
autonomously once access was granted and a secure channel has been
established between C and RS.  The authz-info endpoint MUST NOT be
protected as specified above, in order to allow clients to upload
access tokens to RS (cf.  tokenAuthInfoEndpoint).
Unauthorized Resource Request messages MUST be denied with a client
error response.  In this response, the Resource Server SHOULD provide
proper AS Information to enable the Client to request an access token
from RS's AS as described in asInfo.
In plain OAuth 2.0 the AS provides the /token endpoint for submitting
access token requests.  This framework extends the functionality of
the /token endpoint, giving the AS the possibility to help client and
RS to establish shared keys or to exchange their public keys.
Furthermore this framework defines encodings using CoAP and CBOR, as
a substitute for HTTP and JSON.
In plain OAuth 2.0 the AS provides the token endpoint for submitting
access token requests.  This framework extends the functionality of
the token endpoint, giving the AS the possibility to help client and
RS to establish shared keys or to exchange their public keys.
Furthermore this framework defines encodings using CoAP and CBOR, as
a substitute for HTTP and JSON.
The method consists of an /authz-info endpoint, implemented by the
RS.  A client using this method MUST make a POST request to /authz-
info at the RS with the access token in the payload.  The RS
receiving the token MUST verify the validity of the token.  If the
token is valid, the RS MUST respond to the POST request with 2.01
(Created).  This response MAY contain the identifier of the token
(e.g. the cti for a CWT) as a payload.
The method consists of an authz-info endpoint, implemented by the RS.
A client using this method MUST make a POST request to the authz-info
endpoint at the RS with the access token in the payload.  The RS
receiving the token MUST verify the validity of the token.  If the
token is valid, the RS MUST respond to the POST request with 2.01
(Created).  This response MAY contain the identifier of the token
(e.g. the cti for a CWT) as a payload.
The RS MAY make an introspection request to validate the token before
responding to the POST /authz-info request.  If the introspection
response contains a client token (clientToken) then this token SHALL
be included in the payload of the 2.01 (Created) response.
Profiles MUST specify how the /authz-info endpoint is protected.
Note that since the token contains information that allow the client
and the RS to establish a security context in the first place, mutual
authentication may not be possible at this point.
The RS MAY make an introspection request to validate the token before
responding to the POST request to the authz-info endpoint.  If the
introspection response contains a client token (clientToken) then
this token SHALL be included in the payload of the 2.01 (Created)
response.
Profiles MUST specify how the authz-info endpoint is protected.  Note
that since the token contains information that allow the client and
the RS to establish a security context in the first place, mutual
authentication may not be possible at this point.