jiebi/TextFlow huggingface dataset:
Original text:
Check for the existence of a "status" claim, check for the existence of a "status_list" claim within the "status" claim and validate that the content of "status_list" adheres to the rules <del> defined in referenced-token-jwt for JWTs and referenced-token-cwt for CWTs.  This step can be overruled if defined within the </del>  Referenced Token Format natively Resolve the Status List from the provided URI

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:
Check for the existence of a "status" claim, check for the existence of a "status_list" claim within the "status" claim and validate that the content of "status_list" adheres to the rules  <ins> defined in referenced-token-jose for JWTs and referenced-token- cose for CWTs.  This step can be overruled if defined within the </ins> Referenced Token Format natively Resolve the Status List from the provided URI
Original text:
Change Controller: IETF <del> Specification Document(s): referenced-token-jwt of this </del>  specification 14.3.

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:
Change Controller: IETF  <ins> Specification Document(s): referenced-token-jose of this </ins> specification 14.3.
Original text:
Change Controller: IETF <del> Specification Document(s): referenced-token-cwt of this </del>  specification 14.5.

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:
Change Controller: IETF  <ins> Specification Document(s): referenced-token-cose of this </ins> specification 14.5.
Original text:
The claim value object MUST contain a "lst" (list) attribute with a string based value that represents the status values for all the <del> tokens it conveys statuses for.  The value MUST be a base64 encoded string using RFCXXX containing a GZIP compressed octet string RFC1952. </del>  3.3.

Reviewer comments:
Questions for the encoding: base64 vs url-safe base64 bitwise encoding right now is least significant bit to most significant bit The part describing the bit-encoding still needs be rewritten In general: I searched a bit for better ways to encode/compress but in terms of simplicity and support for different programming languages, it seems some form of byte array and gZIP seem to be a pretty decent pick.
I've made a first implementation in Kotlin today. To me, it feels very natural to count Byte indexes up from 0 to size(whether this is left to right or right to left feels a little philosophical) and Bit indexes from right to left.
Imho we need another iteration on the description of the bit encoding, most likely with some form of ASCII art. I would prefer to do that in another PR- what do you think?

Revised text:
The claim value object MUST contain a "lst" (list) attribute with a string based value that represents the status values for all the  <ins> tokens it conveys statuses for.  The value MUST be computed using the algorithm described in jwt-status-list-claim-encoding. 3.2.2. Each status of a Referenced Token MUST be represented with a bit size of 1,2,4, or 8.  Therefore up to 2,4,16, or 256 statuses for a Referenced Token, depending on the bit-size, are possible.  This limitation is intended to limit bit manipulation necessary to a single byte for every operation and thus keeping implementations simpler and less error prone. The overall status list is encoded as a byte array.  Depending on the "bit-size" each byte corresponds to 8/(#bit-size) statuses (8,4,2, or 1).  The status of each Referenced Token is identified using an index that maps to one or more specific bits within the byte array.  The index starts counting at 0 and ends with "size" - 1(being the last valid entry).  The bits within an array are counted from least significant bit "0" to the most significant bit ("7").  All bits of the byte array at a particular index are set to a status value. The complete byte array is compressed using gZIP RFC1952. The result of the gZIP compression is then encoded as base64 encoding as defined in Section 4 of RFC4648 and stored as a string. Example of a byte representing 8 statuses (1-bit status list) with indices 0,1,2,3,4,5,6,7 (1 byte): Example of a more complex status list of length 12 using 2 bit statuses (3 bytes): </ins> 3.3.
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 via HTTPS or be signed and 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 Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types.  The document also defines how an issuer of a Referenced Token references a Status List (Token). </del>  An example for the usage of a Status List is to manage the status of issued access tokens as defined in section 1.4 of RFC6749.  Token

Reviewer comments:
As the similar requirement was relaxed on SD-JWT, I think we should consider the same.

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 protected within a Status List Token by cryptographic signature or MAC, 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 Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types.  The document also defines how an issuer of a Referenced Token references a Status List (Token). </ins> An example for the usage of a Status List is to manage the status of issued access tokens as defined in section 1.4 of RFC6749.  Token
Original text:
The JWT MAY contain other claims. <del> The JWT MUST be digitally signed using an asymmetric cryptographic algorithm.  Relying parties MUST reject the JWT if it is using a Message Authentication Code (MAC) algorithm.  Relying parties MUST reject JWTs with an invalid signature. </del>  Relying parties MUST reject JWTs that are not valid in all other respects per "JSON Web Token (JWT)" RFC7519. Application of additional restrictions and policy are at the <del> discretion of the verifying party. </del>  The following is a non-normative example for a Status List Token in JWT format:

Reviewer comments:
As the similar requirement was relaxed on SD-JWT, I think we should consider the same.

Revised text:
The JWT MAY contain other claims.  <ins> The JWT MUST be secured using a cryptographic signature or MAC algorithm.  Relying Parties MUST reject JWTs with an invalid signature. </ins> Relying parties MUST reject JWTs that are not valid in all other respects per "JSON Web Token (JWT)" RFC7519. Application of additional restrictions and policy are at the  <ins> discretion of the Relying Party. </ins> The following is a non-normative example for a Status List Token in JWT format:
Original text:
The CWT MAY contain other claims. <del> The CWT MUST be digitally signed using an asymmetric cryptographic algorithm.  Relying parties MUST reject the CWT if it is using a Message Authentication Code (MAC) algorithm.  Relying parties MUST reject CWTs with an invalid signature. </del>  Relying parties MUST reject CWTs that are not valid in all other respects per "CBOR Web Token (CWT)" RFC8392. Application of additional restrictions and policy are at the <del> discretion of the verifying party. </del>  The following is a non-normative example for a Status List Token in CWT format in Hex:

Reviewer comments:
As the similar requirement was relaxed on SD-JWT, I think we should consider the same.

Revised text:
The CWT MAY contain other claims.  <ins> The CWT MUST be secured using a cryptographic signature or MAC algorithm.  Relying Parties MUST reject CWTs with an invalid signature. </ins> Relying parties MUST reject CWTs that are not valid in all other respects per "CBOR Web Token (CWT)" RFC8392. Application of additional restrictions and policy are at the  <ins> discretion of the Relying Party. </ins> The following is a non-normative example for a Status List Token in CWT format in Hex:
Original text:
Upon receiving a Referenced Token, a Relying Party MUST first perform the validation of the Referenced Token - e.g., checking for expected <del> attributes, valid signature, expiration time.  As this is out of scope of this document, this validation is not be described here, but is expected to be done according to the format of the Referenced Token. </del>  If this validation was not successful, the Referenced Token MUST be rejected.  If the validation was successful, the Relying Party MUST

Reviewer comments:
The first few entries are valid, revoked, suspended. There may be future well defined values that issuers and verifiers want global interoperability around. There may also be a need for private use of this space. This document should describe the "reserved for private use range", and leave room for enough globally interoperable and registered status values
We had similar ideas and totally agree
The section 7 explains how to setup the registry (URL) but we are missing a corresponding section in the IANA appendix

Revised text:
Upon receiving a Referenced Token, a Relying Party MUST first perform the validation of the Referenced Token - e.g., checking for expected  <ins> attributes, valid signature, expiration time.  The processing rules for JWT or CWT precede any evaluation of a Referenced Token's status. For example, if a token is evaluated as being expired through the "exp" (Expiration Time) but also has a status of 0x00 ("VALID"), the token is considered expired.  As this is out of scope of this document, this validation is not be described here, but is expected to be done according to the format of the Referenced Token. </ins> If this validation was not successful, the Referenced Token MUST be rejected.  If the validation was successful, the Relying Party MUST
Original text:
14.5.  This section requests registration of the following media types RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838.

Reviewer comments:
The first few entries are valid, revoked, suspended. There may be future well defined values that issuers and verifiers want global interoperability around. There may also be a need for private use of this space. This document should describe the "reserved for private use range", and leave room for enough globally interoperable and registered status values
We had similar ideas and totally agree
The section 7 explains how to setup the registry (URL) but we are missing a corresponding section in the IANA appendix

Revised text:
14.5. <ins> This specification establishes the IANA "Status Types" registry for Status List values.  The registry records the a human readable label, the bit representation and a common description for it. 14.5.1. Status Type Name: Status Type Description: Status Type value: Change Controller: Specification Document(s): 14.5.2. Status Type Name: VALID Status Type Description: The status of the Referenced Token is valid, correct or legal. Status Type value: "0x00" Change Controller: IETF Specification Document(s): status-types of this specification Status Type Name: INVALID Status Type Description: The status of the Referenced Token is revoked, annulled, taken back, recalled or cancelled. Status Type value: "0x01" Change Controller: IETF Specification Document(s): status-types of this specification Status Type Name: SUSPENDED Status Type Description: The status of the Referenced Token is temporarily invalid, hanging, debarred from privilege.  This state is reversible. Status Type value: "0x02" Change Controller: IETF Specification Document(s): status-types of this specification Status Type Name: APPLICATION_SPECIFIC_3 Status Type Description: The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band. Status Type value: "0x03" Change Controller: IETF Specification Document(s): status-types of this specification Status Type Name: APPLICATION_SPECIFIC_14 Status Type Description: The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band. Status Type value: "0x0E" Change Controller: IETF Specification Document(s): status-types of this specification Status Type Name: APPLICATION_SPECIFIC_15 Status Type Description: The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band. Status Type value: "0x0F" Change Controller: IETF Specification Document(s): referenced-token-jose of this specification 14.6. </ins> This section requests registration of the following media types RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838.
Original text:
resolvable endpoint.  The roles of the Issuer (of the Referenced Token), the Status Issuer and the Status Provider may be fulfilled by the same entity.  If not further specified, the term Issuer may refer <del> to an entity acting for all three roles. </del>  <del> The following diagram depicts the relationship between the artifacts: </del>  <del> The Referenced Token is referenced by the Status List, which described the status of the Referenced Token.  The Status List is embedded and secured within a Status List Token. </del>  1.1.  Revocation mechanisms are an essential part for most identity ecosystems.  In the past, revocation of X.509 TLS certificates has been proven difficult.  Traditional certificate revocation lists

Reviewer comments:
The spec creates a registry and claim for status mechanisms and 1 specific mechanism, the status list. We should adjust the introduction to reflect those changes.

Revised text:
resolvable endpoint.  The roles of the Issuer (of the Referenced Token), the Status Issuer and the Status Provider may be fulfilled by the same entity.  If not further specified, the term Issuer may refer  <ins> to an entity acting for all three roles.  This document describes how an Issuer references a Status List Token and how a Relying Party fetches and validates Status Lists. </ins>  <ins> The following diagram depicts the relationship between the involved roles (Relying Party is equivalent to Verifier of SD-JWT.VC): Status Lists may be composed for expressing a range of Status Types. This document defines basic Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types. </ins>  <ins> Furthermore, the document defines an extension point that enables other specifications to describe additional status mechanisms and creates an IANA registry. </ins> 1.1. <ins> An example for the usage of a Status List is to manage the status of issued access tokens as defined in section 1.4 of RFC6749.  Token Introspection RFC7662 defines another way to determine the status of an issued access token, but it requires the party trying to validate an access tokens status to directly contact the token issuer, whereas the mechanism defined in this specification does not have this limitation. Another possible use case for the Status List is to express the status of verifiable credentials (Referenced Tokens) issued by an Issuer in the Issuer-Holder-Verifier model SD-JWT.VC. 1.2. </ins> Revocation mechanisms are an essential part for most identity ecosystems.  In the past, revocation of X.509 TLS certificates has been proven difficult.  Traditional certificate revocation lists
Original text:
this specification.  Other specifications can register other members used for status retrieval. <del> 1.2. </del>  The decisions taken in this specification aim to achieve the following design goals:

Reviewer comments:
The spec creates a registry and claim for status mechanisms and 1 specific mechanism, the status list. We should adjust the introduction to reflect those changes.

Revised text:
this specification.  Other specifications can register other members used for status retrieval.  <ins> 1.3. </ins> The decisions taken in this specification aim to achieve the following design goals:
Original text:
"aggregation_uri": OPTIONAL.  JSON String that contains a URI to retrieve the Status List Aggregation for this type of <del> Referenced Token.  See section batch-fetching for further detail. </del>  The following example illustrates the JSON representation of the Status List:

Reviewer comments:
yes, looks great.
If an OP wanted to publish the Token Status List JWT on an endpoint, perhaps something like with ... it would be nice to specify that in the spec.
I'm not sure what you are suggesting. Are you suggesting that AS or RS has a link to a status list token in his metadata or are you suggesting media types? The latter is already defined in the draft.
Is this covered by ?
Editors Call: add that may link then to the Aggreation
NAME does the PR reflect your idea?
LGTM apart from the minor text change

Revised text:
"aggregation_uri": OPTIONAL.  JSON String that contains a URI to retrieve the Status List Aggregation for this type of  <ins> Referenced Token.  See section aggregation for further detail. </ins> The following example illustrates the JSON representation of the Status List:
Original text:
"aggregation_uri": OPTIONAL.  Text string (Major Type 3) that contains a URI to retrieve the Status List Aggregation for this <del> type of Referenced Token.  See section batch-fetching for further detail. </del>  The following example illustrates the CBOR representation of the Status List in Hex:

Reviewer comments:
yes, looks great.
If an OP wanted to publish the Token Status List JWT on an endpoint, perhaps something like with ... it would be nice to specify that in the spec.
I'm not sure what you are suggesting. Are you suggesting that AS or RS has a link to a status list token in his metadata or are you suggesting media types? The latter is already defined in the draft.
Is this covered by ?
Editors Call: add that may link then to the Aggreation
NAME does the PR reflect your idea?
LGTM apart from the minor text change

Revised text:
"aggregation_uri": OPTIONAL.  Text string (Major Type 3) that contains a URI to retrieve the Status List Aggregation for this  <ins> type of Referenced Token.  See section aggregation for further detail. </ins> The following example illustrates the CBOR representation of the Status List in Hex:
Original text:
The Issuer MAY link to the Status List Aggregation URI in metadata that can be provided by different means like .well-known metadata as is used commonly in OAuth and OpenID, or via a VICAL extension for <del> ISO mDoc / mDL. </del>  The concrete specification on how this is implemented depends on the specific ecosystem and is out of scope of this specification.

Reviewer comments:
yes, looks great.
If an OP wanted to publish the Token Status List JWT on an endpoint, perhaps something like with ... it would be nice to specify that in the spec.
I'm not sure what you are suggesting. Are you suggesting that AS or RS has a link to a status list token in his metadata or are you suggesting media types? The latter is already defined in the draft.
Is this covered by ?
Editors Call: add that may link then to the Aggreation
NAME does the PR reflect your idea?
LGTM apart from the minor text change

Revised text:
The Issuer MAY link to the Status List Aggregation URI in metadata that can be provided by different means like .well-known metadata as is used commonly in OAuth and OpenID, or via a VICAL extension for  <ins> ISO mDoc / mDL.  If the Issuer is an OAuth Authorization Server according to RFC6749, it is RECOMMENDED to use "status_list_aggregation_endpoint" for its metadata defined by RFC8414. </ins> The concrete specification on how this is implemented depends on the specific ecosystem and is out of scope of this specification.
Original text:
14.6.  This section requests registration of the following media types RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838.

Reviewer comments:
yes, looks great.
If an OP wanted to publish the Token Status List JWT on an endpoint, perhaps something like with ... it would be nice to specify that in the spec.
I'm not sure what you are suggesting. Are you suggesting that AS or RS has a link to a status list token in his metadata or are you suggesting media types? The latter is already defined in the draft.
Is this covered by ?
Editors Call: add that may link then to the Aggreation
NAME does the PR reflect your idea?
LGTM apart from the minor text change

Revised text:
14.6. <ins> This specification requests registration of the following value in the IANA "OAuth Authorization Server Metadata" registry IANA.OAuth.Params established by RFC8414. Metadata Name: status_list_aggregation_endpoint Metadata Description: URL of the Authorization Server aggregating OAuth Token Status List URLs for token status management. Change Controller: IETF Reference: aggregation of this specification 14.7. </ins> This section requests registration of the following media types RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838.
Original text:
"aggregation_uri": OPTIONAL.  JSON String that contains a URI to retrieve the Status List Aggregation for this type of <del> Referenced Token.  See section batch-fetching for further detail. </del>  The following example illustrates the JSON representation of the Status List:

Reviewer comments:
Rendered version: URL
We do not define how to respond to a status list request but have status codes on examples We might also need to add language for redirects?
Ok to merge with the minor suggestion.

Revised text:
"aggregation_uri": OPTIONAL.  JSON String that contains a URI to retrieve the Status List Aggregation for this type of  <ins> Referenced Token.  See section aggregation for further detail. </ins> The following example illustrates the JSON representation of the Status List:
Original text:
"aggregation_uri": OPTIONAL.  Text string (Major Type 3) that contains a URI to retrieve the Status List Aggregation for this <del> type of Referenced Token.  See section batch-fetching for further detail. </del>  The following example illustrates the CBOR representation of the Status List in Hex:

Reviewer comments:
Rendered version: URL
We do not define how to respond to a status list request but have status codes on examples We might also need to add language for redirects?
Ok to merge with the minor suggestion.

Revised text:
"aggregation_uri": OPTIONAL.  Text string (Major Type 3) that contains a URI to retrieve the Status List Aggregation for this  <ins> type of Referenced Token.  See section aggregation for further detail. </ins> The following example illustrates the CBOR representation of the Status List in Hex: