jiebi/TextFlow huggingface dataset:
Original text:
("7").  All bits of the byte array at a particular index are set to a status value. <del> The complete byte array is compressed using the "DEFLATE" RFC1951 compression method and stored using the "ZLIB" RFC1950 data format.  Implementations are RECOMMENDED to use the highest compression level available. </del>  The following example illustrates a Status List that represents the statuses of 16 Referenced Tokens, requiring 16 bits (2 bytes) for the

Reviewer comments:
maybe adjust the language around DEFLATE and ZLIB per Originally posted by NAME in URL
Copied over, to have everything in the issue here: This is the current text: This is the proposal: >The complete byte array is compressed using DEFLATE {{RFC1951}} inside the ZLIB {{RFC1950}} data format. Implementations are RECOMMENDED to use the highest compression level available. I agree that the current text is a bit weird and I wasn't really sure how to formulate it better when writing it.
More context copied over via Screenshot: !

Revised text:
("7").  All bits of the byte array at a particular index are set to a status value.  <ins> The byte array is compressed using DEFLATE RFC1951 with the ZLIB RFC1950 data format.  Implementations are RECOMMENDED to use the highest compression level available. </ins> The following example illustrates a Status List that represents the statuses of 16 Referenced Tokens, requiring 16 bits (2 bytes) for the
Original text:
The following content applies to the JWT Claims Set: <del> "iss": REQUIRED.  The "iss" (issuer) claim MUST specify a unique string identifier for the entity that issued the Status List Token.  In the absence of an application profile specifying otherwise, 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 the Referenced Token. </del>  "sub": REQUIRED.  The "sub" (subject) claim MUST specify a unique string identifier for that Status List Token.  The value MUST be

Reviewer comments:
Fixes most of Relaxes requirements on referenced token in terminology issuer in status list token is only required when also present in referenced token (and matching checked) reorder references

Revised text:
The following content applies to the JWT Claims Set:  <ins> "iss": REQUIRED when also present in the Referenced Token.  The "iss" (issuer) claim MUST specify a unique string identifier for the entity that issued the Status List Token.  In the absence of an application profile specifying otherwise, 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 the Referenced Token. </ins> "sub": REQUIRED.  The "sub" (subject) claim MUST specify a unique string identifier for that Status List Token.  The value MUST be
Original text:
The following content applies to the JWT Claims Set: <del> "iss": REQUIRED.  The "iss" (issuer) claim MUST specify a unique string identifier for the entity that issued the Referenced Token. In the absence of an application profile specifying otherwise, 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 the referenced Status List Token. </del>  "status": REQUIRED.  The "status" (status) claim MUST specify a JSON Object that contains at least one reference to a status

Reviewer comments:
Fixes most of Relaxes requirements on referenced token in terminology issuer in status list token is only required when also present in referenced token (and matching checked) reorder references

Revised text:
The following content applies to the JWT Claims Set:  <ins> "iss": REQUIRED when also present in the Status List Token.  The "iss" (issuer) claim MUST specify a unique string identifier for the entity that issued the Referenced Token.  In the absence of an application profile specifying otherwise, 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 the referenced Status List Token. </ins> "status": REQUIRED.  The "status" (status) claim MUST specify a JSON Object that contains at least one reference to a status
Original text:
11.3. <del> Once the Relying Party gets the Referenced Token, this enables him to request the Status List to validate the status of the Token through the provided "uri" property and look up the corresponding "index". </del>  However, the Relying Party may persistently store the "uri" and "index" of the Referenced Token to request the Status List again at a later time.  By doing so regularly, the Relying Party may create a

Reviewer comments:
Closes # URL
batch issued credentials might be revealed in an status list update, which might correlate the related referenced tokens/credentials
improve privacy/prevent tracking by regular re-issuance of referenced tokens

Revised text:
11.3.  <ins> Once the Relying Party receives the Referenced Token, this enables him to request the Status List to validate its status through the provided "uri" parameter and look up the corresponding "index". </ins> However, the Relying Party may persistently store the "uri" and "index" of the Referenced Token to request the Status List again at a later time.  By doing so regularly, the Relying Party may create a
Original text:
regular validity checks, but might also be abused in cases where this is not intended and unknown to the Holder, e.g. profiling the suspension of a driving license or checking the employment status of <del> an employee credential.  This behaviour could be constrained by adding authorization rules to the Status List, see security- authorization. </del>  11.4. <del> Colluding Issuers and Relying Parties have the possibility to identify the usage of credentials of a particular Holder, as the Referenced Token contains unique, trackable data. </del>  To avoid privacy risks for colluding Relying Parties, it is <del> recommended that Issuers use batch issuance to issue multiple tokens, such that Holders can use individual tokens for specific Relying Parties.  In this case, every Referenced Token MUST have a dedicated Status List entry.  Revoking batch issued Referenced Tokens might reveal this correlation later on. </del>  <del> To avoid information leakage by the values of "uri" and "index", Issuers are RECOMMENDED to: </del>  choose non-sequential, pseudo-random or random indices

Reviewer comments:
Closes # URL
batch issued credentials might be revealed in an status list update, which might correlate the related referenced tokens/credentials
improve privacy/prevent tracking by regular re-issuance of referenced tokens

Revised text:
regular validity checks, but might also be abused in cases where this is not intended and unknown to the Holder, e.g. profiling the suspension of a driving license or checking the employment status of  <ins> an employee credential. This behaviour could be mitigated by: - adding authorization rules to the Status List, see security-authorization.  - regular re-issuance of the Referenced Token, see implementation-lifecycle. </ins> 11.4.  <ins> Colluding Issuers and a Relying Parties have the possibility to link two transactions, as the tuple of "uri" and "index" inside the Referenced Token are unique and therefore traceable data.  By comparing the status claims of received Referenced Tokens, two colluding Relying Parties could determine that they have interacted with the same user or an Issuer could trace the usage of its issued Referenced Token by colluding with various Relying Parties.  It is therefore recommended to use Status Lists for Referenced Token formats that have similar unlinkability properties. </ins> To avoid privacy risks for colluding Relying Parties, it is  <ins> RECOMMENDED that Issuers use batch issuance to issue multiple tokens, see implementation-lifecycle. </ins>  <ins> To avoid further correlatable information by the values of "uri" and "index", Issuers are RECOMMENDED to: </ins> choose non-sequential, pseudo-random or random indices
Original text:
12. <del> TBD Declare whether JWT and CWT representations can be used interchangeably by the same issuer.  For instance, declare whether a status list can reference both JWT and CWT tokens. </del>  13.

Reviewer comments:
Closes # URL
batch issued credentials might be revealed in an status list update, which might correlate the related referenced tokens/credentials
improve privacy/prevent tracking by regular re-issuance of referenced tokens

Revised text:
12.  <ins> 12.1. The lifetime of a Status List (and the Status List Token) depends on the lifetime of its Referenced Tokens.  Once all Referenced Tokens are expired, the Issuer may stop serving the Status List (and the Status List Token). Referenced Tokens may be regularly re-issued to increase security or to mitigate linkability and prevent tracking by Relying Parties.  In this case, every Referenced Token MUST have a fresh Status List entry. Referenced Tokens may also be issued in batches, such that Holders can use individual tokens for every transaction.  In this case, every Referenced Token MUST have a dedicated Status List entry.  Revoking batch issued Referenced Tokens might reveal this correlation later on. </ins> 13.
Original text:
"4" (expiration time): OPTIONAL.  Same definition as "exp" claim in status-list-token-jwt. <del> "65534" (status list): REQUIRED.  The status list claim MUST </del>  specify the Status List conforming to the rules outlined in status-list-cbor.

Reviewer comments:
adds ttl to the generated examples: Rendered verison: URL
Should be fine now, with some minor fixes to rendering and adding the proposed values. Can you please check again NAME
It appears the example uses a text string instead of a byte string for the idx value.
Good catch, the referenced token example is wrong!

Revised text:
"4" (expiration time): OPTIONAL.  Same definition as "exp" claim in status-list-token-jwt.  <ins> "65534" (time to live): OPTIONAL.  Same definition as "ttl" claim in status-list-token-jwt. "65535" (status list): REQUIRED.  The status list claim MUST </ins> specify the Status List conforming to the rules outlined in status-list-cbor.
Original text:
Claim Name: "status"  Claim Description: Reference to a status or validity mechanism containing up-to-date status information on the CWT.

Reviewer comments:
adds ttl to the generated examples: Rendered verison: URL
Should be fine now, with some minor fixes to rendering and adding the proposed values. Can you please check again NAME
It appears the example uses a text string instead of a byte string for the idx value.
Good catch, the referenced token example is wrong!

Revised text:
Claim Name: "status" <ins> Claim Key: TBD (requested assignment 65535) </ins> Claim Description: Reference to a status or validity mechanism containing up-to-date status information on the CWT.
Original text:
Specification Document(s): status-list-token-cwt of this specification  13.4. This specification establishes the IANA "Status Mechanism Methods"

Reviewer comments:
adds ttl to the generated examples: Rendered verison: URL
Should be fine now, with some minor fixes to rendering and adding the proposed values. Can you please check again NAME
It appears the example uses a text string instead of a byte string for the idx value.
Good catch, the referenced token example is wrong!

Revised text:
Specification Document(s): status-list-token-cwt of this specification <ins> Claim Name: "ttl" Claim Key: TBD (requested assignment 65534) Claim Description: Time to Live Change Controller: IETF Specification Document(s): status-list-token-cwt of this specification </ins> 13.4. This specification establishes the IANA "Status Mechanism Methods"
Original text:
"4" (expiration time): OPTIONAL.  Same definition as "exp" claim in status-list-token-jwt. <del> "65534" (status list): REQUIRED.  The status list claim MUST </del>  specify the Status List conforming to the rules outlined in status-list-cbor.

Reviewer comments:
Pretty straightforward fix for an oversight when relaxing the requirements for status list
The spec says: However, JWT defines as "REQUIRED if present in the reference token which means, the REQUIRED word is a bit misleading without the if-statement that follows. Either use OPTIONAL for , or also say in the CWT section.

Revised text:
"4" (expiration time): OPTIONAL.  Same definition as "exp" claim in status-list-token-jwt.  <ins> "65534" (time to live): OPTIONAL.  Same definition as "ttl" claim in status-list-token-jwt. "65535" (status list): REQUIRED.  The status list claim MUST </ins> specify the Status List conforming to the rules outlined in status-list-cbor.
Original text:
The following content applies to the CWT Claims Set: <del> "1" (issuer): REQUIRED.  Same definition as "iss" claim in referenced-token-jwt. </del>  "65535" (status): REQUIRED.  The status claim is encoded as a "Status" CBOR structure and MUST include at least one data item

Reviewer comments:
Pretty straightforward fix for an oversight when relaxing the requirements for status list
The spec says: However, JWT defines as "REQUIRED if present in the reference token which means, the REQUIRED word is a bit misleading without the if-statement that follows. Either use OPTIONAL for , or also say in the CWT section.

Revised text:
The following content applies to the CWT Claims Set:  <ins> "1" (issuer): REQUIRED when also present in the Referenced Token. Same definition as "iss" claim in referenced-token-jwt. </ins> "65535" (status): REQUIRED.  The status claim is encoded as a "Status" CBOR structure and MUST include at least one data item
Original text:
Claim Name: "status"  Claim Description: Reference to a status or validity mechanism containing up-to-date status information on the CWT.

Reviewer comments:
Pretty straightforward fix for an oversight when relaxing the requirements for status list
The spec says: However, JWT defines as "REQUIRED if present in the reference token which means, the REQUIRED word is a bit misleading without the if-statement that follows. Either use OPTIONAL for , or also say in the CWT section.

Revised text:
Claim Name: "status" <ins> Claim Key: TBD (requested assignment 65535) </ins> Claim Description: Reference to a status or validity mechanism containing up-to-date status information on the CWT.
Original text:
Specification Document(s): status-list-token-cwt of this specification  13.4. This specification establishes the IANA "Status Mechanism Methods"

Reviewer comments:
Pretty straightforward fix for an oversight when relaxing the requirements for status list
The spec says: However, JWT defines as "REQUIRED if present in the reference token which means, the REQUIRED word is a bit misleading without the if-statement that follows. Either use OPTIONAL for , or also say in the CWT section.

Revised text:
Specification Document(s): status-list-token-cwt of this specification <ins> Claim Name: "ttl" Claim Key: TBD (requested assignment 65534) Claim Description: Time to Live Change Controller: IETF Specification Document(s): status-list-token-cwt of this specification </ins> 13.4. This specification establishes the IANA "Status Mechanism Methods"
Original text:
MUST be equal to that of the "iss" claim contained within the Referenced Token. <del> "sub": REQUIRED.  The "sub" (subject) claim MUST specify a unique string identifier for the Status List Token.  The value MUST be equal to that of the "uri" claim contained in the "status_list" claim of the Referenced Token. </del>  "iat": REQUIRED.  The "iat" (issued at) claim MUST specify the time at which the Status List Token was issued.

Reviewer comments:
The first and second sentence of this description seem contradictory to me. The first sentence seems to state that (all?) Status List Tokens should have a unique identifier included as their claim. The second sentence directly contradicts this uniqueness requirement. Perhaps I'm misunderstanding what is meant by 'uniqueness' in the first sentence, but in that case the language is quite ambiguous. As the claim seems to have been added solely for including the from the Referenced Token in the Status List Token (as described in ), perhaps the sentences should simply be reworded to not mention uniqueness. So something like: : REQUIRED. The (subject) claim MUST be equal to the claim contained in the claim of the Referenced Token.
The is basically the URI by which the Status List Token is retrieved. As Status List Tokens may be downloaded for offline use, further re-transmission or archiving, its important to also store the URI in the Token, such that it can be compared by others to the of the claim of the Referenced Token. I see that the text may be confusing, it should be clearer as "URI" may be better than "unique string identifier" and URI is unique anyway. How about: : REQUIRED. The (subject) claim MUST specify the URI of the Status List Token. The value MUST be equal to that of the claim contained in the claim of the Referenced Token.
Yes thank you, this wording clears it up. If you wanted to be very precise instead of you could write . But perhaps my suggestion is too verbose, what you've written gets the idea across.

Revised text:
MUST be equal to that of the "iss" claim contained within the Referenced Token.  <ins> "sub": REQUIRED.  The "sub" (subject) claim MUST specify the URI of the Status List Token.  The value MUST be equal to that of the "uri" claim contained in the "status_list" claim of the Referenced Token. </ins> "iat": REQUIRED.  The "iat" (issued at) claim MUST specify the time at which the Status List Token was issued.
Original text:
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 <del> Status List may either be provided by an endpoint or be signed and </del>  embedded into a Status List Token, whereas this document defines its representations in JWT and CWT.  Status Lists may be composed for expressing a range of Status Types.  This document defines basic

Reviewer comments:
Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex

Revised text:
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  <ins> Status List may either be provided via HTTPS or be signed and </ins> embedded into a Status List Token, whereas this document defines its representations in JWT and CWT.  Status Lists may be composed for expressing a range of Status Types.  This document defines basic
Original text:
Status List as specified in status-list-json. The following example illustrates the CBOR representation of the <del> Status List: </del>  <del> The following is the CBOR diagnostic output of the example above: </del>  5.

Reviewer comments:
Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex

Revised text:
Status List as specified in status-list-json. The following example illustrates the CBOR representation of the  <ins> Status List in Hex: </ins>  <ins> The following is the CBOR Annotated Hex output of the example above: </ins> 5.
Original text:
discretion of the verifying party. The following is a non-normative example for a Status List Token in <del> CWT format (not including the type header yet): </del>  <del> The following is the CBOR diagnostic output of the example above: </del>  6.

Reviewer comments:
Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex

Revised text:
discretion of the verifying party. The following is a non-normative example for a Status List Token in  <ins> CWT format in Hex: </ins>  <ins> The following is the CBOR Annotated Hex output of the example above: </ins> 6.
Original text:
Application of additional restrictions and policy are at the discretion of the verifying party. <del> The following is a non-normative example for a decoded payload of a Referenced Token: </del>  6.4.

Reviewer comments:
Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex

Revised text:
Application of additional restrictions and policy are at the discretion of the verifying party.  <ins> The following is a non-normative example of a Referenced Token in CWT format in Hex: The following is the CBOR Annotated Hex output of the example above: </ins> 6.4.
Original text:
8.1. To obtain the Status List or Status List Token, the Relying Party <del> MUST send a HTTP GET request to the Status List Endpoint. Communication with the Status List Endpoint MUST utilize TLS.  Which version(s) should be implemented will vary over time.  A TLS server certificate check MUST be performed as defined in Section 5 and 6 of RFC6125. </del>  The Relying Party SHOULD send the following Accept-Header to indicate the requested response type:

Reviewer comments:
Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex

Revised text:
8.1. To obtain the Status List or Status List Token, the Relying Party  <ins> MUST send an HTTP GET request to the URI provided in the Referenced Token. If the Status List is provided by an HTTP endpoint (and not as a Status List Token), the provider of the Status List MUST utilize TLS. Which version(s) should be implemented will vary over time.  A TLS server certificate check MUST be performed as defined in Section 5 and 6 of RFC6125. </ins> The Relying Party SHOULD send the following Accept-Header to indicate the requested response type:
Original text:
8.3. <del> If caching is required (e.g., to enable the use of alternative mechanisms for hosting, like Content Delivery Networks), the control of the caching mechanism SHOULD be implemented using the standard HTTP Cache-Control as defined in RFC9111. 8.4. </del> TBD 9.

Reviewer comments:
Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex

Revised text:
8.3.  TBD 9.
Original text:
The following content applies to the CWT protected header: <del> "16" TBD (type): REQUIRED.  The type of the CWT MUST be "statuslist+cwt" as defined in CWT.typ. </del>  The following content applies to the CWT Claims Set:

Reviewer comments:
Rendered Version: URL
COSE typ is now registered in IANA. Because of that, the TBD could be removed.

Revised text:
The following content applies to the CWT protected header:  <ins> "16" (type): REQUIRED.  The type of the CWT MUST be "statuslist+cwt" as defined in RFC9596. </ins> The following content applies to the CWT Claims Set: