Code change:
compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC3986.  The value MUST be equal to that of the "iss" claim contained within <del> the referenced status list JWT. </del> <ins> the referenced Status List Token. </ins> <del> The JWT MUST contain an "sts" (status) claim conforming to the </del> <ins> The JWT MUST contain an "status" (status) claim conforming to the </ins> rules outlined in The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. <del> 3.1.1. </del> <ins> 4.1.1. </ins> <del> The following rules apply to validating the "sts" (status) claim </del> <ins> The following rules apply to validating the "status" (status) 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_lst" claim for the referenced status list. </del> The claim value object MUST contain an "idx" (index) attribute with a numberic based value that represents the index to check for <del> status information in the status list for the current JWT.  The </del> <ins> status information in the Status List for the current JWT.  The </ins> value of this attribute MUST be a non-negative number, containing a value of zero or greater.  Refer to xx for details on the validation procedure. The claim value object MUST contain a "uri" attribute with a <del> string based value that identifies the status list containing the </del> <ins> string based value that identifies the Status List containing the </ins> status information for the JWT.  The value of this attribute MUST be a uri conforming to <del> 3.2. </del> <ins> 4.2. </ins> <del> The following rules apply to validating a JWT based status list. Application of additional restrictions and policy are at the </del> <ins> The following rules apply to validating a JWT based Status List Token.  Application of additional restrictions and policy are at the </ins> discretion of the verifying party. The JWT MUST contain an "iss" (issuer) claim that contains a

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