Change:
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

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