jiebi/CodeConvo huggingface dataset:
11.3. <del> When Relying Parties fetch the Status List, they need to be aware of its up-to-date status.  The 'ttl' (time-to-live) claim in the Status List Token provides one mechanism for setting a maximum cache time for the fetched data.  This property permits distribution of a Status List to a CDN or other distribution mechanism while giving guidance to consumers of the Status List on how often they need to fetch a fresh copy of the Status List even if that Status List is not expired. </del> <ins> When fetching a Status List Token, Relying Parties must carefully evaluate how long a Status List is cached for.  Collectively the "iat", "exp" and "ttl" claims when present in a Status List Token communicate how long a Status List should be cached and should be considered valid for.  The following diagram illustrates the relationship between these claims and how they are designed to influence caching. It is essential to understand the distinct purposes of the "ttl" and "exp" claims.  The "ttl" claim represents a duration to be interpreted relative to the time the Status List is fetched, indicating when a new version of the Status List may be available. In contrast, the "exp" claim specifies an absolute timestamp, marking the point in time when the Status List expires and MUST NOT be relied upon any longer.  Together, these claims provide guidance on when to check for updates ("ttl" claim) and when the Status List must be refreshed or replaced ("exp" claim). </ins> 12.
status mechanism method member and a reference to the specification that defines it. <ins> JWT Status Mechanism Methods are registered by Specification Required [RFC5226] after a three-week review period on the jwt-reg- review@ietf.org mailing list, on the advice of one or more Designated Experts.  However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register JWT Status Mechanism Method: example"). Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA.  Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list. </ins> 14.2.1. Status Method Value:
status mechanism method member and a reference to the specification that defines it. <ins> CWT Status Mechanism Methods are registered by Specification Required [RFC5226] after a three-week review period on the cwt-reg- review@ietf.org mailing list, on the advice of one or more Designated Experts.  However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register CWT Status Mechanism Method: example"). Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA.  Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list. </ins> 14.4.1. Status Method Value:
Status List values.  The registry records the a human readable label, the bit representation and a common description for it. <ins> Status Types are registered by Specification Required [RFC5226] after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts.  However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register Status Type name: example"). Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA.  Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list. </ins> 14.5.1. Status Type Name:
single byte for every operation and thus keeping implementations simpler and less error prone. <del> The overall status list is encoded as a byte array.  Depending on </del> <ins> The overall Status List is encoded as a byte array.  Depending on </ins> the "bit-size" each byte corresponds to 8/(#bit-size) statuses (8,4,2, or 1).  The status of each Referenced Token is identified <del> 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. </del> <ins> using the "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. </ins> The complete byte array is compressed using gZIP RFC1952.
base64 encoding without padding encoding as defined in Section 2 of RFC7515 and stored as a string. <del> Example of a two byte status list representing 16 statuses (1-bit status list) with indices 0 to 16 (2 bytes): </del> <ins> Example of a Status List representing the statuses of 16 Referenced Tokens (1-bit status type) with indices 0 to 15 (2 bytes): These bits are concatenated: After compression and Base64URL encoding the generated Status List is: </ins> Example of a more complex status list of length 12 using 2 bit statuses (3 bytes): <ins> These bits are concatenated: byte 0 1 2 bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ values |1|1|0|0|1|0|0|1| |0|1|0|0|0|1|0|0| |1|1|1|1|1|0|0|1| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / status 3 0 2 1 1 0 1 0 3 3 2 1 index 3 2 1 0 7 6 5 4 11 10 9 8 _ __/ 0xC9 0x44 0xF9 This results in the byte array: After compression and Base64URL encoding the generated Status List is: </ins> 5. This document defines the possible statuses of Referenced Tokens as
These bits are concatenated: <del> byte 0 1 2 bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ values |1|1|0|0|1|0|0|1| |0|1|0|0|0|1|0|0| |1|1|1|1|1|0|0|1| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / status 3 0 2 1 1 0 1 0 3 3 2 1 index 3 2 1 0 7 6 5 4 11 10 9 8 _ __/ 0xC9 0x44 0xF9 This results in the byte array: </del> <ins> Resulting in the byte array: </ins> After compression and Base64URL encoding the generated Status List is:
4.1. <del> 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. The JWT MUST contain an "iss" (issuer) claim that contains a unique string identifier for the entity that issued the JWT.  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. The JWT MUST contain an "status" (status) claim conforming to the rules outlined in The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. 4.1.1. The following rules apply to validating the "status" (status) claim The claim value MUST be a valid JSON object. The claim value object MUST contain an "idx" (index) member with a numeric value that represents the index to check for status information in the Status List for the current JWT.  The value of this member MUST be a non-negative number, containing a value of zero or greater. The claim value object MUST contain a "uri" member with a string value that identifies the Status List containing the status information for the JWT.  The value of this member MUST be a uri conforming to RFC3986. 4.2. </del> The following rules apply to validating a JWT-based Status List Token.  Application of additional restrictions and policy are at the discretion of the verifying party.
The result of the gZIP compression is then base64url-encoded, as defined in Section 2 of RFC7515. <ins> 4.2. 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. The JWT MUST contain an "iss" (issuer) claim that contains a unique string identifier for the entity that issued the JWT.  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. The JWT MUST contain an "status" (status) claim conforming to the rules outlined in The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. 4.2.1. The following rules apply to validating the "status" (status) claim The claim value MUST be a valid JSON object. The claim value object MUST contain an "idx" (index) member with a numeric value that represents the index to check for status information in the Status List for the current JWT.  The value of this member MUST be a non-negative number, containing a value of zero or greater. The claim value object MUST contain a "uri" member with a string value that identifies the Status List containing the status information for the JWT.  The value of this member MUST be a uri conforming to RFC3986. </ins> 5. This document defines potential statuses of Referenced Tokens as
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.
interchangeably by the same issuer.  For instance, declare whether a status list can reference both JWT and CWT tokens. <del> 8. </del> <ins> 9. </ins> <del> 8.1. </del> <ins> 9.1. </ins> TODO elaborate on risks of incorrect parsing/decoding leading to erroneous status data <del> 8.2. </del> <ins> 9.2. </ins> TODO consumers/Verifiers of the status list should be aware if they fetch the up-to-date data <del> 8.3. </del> <ins> 9.3. </ins> TODO elaborate on authorization mechanisms preventing misuse and profiling as described in privacy section <del> 8.4. </del> <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 <del> 9. </del> <ins> 10. </ins> <del> 9.1. </del> <ins> 10.1. </ins> TODO elaborate on herd privacy, size of the status list <del> 9.2. </del> <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 <del> 9.3. </del> <ins> 10.3. </ins> TODO elaborate on Issuer-Verifier correlation and Verifier-Verifier correlation as the status list introduces unique,trackable data TODO
are recommended to pre-allocate lists, use dead entries that are never assigned or other obfuscation mechanisms <del> 9.4. </del> <ins> 10.4. </ins> TODO elaborate on issuers generating unique status lists per Referenced Token that do not offer herd privacy <del> 9.5. </del> <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
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> <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> <del> The Verifier SHOULD send the following Accept-Header to indicate the requested response type: </del> <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 <del> If the Verifier does not send an Accept Header, the reponse type is assumed to be known implicit or out-of-band. </del> <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.
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> <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 <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> <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
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> <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.
12. <del> This document specifies no IANA actions. </del> <ins> 12.1. This specification requests registration of the following Claims in the IANA "JSON Web Token Claims" registry [@IANA.JWT] established by [@!RFC7519]. Claim Name: "status" Claim Description: Reference to a status list containing up-to- date status information on the JWT. Change Controller: IETF Specification Document(s): [[ (#jwt-referenced-token) of this specification ]] Claim Name: "status_list" Claim Description: A status list containing up-to-date status information on multiple other JWTs encoded as a bitarray. Change Controller: IETF Specification Document(s): [[ (#jwt-status-list-claim-format) of this specification ]] 12.2. This section requests registration of the following media types [@RFC2046] in the "Media Types" registry [@IANA.MediaTypes] in the manner described in [@RFC6838]. To indicate that the content is an JWT-based Status List: Type name: application * Subtype name: statuslist+jwt * Required parameters: n/a * Optional parameters: n/a * 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.  * Security considerations: See (#Security) of [[ this specification ]] * Interoperability considerations: n/a * Published specification: [[ this specification ]] * Applications that use this media type: Applications using [[ this specification ]] for updated status information of tokens * Fragment identifier considerations: n/a * Additional information: * File extension(s): n/a * Macintosh file type code(s): n/a * Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de * Intended usage: COMMON * Restrictions on usage: none * Author: Paul Bastian, paul.bastian@posteo.de * Change controller: IETF * Provisional registration?  No To indicate that the content is an CWT-based Status List: Type name: application * Subtype name: statuslist+cwt * Required parameters: n/a * Optional parameters: n/a * Encoding considerations: binary * Security considerations: See (#Security) of [[ this specification ]] * Interoperability considerations: n/a * Published specification: [[ this specification ]] * Applications that use this media type: Applications using [[ this specification ]] for updated status information of tokens * Fragment identifier considerations: n/ a * Additional information: * File extension(s): n/a * Macintosh file type code(s): n/a * Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de * Intended usage: COMMON * Restrictions on usage: none * Author: Paul Bastian, paul.bastian@posteo.de * Change controller: IETF * Provisional registration?  No </ins>
4. <del> TODO Security </del> <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. <del> TODO elaborate on heard privacy </del> <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.
("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> <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> <del> The result of the gZIP compression is then base64url-encoded, as </del> <ins> The result of the compression is then base64url-encoded, as </ins> defined in Section 2 of RFC7515. 4.2.
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> <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.
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> <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.
The SCITT version header MUST be included and its value match the "version" field of the Receipt stucture. <del> The DID of issuer header (like in Signed Claims) MUST be included and its value match the "ts_identifier" field of the Receipt structure. </del> <ins> The DID of issuer header (like in Signed Statements) MUST be included and its value match the "ts_identifier" field of the Receipt structure. </ins> TS MAY include the Registration policy info header to indicate to verifiers what policies have been applied at the registration of <del> this claim. </del> <ins> this Statement. </ins> Since I-D.draft-steele-cose-merkle-tree-proofs uses optional headers, the "crit" header (id: 2) MUST be included and all SCITT-