jiebi/TextFlow huggingface dataset:
Original text:
"65534" (time to live): OPTIONAL.  Same definition as "ttl" claim in status-list-token-jwt. <del> "65535" (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 a claim key for used in the status list token in CWT format and fixes the reference.

Revised text:
"65534" (time to live): OPTIONAL.  Same definition as "ttl" claim in status-list-token-jwt.  <ins> "65533" (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_list"  Claim Description: A status list containing up-to-date status information on multiple other CWTs encoded as a bitarray.

Reviewer comments:
Adds a claim key for used in the status list token in CWT format and fixes the reference.

Revised text:
Claim Name: "status_list" <ins> Claim Key: TBD (requested assignment 65533) </ins> Claim Description: A status list containing up-to-date status information on multiple other CWTs encoded as a bitarray.
Original text:
The allowed values for "bits" are 1, 2, 4 and 8. "lst": REQUIRED.  Byte string (Major Type 2) that contains the <del> Status List as specified in status-list-json. </del>  "aggregation_uri": OPTIONAL.  Text string (Major Type 3) that contains a URI to retrieve the Status List Aggregation for this

Reviewer comments:
Status List claim was referencing Chapter 4.1 instead of Chapter 4, which made it ambiguous whether to base64url-encode or not

Revised text:
The allowed values for "bits" are 1, 2, 4 and 8. "lst": REQUIRED.  Byte string (Major Type 2) that contains the  <ins> Status List as specified in status-list. </ins> "aggregation_uri": OPTIONAL.  Text string (Major Type 3) that contains a URI to retrieve the Status List Aggregation for this
Original text:
"lst": REQUIRED.  JSON String that contains the status values for all the Referenced Tokens it conveys statuses for.  The <del> value MUST be the base64url-encoded (as defined in Section 2 of RFC7515) Status List as specified in status-list. </del>  "aggregation_uri": OPTIONAL.  JSON String that contains a URI to retrieve the Status List Aggregation for this type of

Reviewer comments:
Redered version: URL
the text is existing in JWT encoding, does it make sense to emphasize this change from standard base64url encoding again in our spec?
I like the solution in sd-jwt - they introduced it as terminology: Should we move that to terminology and reference via base64url in the text?

Revised text:
"lst": REQUIRED.  JSON String that contains the status values for all the Referenced Tokens it conveys statuses for.  The  <ins> value MUST be the base64url-encoded Status List as specified in status-list. </ins> "aggregation_uri": OPTIONAL.  JSON String that contains a URI to retrieve the Status List Aggregation for this type of
Original text:
These bits are concatenated: <del> Resulting in the byte array and compressed/base64url encoded status </del>  list: 11.

Reviewer comments:
Redered version: URL
the text is existing in JWT encoding, does it make sense to emphasize this change from standard base64url encoding again in our spec?
I like the solution in sd-jwt - they introduced it as terminology: Should we move that to terminology and reference via base64url in the text?

Revised text:
These bits are concatenated:  <ins> Resulting in the byte array and compressed/base64url-encoded status </ins> list: 11.
Original text:
server certificate check MUST be performed as defined in Section 5 and 6 of RFC6125.  The Relying Party SHOULD send the following Accept-Header to indicate the requested response type:

Reviewer comments:
Rendered version: URL
We should probably add a small section mentioning that should be set to when explaining the endpoint.

Revised text:
server certificate check MUST be performed as defined in Section 5 and 6 of RFC6125. <ins> The HTTP endpoint SHOULD support the use of Cross-Origin Resource Sharing (CORS) CORS and/or other methods as appropriate to enable Browser-Based clients to access it. </ins> The Relying Party SHOULD send the following Accept-Header to indicate the requested response type:
Original text:
3. <del> 3.1. </del>  <del> The following rules apply to validating a JWT which references a status list.  Application of additional restrictions and policy are at the discretion of the verifying party. </del>  The JWT MUST contain an "iss" (issuer) claim that contains a unique string based identifier for the entity that issued the JWT.

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:
3.  <ins> Status List A bit array that lists the statuses of many Referenced Tokens. Status List Token A token in JWT or CWT representation that contains a Status List. Referenced Token A token in JWT or CWT representation which contains a reference to a Status List Token.  The information from the contained Status List may give a verifier additional information about up-to-date status of the Referenced Token. 4. 4.1. </ins>  <ins> The following rules apply to validating a Referenced Token in JWT representation which references a Status List Token.  Application of additional restrictions and policy are at the discretion of the verifying party. </ins> The JWT MUST contain an "iss" (issuer) claim that contains a unique string based identifier for the entity that issued the JWT.
Original text:
The JWT MUST contain an "iat" (issued at) claim that identifies the time at which it was issued. <del> The JWT MUST contain an "sts_lst" (status list) claim conforming to the rules outlined in jwt-status-list-claim-format. </del>  The JWT MAY contain an "exp" (expiration time) claim that convey's when it is considered expired by its issuer.

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:
The JWT MUST contain an "iat" (issued at) claim that identifies the time at which it was issued.  <ins> The JWT MUST contain an "status_list" (status list) claim conforming to the rules outlined in jwt-status-list-claim-format. </ins> The JWT MAY contain an "exp" (expiration time) claim that convey's when it is considered expired by its issuer.
Original text:
suspension of a driving license or checking the employment status of an employee credential. <del> 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. </del>  12.4.

Reviewer comments:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Revised text:
suspension of a driving license or checking the employment status of an employee credential.  <ins> 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> 12.4.
Original text:
Claim Name: "status_list" Claim Description: A status list containing up-to-date status <del> information on multiple other JWTs encoded as a bitarray. </del>  Change Controller: IETF

Reviewer comments:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Revised text:
Claim Name: "status_list" Claim Description: A status list containing up-to-date status  <ins> information on multiple tokens. </ins> Change Controller: IETF
Original text:
Status Method Value: "status_list" Status Method Description: A status list containing up-to-date <del> status information on multiple other JWTs encoded as a bitarray. </del>  Change Controller: IETF

Reviewer comments:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Revised text:
Status Method Value: "status_list" Status Method Description: A status list containing up-to-date  <ins> status information on multiple tokens. </ins> Change Controller: IETF
Original text:
Claim Key: TBD (requested assignment 65533) Claim Description: A status list containing up-to-date status <del> information on multiple other CWTs encoded as a bitarray. </del>  Change Controller: IETF

Reviewer comments:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Revised text:
Claim Key: TBD (requested assignment 65533) Claim Description: A status list containing up-to-date status  <ins> information on multiple tokens. </ins> Change Controller: IETF
Original text:
Status Method Value: "status_list" Status Method Description: A status list containing up-to-date <del> status information on multiple other CWTs encoded as a bitarray. </del>  Change Controller: IETF

Reviewer comments:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Revised text:
Status Method Value: "status_list" Status Method Description: A status list containing up-to-date  <ins> status information on multiple tokens. </ins> Change Controller: IETF
Original text:
Optional parameters: n/a <del> Encoding considerations: binary; A JSON-based Status List is a JSON Object. </del>  <del> Security considerations: See (#Security) of [ this specification ] </del>  Interoperability considerations: n/a <del> Published specification: [ this specification ] </del>  <del> Applications that use this media type: Applications using [ this specification ] for updated status information of tokens </del>  Fragment identifier considerations: n/a <del> Additional information: File extension(s): n/a Macintosh file type code(s): n/a </del>  Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de

Reviewer comments:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Revised text:
Optional parameters: n/a  <ins> Encoding considerations: See status-list-json of this specification </ins>  <ins> Security considerations: See Security of this specification </ins> Interoperability considerations: n/a  <ins> Published specification: this specification </ins>  <ins> Applications that use this media type: Applications using this specification for updated status information of tokens </ins> Fragment identifier considerations: n/a  <ins> Additional information: n/a </ins> Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de
Original text:
Optional parameters: n/a <del> Encoding considerations: binary; A JWT-based Status List is a JWT; JWT values are encoded as a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') characters. </del>  <del> Security considerations: See (#Security) of [ this specification ] </del>  Interoperability considerations: n/a <del> Published specification: [ this specification ] </del>  <del> Applications that use this media type: Applications using [ this specification ] for updated status information of tokens </del>  Fragment identifier considerations: n/a <del> Additional information: File extension(s): n/a Macintosh file type code(s): n/a </del>  Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de

Reviewer comments:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Revised text:
Optional parameters: n/a  <ins> Encoding considerations: See status-list-token-jwt of this specification </ins>  <ins> Security considerations: See Security of this specification </ins> Interoperability considerations: n/a  <ins> Published specification: this specification </ins>  <ins> Applications that use this media type: Applications using this specification for updated status information of tokens </ins> Fragment identifier considerations: n/a  <ins> Additional information: n/a </ins> Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de
Original text:
Optional parameters: n/a <del> Encoding considerations: binary; A CBOR-based Status List is a CBOR Object. </del>  <del> Security considerations: See (#Security) of [ this specification ] </del>  Interoperability considerations: n/a <del> Published specification: [ this specification ] </del>  <del> Applications that use this media type: Applications using [ this specification ] for updated status information of tokens </del>  Fragment identifier considerations: n/a <del> Additional information: File extension(s): n/a Macintosh file type code(s): n/a </del>  Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de

Reviewer comments:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Revised text:
Optional parameters: n/a  <ins> Encoding considerations: See status-list-cbor of this specification </ins>  <ins> Security considerations: See Security of this specification </ins> Interoperability considerations: n/a  <ins> Published specification: this specification </ins>  <ins> Applications that use this media type: Applications using this specification for updated status information of tokens </ins> Fragment identifier considerations: n/a  <ins> Additional information: n/a </ins> Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de
Original text:
Optional parameters: n/a <del> Encoding considerations: binary; </del>  <del> Security considerations: See (#Security) of [ this specification ] </del>  Interoperability considerations: n/a <del> Published specification: [ this specification ] </del>  <del> Applications that use this media type: Applications using [ this specification ] for updated status information of tokens </del>  Fragment identifier considerations: n/a <del> Additional information: File extension(s): n/a Macintosh file type code(s): n/a </del>  Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de

Reviewer comments:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Revised text:
Optional parameters: n/a  <ins> Encoding considerations: See status-list-token-cwt of this specification </ins>  <ins> Security considerations: See Security of this specification </ins> Interoperability considerations: n/a  <ins> Published specification: this specification </ins>  <ins> Applications that use this media type: Applications using this specification for updated status information of tokens </ins> Fragment identifier considerations: n/a  <ins> Additional information: n/a </ins> Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de
Original text:
SD-JWT-based Verifiable Credentials SD-JWT.VC introduce the usage of Status List in Section 3.2.2.2.  The "status" object uses the same <del> encoding as a JWT as defined in referenced-token-jwt. </del>  The following is a non-normative example for a Referenced Token in SD-JWT-VC serialized form as received from an Issuer:

Reviewer comments:
Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho

Revised text:
SD-JWT-based Verifiable Credentials SD-JWT.VC introduce the usage of Status List in Section 3.2.2.2.  The "status" object uses the same  <ins> encoding as a JWT as defined in referenced-token-jose. </ins> The following is a non-normative example for a Referenced Token in SD-JWT-VC serialized form as received from an Issuer:
Original text:
6.3. <del> The Referenced Token MUST be encoded as a "COSE Web Token (CWT)" object according to RFC8392. </del>  The following content applies to the CWT Claims Set:

Reviewer comments:
Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho

Revised text:
6.3.  <ins> The Referenced Token MAY be encoded as a "COSE Web Token (CWT)" object according to RFC8392 or other formats based on COSE. </ins> The following content applies to the CWT Claims Set:
Original text:
"status_list" (status list): REQUIRED when the status list mechanism defined in this specification is used.  It has the same definition as the "status_list" claim in referenced-token- <del> jwt but MUST be encoded as a "StatusListInfo" CBOR structure </del>  with the following fields: "idx": REQUIRED.  Same definition as "idx" claim in <del> referenced-token-jwt. </del>  "uri": REQUIRED.  Same definition as "uri" claim in <del> referenced-token-jwt. </del>  Application of additional restrictions and policy are at the discretion of the verifying party.

Reviewer comments:
Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho

Revised text:
"status_list" (status list): REQUIRED when the status list mechanism defined in this specification is used.  It has the same definition as the "status_list" claim in referenced-token-  <ins> jose but MUST be encoded as a "StatusListInfo" CBOR structure </ins> with the following fields: "idx": REQUIRED.  Same definition as "idx" claim in  <ins> referenced-token-jose. </ins> "uri": REQUIRED.  Same definition as "uri" claim in  <ins> referenced-token-jose. </ins> Application of additional restrictions and policy are at the discretion of the verifying party.
Original text:
The following is the CBOR Annotated Hex output of the example above: <del> 6.4. The Referenced Token MUST be encoded as a "COSE_Sign1" or "COSE_Sign" CBOR structure as defined in "CBOR Object Signing and Encryption (COSE)" RFC9052. It is required to encode the status mechanisms referred to in the Referenced Token using the "Status" CBOR structure defined in referenced-token-cwt. </del>  It is RECOMMENDED to use "status" for the label of the field that contains the "Status" CBOR structure.

Reviewer comments:
Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho

Revised text:
The following is the CBOR Annotated Hex output of the example above:  <ins> ISO mdoc ISO.mdoc may utilize the Status List mechanism by introducing the "status" parameter in the Mobile Security Object (MSO) as specified in Section 9.1.2.  The "status" parameter uses the same encoding as a CWT as defined in referenced-token-cose. </ins> It is RECOMMENDED to use "status" for the label of the field that contains the "Status" CBOR structure.
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>  <del> TBD: example </del>  7.

Reviewer comments:
Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho

Revised text:
Application of additional restrictions and policy are at the discretion of the verifying party.  <ins> The following is a non-normative example for an IssuerAuth as specified in ISO mDL (also referred to as signed MSO) in Hex: </ins>  <ins> The following is the CBOR Diagnostic Notation of the example above: </ins> 7.