Code change:
Relying parties MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" RFC7519. <del> 3.2.1. </del> <ins> 4.2.1. </ins> <del> The following rules apply to validating the "sts_lst" (status list) claim </del> <ins> The following rules apply to validating the "status_list" (status list) claim </ins> The claim value MUST be a valid JSON object. <del> The claim value object MUST contain a "typ" (type) attribute with a string based value that represents the type of status list referenced.  The value MUST be equal to that of the "typ" attribute in the "sts" claim for the token who's status is being validated. </del> <ins> The claim value object MUST contain a "bit_size" attribute with an numeric based value that represents the number of bits per Referenced Token in the Status List ("lst") of the Status List JWT.  The allowed values for "bit_size" are 1,2,4 and 8. </ins> The claim value object MUST contain a "lst" (list) attribute with <del> a string based value that represents the status values for all the tokens it conveys statuses for.  The value MUST be a base64 encoded string using RFCXXX containing a GZIP compressed octet string RFC1952. </del> <ins> a string based value that represents the bit array containing the Status Type values for all the Referenced Tokens it conveys statuses for.  The value MUST be a base64 encoded string using RFCXXX containing a GZIP compressed octet string RFC1952. </ins> <del> 3.3. </del> <ins> 5. </ins> <del> This document formally defines the "revocation-list" status list type which applies the following additional validation rules beyond those described in jwt-format-and-processing and jwt-status-list-format- and-processing. </del> <ins> This document defines the possible statuses of Referenced Tokens as Status Type values.  If the Status List contains more than one bit per token (as defined by "bits" in the Status List) then the whole value of bits MUST describe one value.  A Status List can not encompass multiple statuses per individual bits for a Reference Token. </ins> <del> The "uri" attribute contained within a JWT using the "sts" claim MUST be an HTTPS based URL that when resolved via an HTTPS GET request returns a content type "application/jwt" containing the status list. </del> <ins> The registry in this document describes the basic Status Type values required for the most common use cases.  The registry may be extended as describes in XXX. </ins> <del> TODO add more </del> <ins> 5.1. </ins> <del> 4. </del> <ins> A status describes the state, mode, condition or stage of an entity that is described by the status list.  Status Types MUST be numeric based values between 0 and 255.  Status types described by this specifiction comprise: 0x00 - "VALID" - The status of the Token is valid, correct or legal.  0x01 - "INVALID" - The status of the Token is revoked, annuled, taken back, recalled or cancelled.  This state is irreversible.  0x02 - "SUSPENDED" - The status of the Token is temporarily unvalid, hanging, debared from privilege.  This state is reversible. </ins> <del> 4.1. </del> <ins> The issuer of the Status List Token MUST choose an adequate "bit_size" to be able to describe the required Status Types.ST be used for the "typ" attribute within the "status_list". 5.1.1. In the first example the Status List shall be used as a revocation list.  It only requires the Status Types "VALID" and "INVALID", therefore a "bit_size" of 1 is sufficient. In the second example the Status List shall additionally include the Status Type "SUSPENDED.  As the Status Type value for "SUSPENDED" is 0x02 and doe snot fit into 1 bit, the "bit_size" is required to be 2. 5.2. 6. 6.1. </ins> TODO elaborate on risks of incorrect parsing/decoding leading to erroneuos status data <del> 4.2. </del> <ins> 6.2. </ins> TODO consumers/Verifiers of the status list should be aware if they fetch the up-to-date data <del> 4.3. </del> <ins> 6.3. </ins> TODO elaborate on authorization mechanisms preventing misuse and profiling as described in privacy section <del> 4.4. </del> <ins> 6.4. </ins> TODO elaborate on status list only providing the up-to date/latest status, no historical data, may be provided by the underlying hosting architecture <del> 5. </del> <ins> 7. </ins> <del> 5.1. </del> <ins> 7.1. </ins> TODO elaborate on herd privacy, size of the status list <del> 5.2. </del> <ins> 7.2. </ins> TODO elaborate on Verifiers regularly fetching the status list to create a profile, possible countermeasures with authorized access to the status list <del> 5.3. </del> <ins> 7.3. </ins> TODO elaborate on Issuer-Verifier correlation and Verifier-Verifier correlation as the status list introduces unique,trackable data TODO elaborate on issuers avoiding sequential usage of indices and status <del> lists </del> <ins> lists TODO elaborate that a status list only gives information about the maximum number of possible statuses that a list conveys, issuers are recommended to pre-allocate lists, use dead entries that are never assigned or other obfuscation mechanisms </ins> <del> 5.4. </del> <ins> 7.4. </ins> <del> TODO elaborate on issuers generating unique status lists per JWT token that do not offer herd privacy </del> <ins> TODO elaborate on issuers generating unique status lists per Referenced Token that do not offer herd privacy </ins> <del> 5.5. </del> <ins> 7.5. </ins> TODO elaborate on increased privacy if the status list is hosted by a <del> third party instead of the issuer reducing tracking possiblities </del> <ins> third party instead of the issuer reducing tracking possiblities TODO evaluate deifnition of Status List Provider?  An entity that hosts the Status List as a resource for potential verifiers.  The Status List Provider may be the issuer of the Status List but may also be outsourced to a trusted third party. </ins> <del> 6. </del> <ins> 8. </ins> This document has no IANA actions.

Related discussion:
text: 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