Change:
Based on the review by Steffi I updated the text in Section 5.8.1.1 "Verifying an Access Token".

Discussion:
specified in RFC8392. In order to facilitate offline processing of access tokens, this <del> 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. </del> <ins> 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. </ins> The "scope" claim explicitly encodes the scope of a given access token.  This claim follows the same encoding rules as defined in

5.8.1.1. When an RS receives an access token, it MUST verify it before storing <del> 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 following claims MUST be checked if present, and errors returned when a check fails, in the order of priority of this list: </del> <ins> 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. Errors may happen during this initial processing stage: 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). Next, the RS MUST verify claims, if present, contained in the access token.  Errors are returned when claim checks fail, in the order of priority of this list: </ins> The issuer claim must identify an AS that has the authority to issue access tokens for the receiving RS.  If that is not the case the RS MUST respond with a response code equivalent to the CoAP code 4.01 (Unauthorized). <del> 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). </del> <ins> 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. </ins> The audience claim must refer to an audience that the RS identifies with.  If that is not the case the RS MUST respond with

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 <del> information in the error response, in order to clarify what went wrong. </del> <ins> information in the error response, to clarify what went wrong. </ins> If the access token contains any other claims that the RS cannot process the RS MUST respond with a response code equivalent to the

in the error response to clarify which claim couldn't be processed. Note that the Subject (sub) claim cannot always be verified when the <del> token is submitted to the RS, since the client may not have </del> <ins> token is submitted to the RS since the client may not have </ins> 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 <del> section 3.1 of RFC6750, in order to provide additional detail to the client. </del> <ins> Section 3.1 of RFC6750, to provide additional details to the client. </ins> 5.8.1.2.