Code change:
The spec creates a registry and claim for status mechanisms and 1 specific mechanism, the status list. We should adjust the introduction to reflect those changes.

Related discussion:
text: Abstract <del> This specification defines status list data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption(COSE), such as JSON Web Tokens (JWTs), CBOR Web Tokens (CWTs) and ISO mdoc.  Status Lists are provided in the form of JWTs or CWTs. </del> <ins> This specification defines a mechanism, data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT VC, CBOR Web Token and ISO mdoc.  It also defines an extension point and a registry for future status mechanisms. </ins> 1. <del> Token formats secured by JOSE IANA.JOSE or COSE RFC9052, such as JSON Web Tokens (JWTs) RFC7519, CBOR Web Tokens (CWTs) RFC8392 and ISO mdoc ISO.mdoc, have vast possible applications.  Some of these applications can involve issuing a token whereby certain semantics about the token can change over time, which are important to be able to communicate to relying parties in an interoperable manner, such as whether the token is considered invalidated or suspended by its issuer. This document defines a Status List and its representations in JWT and CWT formats that describe the individual statuses of multiple Referenced Tokens, which themselves are most commonly data structures secured by JOSE or COSE.  The statuses of all Referenced Tokens are conveyed via a bit array in the Status List.  Each Referenced Token is allocated an index during issuance that represents its position within this bit array.  The value of the bit(s) at this index correspond to the Referenced Token's status.  A Status List is provided within a Status List Token protected by cryptographic signature or MAC and this document defines its representations in JWT and CWT format.  Status Lists may be composed for expressing a range of Status Types.  This document defines basic Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types.  The document also defines how an issuer of a Referenced Token references a Status List Token. </del> <ins> Token formats secured by JOSE IANA.JOSE or COSE RFC9052, such as JWTs RFC7519, SD-JWT VCs SD-JWT.VC, CWTs RFC8392 and ISO mdoc ISO.mdoc, have vast possible applications.  Some of these applications can involve issuing a token whereby certain semantics about the token or its validity may change over time.  Communicating these changes to relying parties in an interoperable manner, such as whether the token is considered invalidated or suspended by its issuer, is important for many of these applications. This document defines a Status List data structure that describes the individual statuses of multiple Referenced Tokens.  A Referenced Token may be of any format, but is most commonly a data structures secured by JOSE or COSE.  The Referenced Token is referenced by the Status List, which described the status of the Referenced Token.  The statuses of all Referenced Tokens are conveyed via a bit array in the Status List.  Each Referenced Token is allocated an index during issuance that represents its position within this bit array.  The value of the bit(s) at this index correspond to the Referenced Token's status.  A Status List is provided within a Status List Token protected by cryptographic signature or MAC and this document defines its representations in JWT and CWT format. </ins> <del> An example for the usage of a Status List is to manage the status of issued access tokens as defined in section 1.4 of RFC6749.  Token Introspection RFC7662 defines another way to determine the status of an issued access token, but it requires the party trying to validate an access tokens status to directly contact the token issuer, whereas the mechanism defined in this specification does not have this limitation. Another possible use case for the Status List is to express the status of verifiable credentials (Referenced Tokens) issued by an Issuer in the Issuer-Holder-Verifier model SD-JWT.VC.  The following diagram depicts the relationship between the involved roles (Relying Party is equivalent to Verifier of SD-JWT.VC): </del> <ins> The following diagram depicts the relationship between the artifacts: </ins> An Issuer issues Referenced Tokens to a Holder, the Holder uses and presents those Referenced Tokens to a Relying Party.  The Issuer