jiebi/TextFlow huggingface dataset:
Original text:
7.  TBD Define parallel CWT representations for Status Lists and Referenced Tokens.

Reviewer comments:
Defines the HTTP GET API URL
We need to document end to end the validation procedure for a JWT and CWT referencing a status list including resolution of the status list, validation of the status list and how to get the status information for the JWT referencing the status list.

Revised text:
7. <ins> 7.1. To obtain the Status List or Status List Token, the Verifier 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. The Verifier SHOULD send the following Accept-Header to indicate the requested response type: "application/statuslist+jwt" for Status List JWTs "application/statuslist+cwt" for Status List CWTs If the Verifier does not send an Accept Header, the reponse type is assumed to be known implicit or out-of-band. 7.2. In the successful response, the Status List Provider MUST use the following content-type: "application/statuslist+jwt" for Status List JWTs "application/statuslist+cwt" for Status List CWTs In the case of "application/statuslist+jwt", the response MUST be of type JWT and follow the rules of jwt-status-list-format-and- processing.  In the case of "application/statuslist+cwt", the response MUST be of type JWT and follow the rules of cwt-status-list- format. The response SHOULD use gzip Content-Encoding as defined in RFC9110. 7.3. 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. 7.4. 8. </ins> TBD Define parallel CWT representations for Status Lists and Referenced Tokens.
Original text:
interchangeably by the same issuer.  For instance, declare whether a status list can reference both JWT and CWT tokens. <del> 8. </del>  <del> 8.1. </del>  TODO elaborate on risks of incorrect parsing/decoding leading to erroneous status data <del> 8.2. </del>  TODO consumers/Verifiers of the status list should be aware if they fetch the up-to-date data <del> 8.3. </del>  TODO elaborate on authorization mechanisms preventing misuse and profiling as described in privacy section <del> 8.4. </del>  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> 9. </del>  <del> 9.1. </del>  TODO elaborate on herd privacy, size of the status list <del> 9.2. </del>  TODO elaborate on Verifiers regularly fetching the status list to create a profile, possible countermeasures with authorized access to the status list <del> 9.3. </del>  TODO elaborate on Issuer-Verifier correlation and Verifier-Verifier correlation as the status list introduces unique,trackable data TODO

Reviewer comments:
Defines the HTTP GET API URL
We need to document end to end the validation procedure for a JWT and CWT referencing a status list including resolution of the status list, validation of the status list and how to get the status information for the JWT referencing the status list.

Revised text:
interchangeably by the same issuer.  For instance, declare whether a status list can reference both JWT and CWT tokens.  <ins> 9. </ins>  <ins> 9.1. </ins> TODO elaborate on risks of incorrect parsing/decoding leading to erroneous status data  <ins> 9.2. </ins> TODO consumers/Verifiers of the status list should be aware if they fetch the up-to-date data  <ins> 9.3. </ins> TODO elaborate on authorization mechanisms preventing misuse and profiling as described in privacy section  <ins> 9.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  <ins> 10. </ins>  <ins> 10.1. </ins> TODO elaborate on herd privacy, size of the status list  <ins> 10.2. </ins> TODO elaborate on Verifiers regularly fetching the status list to create a profile, possible countermeasures with authorized access to the status list  <ins> 10.3. </ins> TODO elaborate on Issuer-Verifier correlation and Verifier-Verifier correlation as the status list introduces unique,trackable data TODO
Original text:
are recommended to pre-allocate lists, use dead entries that are never assigned or other obfuscation mechanisms <del> 9.4. </del>  TODO elaborate on issuers generating unique status lists per Referenced Token that do not offer herd privacy <del> 9.5. </del>  TODO elaborate on increased privacy if the status list is hosted by a third party instead of the issuer reducing tracking possiblities TODO

Reviewer comments:
Defines the HTTP GET API URL
We need to document end to end the validation procedure for a JWT and CWT referencing a status list including resolution of the status list, validation of the status list and how to get the status information for the JWT referencing the status list.

Revised text:
are recommended to pre-allocate lists, use dead entries that are never assigned or other obfuscation mechanisms  <ins> 10.4. </ins> TODO elaborate on issuers generating unique status lists per Referenced Token that do not offer herd privacy  <ins> 10.5. </ins> TODO elaborate on increased privacy if the status list is hosted by a third party instead of the issuer reducing tracking possiblities TODO
Original text:
List Provider may be the issuer of the Status List but may also be outsourced to a trusted third party. <del> 10. </del>  This document specifies no IANA actions.

Reviewer comments:
Defines the HTTP GET API URL
We need to document end to end the validation procedure for a JWT and CWT referencing a status list including resolution of the status list, validation of the status list and how to get the status information for the JWT referencing the status list.

Revised text:
List Provider may be the issuer of the Status List but may also be outsourced to a trusted third party.  <ins> 11. </ins> This document specifies no IANA actions.
Original text:
7.1. <del> To obtain the Status List or Status List Token, the Verifier 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>  <del> The Verifier SHOULD send the following Accept-Header to indicate the requested response type: </del>  "application/statuslist+jwt" for Status List JWTs "application/statuslist+cwt" for Status List CWTs <del> If the Verifier does not send an Accept Header, the reponse type is assumed to be known implicit or out-of-band. </del>  7.2.

Reviewer comments:
Use term Relying Party and Issuer URL
Sometimes we use Verifier, sometimes we use Relying Party. After deciding this, we should add them to the Terminology
As this is moving to OAuth Security working Group, we should adopt Relying Party as terminology

Revised text:
7.1.  <ins> To obtain the Status List or Status List Token, the Relying Party 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. </ins>  <ins> The Relying Party SHOULD send the following Accept-Header to indicate the requested response type: </ins> "application/statuslist+jwt" for Status List JWTs "application/statuslist+cwt" for Status List CWTs  <ins> If the Relying Party does not send an Accept Header, the reponse type is assumed to be known implicit or out-of-band. </ins> 7.2.
Original text:
9.2. <del> TODO consumers/Verifiers of the status list should be aware if they fetch the up-to-date data </del>  9.3.

Reviewer comments:
Use term Relying Party and Issuer URL
Sometimes we use Verifier, sometimes we use Relying Party. After deciding this, we should add them to the Terminology
As this is moving to OAuth Security working Group, we should adopt Relying Party as terminology

Revised text:
9.2.  <ins> TODO consumers/Relying Party of the status list should be aware if they fetch the up-to-date data </ins> 9.3.
Original text:
from tracking the usage of the Referenced Token when the status is being checked.  If an Issuer offers status information by referencing a specific token, this would enable him to create a profile for the <del> issued token by correlating the date and identity of Verifiers, that are requesting the status. </del>  The Status List approaches these privacy implications by integrating the status information of many Referenced Tokens into the same list. Therefore, the Issuer does not learn for which Referenced Token the <del> Verifier is requesting the Status List.  The privacy of the Holder is protected by the anonymity within the set of Referenced Tokens in the Status List, also called herd privacy.  This limits the possibilities of tracking by the Issuer. </del>  The herd privacy is depending on the number of entities within the Status List called its size.  A larger size results in better privacy

Reviewer comments:
Use term Relying Party and Issuer URL
Sometimes we use Verifier, sometimes we use Relying Party. After deciding this, we should add them to the Terminology
As this is moving to OAuth Security working Group, we should adopt Relying Party as terminology

Revised text:
from tracking the usage of the Referenced Token when the status is being checked.  If an Issuer offers status information by referencing a specific token, this would enable him to create a profile for the  <ins> issued token by correlating the date and identity of Relying Parties, that are requesting the status. </ins> The Status List approaches these privacy implications by integrating the status information of many Referenced Tokens into the same list. Therefore, the Issuer does not learn for which Referenced Token the  <ins> Relying Party is requesting the Status List.  The privacy of the Holder is protected by the anonymity within the set of Referenced Tokens in the Status List, also called herd privacy.  This limits the possibilities of tracking by the Issuer. </ins> The herd privacy is depending on the number of entities within the Status List called its size.  A larger size results in better privacy
Original text:
TODO elaborate on increased privacy if the status list is hosted by a third party instead of the issuer reducing tracking possiblities TODO evaluate deifnition of Status List Provider?  An entity that hosts <del> 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. </del>  11.

Reviewer comments:
Use term Relying Party and Issuer URL
Sometimes we use Verifier, sometimes we use Relying Party. After deciding this, we should add them to the Terminology
As this is moving to OAuth Security working Group, we should adopt Relying Party as terminology

Revised text:
TODO elaborate on increased privacy if the status list is hosted by a third party instead of the issuer reducing tracking possiblities TODO evaluate deifnition of Status List Provider?  An entity that hosts  <ins> the Status List as a resource for potential Relying Parties.  The Status List Provider may be the issuer of the Status List but may also be outsourced to a trusted third party. </ins> 11.
Original text:
the Referenced Token. The JWT MUST contain a "sub" (subject) claim that contains an <del> unique string identifier for that Referenced Token.  The value </del>  MUST be equal to that of the "uri" claim contained in the "status" claim of the Referenced Token.

Reviewer comments:
Change typo in Status List Token sub claim description URL
The in the "Status List JWT Format and Processing Requirements" section has 'The JWT MUST contain a "sub" (subject) claim that contains an unique string identifier for that Referenced Token.' but I believe it should be "... unique string identifier for that Status List Token."
that's correct, thanks for pointing this out Brian

Revised text:
the Referenced Token. The JWT MUST contain a "sub" (subject) claim that contains an  <ins> unique string identifier for that Status List Token.  The value </ins> MUST be equal to that of the "uri" claim contained in the "status" claim of the Referenced Token.
Original text:
4. <del> TODO Security </del>  5. <del> TODO elaborate on heard privacy </del>  6.

Reviewer comments:
gathering some ideas on privacy and security considerations
Looking good NAME you should be able to run 'make fix-lint' locally to fix the whitespace issues
Need to remove the trailing whitespaces for the markdown tooling to be happy

Revised text:
4.  <ins> 4.1. TODO elaborate on risks of incorrect parsing/decoding leading to erroneuos status data 4.2. TODO consumers/Verifiers of the status list should be aware if they fetch the up-to-date data 4.3. TODO elaborate on authorization mechanisms preventing misuse and profiling as described in privacy section 4.4. TODO elaborate on status list only providing the up-to date/latest status, no historical data, may be provided by the underlying hosting architecture </ins> 5.  <ins> 5.1. TODO elaborate on herd privacy, size of the status list 5.2. TODO elaborate on Verifiers regularly fetching the status list to create a profile, possible countermeasures with authorized access to the status list 5.3. 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 lists 5.4. TODO elaborate on issuers generating unique status lists per JWT token that do not offer herd privacy 5.5. TODO elaborate on increased privacy if the status list is hosted by a third party instead of the issuer reducing tracking possiblities </ins> 6.
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 gZIP RFC1952. </del>  <del> The result of the gZIP compression is then base64url-encoded, as </del>  defined in Section 2 of RFC7515. 4.2.

Reviewer comments:
and . Switches to zlib instead of gzip encoding and adds the recommendation to use the best available compression.
I'm working on a TypeScript implementation of this spec, and have the encoding / decoding of the status list implemented. It seems to work based on the example in the spec and the example python scripts, with one slight difference. When I encode either the 1 or 2 bit example it will output one character difference , while mine outputs an . The decoding seems to work fine, and maybe this is a gzip thing, but I'm wondering if the examples use certain gzip features to get this output? I've adapted my implementation to use compression level 9 (default for python lib) and set the mtime to the same value The input byte array is the same as for the python implementation and the examples in the spec, so it's really something that is happening during the gzip encoding (the output byte array here is different) any idea what is going on here? The implementation and tests can be found here: URL
Seems to be a difference in the header - from the position I would assume the timestamp (even though you seem be setting it to the fixed value used in the examples in the draft)? There is also a header entry for the operating system - that would also be a very likely candidate for the difference. I will take a look at it when I am back from IIW. We were discussing switching from gzip to zlib (or deflate directly) for that reason - we don't really need these headers and most languages seem to support both gzip and zlib (which was our concern when we initially thought about this). Related Issue:
Thanks for testing! There is a header as well in zlib, but it's considerably smaller. The zlib header does not include a timestamp which makes it better for reproducible results and test vectors. I think we should also give a recommendation for the used compression level, I suspect either default or highest. It would be interesting if the underscore vanishes in zlib?
I changed the python implementation to use zlib with level 9 and did the same for your typescript implementation --> both resulted in the same: We should really change that imho (and also add the text to recommend compression level).
I'm a proponent of using zlib instead of gzip. As suggested in the other issue, we don't really need the other metadata. And the result is smaller as well :)

Revised text:
("7").  All bits of the byte array at a particular index are set to a status value.  <ins> 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. </ins>  <ins> The result of the compression is then base64url-encoded, as </ins> defined in Section 2 of RFC7515. 4.2.
Original text:
(bit size) to be able to describe the required Status Types for the application.  6. 6.1.

Reviewer comments:
This feedback comes from applying the Status List to an implementation of a general OAuth 2.x server issuing JWT Access Tokens. Such implementation will typically not keep record of any issued JWT Access Tokens (their claims, expiry, etc) until they need to be revoked due any reason, e.g. getting leaked or just being explicitly revoked by the client. In such cases the issuer considers the token as VALID when issuing the Status List but this state will not necessarily reflect the token's validity as per the JWT validation rules for claims like nbf or exp. This is important to point out so that the status list is not mistaken for an alternative to actually validating the referenced token's claim set.
NAME could you merge with main and add a line to the document history please
Not a member, cannot merge.
I meant sync, sry. But I can add the history on main also.
NAME Please review and merge if you approve
Looks good to me. It might be better positioned in a dedicated Verification Processing section once we have that but its good for now

Revised text:
(bit size) to be able to describe the required Status Types for the application. <ins> The processing rules for JWT or CWT precede any evaluation of a referenced tokens 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. </ins> 6. 6.1.
Original text:
references a Status List Token.  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 <del> extensibility mechanism for custom Status Types.  The Status List Token may be used by an issuer in the Issuer-Holder-Verifier model to express the status of verifiable credentials (Referenced Tokens) issued by an issuer. The following diagram depicts the basic conceptual relationship. </del>  1.1.

Reviewer comments:
Adds access token as an example use-case for status list.
Aaron says that there are zero mentions of the term access token and proposes to mention JWT accesstokens as a possible usecase

Revised text:
references a Status List Token.  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  <ins> extensibility mechanism for custom Status Types. 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.  The following diagram depicts the basic conceptual relationship. </ins> 1.1.
Original text:
ts_identifier: The DID of the Transparency Service that issued the Receipt.  Verifiers MAY use this DID as a key discovery mechanism to verify the Receipt; in this case the verification is the same <del> as for Signed Claims and the signer MAY include the "kid" header </del>  parameter.  Verifiers MUST support the "did:web" method, all other methods are optional.

Reviewer comments:
and
Payload and Statement seem to be used intermixed in the text. I tried to disambiguate the via "Statement payload". If that does not work, please provide a counter proposal. The term Claim sometimes seem to have meant Signed Statement and sometimes Transparent Statement. Using our interim terminology, that became a selection process for me. Please check, if I made the correct choice in all occurrences (sometimes I had to guess the intent). Consistent Capitalization was a mess. I hope I fixed most of that. Please check. There is still no consistent use of "Registry" vs. "log" vs. "ledger" vs. "Transparency Service", I think. Please check. Please check every use of the term "Evidence" and if an alternative expression could be used. Please check every occurrence of the term "guarantee" or "proof" and if an alternative expression could be used. Privacy Considerations and Security Considerations texts require significant improvement.
Here is my opinion: Registry refers to the facilities used to store and retrieve "Authenticated Statement Data" that has been submitted to a "Transparency Service" "operator". A Registry contains specific "Statements" which the Transparency service supports, as documented in their registration policies document. A Registry may employ different technologies needed to carry out its function to store and retrieve "Statements" that are permitted in the Registry, per the registration policies defined by the Transparency Service operator. The operator of a Transparency Service serves the role of Gatekeeper to ensure the integrity of the Registry data and services provided to access the Registry data. A Statement is contained in a message "Payload" exchanged between a Transparency Service API function and other parties, i.e. consumer inquiries and Notary submissions.
It would help to be able to read the document given the changes proposed here. But due to the make errors documented in I haven't yet succeeded in doing so. Does the build infrastructure automatically build documents for other branches? Or can someone else build and publish the document based on this branch?
Editor's version build via github actions for is located here: https://ietf-wg-URL
LGTM, thanks for finishing this off

Revised text:
ts_identifier: The DID of the Transparency Service that issued the Receipt.  Verifiers MAY use this DID as a key discovery mechanism to verify the Receipt; in this case the verification is the same  <ins> as for Signed Statment and the signer MAY include the "kid" header </ins> parameter.  Verifiers MUST support the "did:web" method, all other methods are optional.