Draft: draft-ietf-ace-oauth-authz

Commentary: Based on the review by Steffi I updated the text in Section 5.8.1.1 " Verifying an Access Token " .
In order to facilitate offline processing of access tokens, this
draft uses the "cnf" claim from I-D.ietf-ace-cwt-proof-of-possession
and specifies the "scope" claim for both JSON and CBOR web tokens.
In order to facilitate offline processing of access tokens, this
document uses the "cnf" claim from I-D.ietf-ace-cwt-proof-of-
possession and specifies the "scope" claim for JWT- and CWT-encoded
tokens.
When an RS receives an access token, it MUST verify it before storing
it.  The verification is based on the claims of the token and its
cryptographic wrapper (if any), so the RS needs to retrieve those
claims.  If the claims cannot be retrieved the RS MUST discard the
token and in case of an interaction via the authz-info endpoint,
return an error message with a response code equivalent to the CoAP
code 4.00 (Bad Request).
The cryptographic wrapper of the token (e.g. a COSE message) MUST be
verified by the RS, based on shared cryptographic material with an AS
that has the authority to issue tokens for the RS.  Since this
wrapper could include encryption, it needs to be verified before the
claims can be processed.  If this verification fails, the RS MUST
discard the token and if this was an interaction with authz-info it
MUST respond with a response code equivalent to the CoAP code 4.01
(Unauthorized).
The expiration date must be in the future.  Note that this has to
be verified again at access time.  If that is not the case the RS
MUST respond with a response code equivalent to the CoAP code 4.01
(Unauthorized).
When an RS receives an access token, it MUST verify it before storing
it.  The details of token verification depends on various aspects,
including the token encoding, the type of token, the security
protection applied to the token, and the claims.  The token encoding
matters since the security wrapper differs between the token
encodings.  For example, a CWT token uses COSE while a JWT token uses
JOSE.  The type of token also has an influence on the verification
procedure since tokens may be self-contained whereby token
verification may happen locally at the RS while a token-by-reference
requires further interaction with the authorization, for example
using token introspection, to obtain the claims associated with the
token reference.  Self-contained token MUST, at a minimum, be
integrity protected but they MAY also be encrypted.
For self-contained tokens the RS MUST process the security protection
of the token first, as specified by the respective token format.  For
CWT the description can be found in RFC8392 and for JWT the relevant
specification is RFC7519.
In case the token is communicated by reference the RS needs to obtain
the claims first.  When the RS uses token introspection the relevant
specification is RFC7662 with CoAP transport specified in
introspectionEndpoint.
If token or claim verification fails, the RS MUST discard the
token and, if this was an interaction with authz-info, return an
error message with a response code equivalent to the CoAP code
4.01 (Unauthorized).
If the claims cannot be obtained the RS MUST discard the token
and, in case of an interaction via the authz-info endpoint, return
an error message with a response code equivalent to the CoAP code
4.00 (Bad Request).
The expiration date must be in the future.  If that is not the
case the RS MUST respond with a response code equivalent to the
CoAP code 4.01 (Unauthorized).  Note that the RS has to terminate
access rights to the protected resources at the time when the
tokens expire.
The RS must recognize value of the scope claim.  If that is not
the case the RS MUST respond with a response code equivalent to
the CoAP code 4.00 (Bad Request).  The RS MAY provide additional
information in the error response, in order to clarify what went
wrong.
The RS must recognize value of the scope claim.  If that is not
the case the RS MUST respond with a response code equivalent to
the CoAP code 4.00 (Bad Request).  The RS MAY provide additional
information in the error response, to clarify what went wrong.
Note that the Subject (sub) claim cannot always be verified when the
token is submitted to the RS, since the client may not have
authenticated yet.  Also note that a counter for the expires_in (exi)
claim MUST be initialized when the RS first verifies this token.
When sending error responses, the RS MAY use the error codes from
section 3.1 of RFC6750, in order to provide additional detail to the
client.
Note that the Subject (sub) claim cannot always be verified when the
token is submitted to the RS since the client may not have
authenticated yet.  Also note that a counter for the expires_in (exi)
claim MUST be initialized when the RS first verifies this token.
When sending error responses, the RS MAY use the error codes from
Section 3.1 of RFC6750, to provide additional details to the client.