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.