Original text:
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 <del> whether the token is considered revoked by its issuer. This document defines a status list using JWT and CWT for representation that is capable of communicating the individual statuses of multiple tokens.  The document also defines how an issuer of a token references a status list in a JWT or CWT which has a status to convey. </del>  The following diagram depicts the basic conceptual relationship.  2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Reviewer comments:
Micha proposed to change REVOKED to INVALID, as it gives less intention whether this is a permanent state and the issuers could reflect a suspension also with a 1bit size status list as well
I'm in agreement with Kristina, the more I look at this the more I think we should have one possible enumeration of statuses rather than allowing every issuer to define their own, the question then becomes how big that set needs to be as it controls how many bits are allocated to each credential in the status list.
I'm fine with defining the first bit as valid/invalid. I think providing the option for additional bits offers benefits with acceptable tradeoffs
I've made some changes, please recheck NAME NAME
umm I thought we agreed to remove the concept of the "typ" attribute.. so no and no .
Yeah that was captured here NAME URL
But I assume the Status List Token will have a JOSE header to properly distinguish it from other JWTs, right?
I approve, but moved to separate issue
NAME typo on my end. yes, JWT should be typed ( claim present), the current spec also introduces a body claim as far as I can see, which is what I am not in agreement with.
NAME I am confused. so the idea is to merge this PR and then remove the "type" JWT claim in PR ?
comment edited, I got confused here as well. There is an issue open already as a task and I would like to not blow up the PRs too much
NAME ready for merge
I am a little confused with calling "VALID", "INVALID" Status List , but agreed this should be mergedOne minor typo

Revised text:
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  <ins> whether the token is considered invalidated or suspended by its issuer. This document defines a Status List in JWT and CWT representations that describes the individual statuses of multiple Referenced Tokens. 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 which represents a position within this bit array and the value of the bit(s) at this position correspond to the Referenced Token's status.  The document also defines how an issuer of a Referenced Token in JWT or CWT representation references a Status List Token.  Status Lists may be composed for expressing a range of Status Types, the document defines basic Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types.  The Status List Token may be used by an issuer in the Issuer-Holder-Verifier model, as described in (XXX) to express the status of verifiable credentials (Referenced Tokens) issued by an issuer. </ins> The following diagram depicts the basic conceptual relationship. <ins> 1.1. Revocation mechanisms are an essential part for most identity ecoosystems.  In the past, revocation of X.509 TLS certificates has been proven difficult as traditional certificate revocation lists (CRLs) have limited scalability and the Online Certificate Status Protocol (OCSP) has additional privacy risks as the client is leaking the requested website to a third party.  OSCP stapling is adressing some of these problems at the cost of less up-to-date data.  Modern approaches use accumulator-based revocation registries and Zero- Knowledge-Proofs to accomodate for this privacy gap but face scalability issues again. The approach of this specification seeks to find a balance between scalability, security and privacy by minimizing the status information to mere bits and compressing the resulting binary data. Thereby a Status List may contain statuses of 100.000 or more Referenced Tokens, but still remain relatively small.  Placing large amounts of Referenced Tokens into the same list also enables a herd privacy towards the Issuer. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",