jiebi/CodeConvo huggingface dataset:
The following content applies to the JWT Claims Set: <del> "iss": REQUIRED.  The "iss" (issuer) claim MUST specify a unique string identifier for the entity that issued the Referenced Token. In the absence of an application profile specifying otherwise, compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC3986.  The value MUST be equal to that of the "iss" claim contained within the referenced Status List Token. </del> <ins> "iss": REQUIRED when also present in the Status List Token.  The "iss" (issuer) claim MUST specify a unique string identifier for the entity that issued the Referenced Token.  In the absence of an application profile specifying otherwise, compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC3986.  The value MUST be equal to that of the "iss" claim contained within the referenced Status List Token. </ins> "status": REQUIRED.  The "status" (status) claim MUST specify a JSON Object that contains at least one reference to a status
11.3. <del> Once the Relying Party gets the Referenced Token, this enables him to request the Status List to validate the status of the Token through the provided "uri" property and look up the corresponding "index". </del> <ins> Once the Relying Party receives the Referenced Token, this enables him to request the Status List to validate its status through the provided "uri" parameter and look up the corresponding "index". </ins> However, the Relying Party may persistently store the "uri" and "index" of the Referenced Token to request the Status List again at a later time.  By doing so regularly, the Relying Party may create a
regular validity checks, but might also be abused in cases where this is not intended and unknown to the Holder, e.g. profiling the suspension of a driving license or checking the employment status of <del> an employee credential.  This behaviour could be constrained by adding authorization rules to the Status List, see security- authorization. </del> <ins> an employee credential. This behaviour could be mitigated by: - adding authorization rules to the Status List, see security-authorization.  - regular re-issuance of the Referenced Token, see implementation-lifecycle. </ins> 11.4. <del> Colluding Issuers and Relying Parties have the possibility to identify the usage of credentials of a particular Holder, as the Referenced Token contains unique, trackable data. </del> <ins> Colluding Issuers and a Relying Parties have the possibility to link two transactions, as the tuple of "uri" and "index" inside the Referenced Token are unique and therefore traceable data.  By comparing the status claims of received Referenced Tokens, two colluding Relying Parties could determine that they have interacted with the same user or an Issuer could trace the usage of its issued Referenced Token by colluding with various Relying Parties.  It is therefore recommended to use Status Lists for Referenced Token formats that have similar unlinkability properties. </ins> To avoid privacy risks for colluding Relying Parties, it is <del> recommended that Issuers use batch issuance to issue multiple tokens, such that Holders can use individual tokens for specific Relying Parties.  In this case, every Referenced Token MUST have a dedicated Status List entry.  Revoking batch issued Referenced Tokens might reveal this correlation later on. </del> <ins> RECOMMENDED that Issuers use batch issuance to issue multiple tokens, see implementation-lifecycle. </ins> <del> To avoid information leakage by the values of "uri" and "index", Issuers are RECOMMENDED to: </del> <ins> To avoid further correlatable information by the values of "uri" and "index", Issuers are RECOMMENDED to: </ins> choose non-sequential, pseudo-random or random indices
12. <del> TBD Declare whether JWT and CWT representations can be used interchangeably by the same issuer.  For instance, declare whether a status list can reference both JWT and CWT tokens. </del> <ins> 12.1. The lifetime of a Status List (and the Status List Token) depends on the lifetime of its Referenced Tokens.  Once all Referenced Tokens are expired, the Issuer may stop serving the Status List (and the Status List Token). Referenced Tokens may be regularly re-issued to increase security or to mitigate linkability and prevent tracking by Relying Parties.  In this case, every Referenced Token MUST have a fresh Status List entry. Referenced Tokens may also be issued in batches, such that Holders can use individual tokens for every transaction.  In this case, every Referenced Token MUST have a dedicated Status List entry.  Revoking batch issued Referenced Tokens might reveal this correlation later on. </ins> 13.
Abstract This specification defines status list data structures for <del> representing the status of JSON Web Tokens (JWTs) RFC7519 and CBOR Web Tokens (CWTs) RFC8392.  The status list data structures </del> <ins> representing the status of JSON Web Tokens (JWTs) RFC7519, CBOR Web Tokens (CWTs) RFC8392, and other tokens secured by CBOR Object Signing and Encryption _8152.  The status list data structures </ins> themselves are also represented as JWTs or CWTs. 1. <del> JSON Web Tokens (JWTs) RFC7519 and CBOR Web Tokens (CWTs) RFC8392 as secure token formats, have vast possible applications.  Some of these </del> <ins> JSON Web Tokens (JWTs) RFC7519, CBOR Object Signing and Encryption (COSE) _8152 objects, and CBOR Web Tokens (CWTs) RFC8392 as secure token formats, have vast possible applications.  Some of these </ins> applications can involve issuing a token whereby certain semantics about the token can change over time, which are important to be able to communicate to relying parties in an interoperable manner, such as
4.2. <del> TBD </del> <ins> This section defines the "StatusList" structure for a CBOR-encoded Status List. The "StatusList" structure is a map (Major Type 5) and defines the following entries: * "bits": REQUIRED.  Unsigned int (Major Type 0) that contains the number of bits in the per Referenced Token in the Status List.  The allowed values for "bits" are 1, 2, 4 and 8.  * "lst": REQUIRED.  Byte string (Major Type 2) that contains the Status List as specified in status-list-json. The following example illustrates the CBOR representation of the Status List: The following is the CBOR diagnostic output of the example above: </ins> 5.
5.2. <del> TBD </del> <ins> The Status List Token MUST be encoded as a "CBOR Web Token (CWT)" according to RFC8392. Applications MAY use the media type "statuslist+cwt" for a CWT in accordance with the rules outlined in this specification. The following content applies to the CWT protected header: "3" (content type): REQUIRED.  The CWT content type MUST be "statuslist+cbor". The following content applies to the CWT Claims Set: "1" (issuer): REQUIRED.  Same definition as "iss" claim in (#status-list-token-jwt). "2" (subject): REQUIRED.  Same definition as "sub" claim in (#status-list-token-jwt). "6" (issued at): REQUIRED.  Same definition as "iat" claim in (#status-list-token-jwt). "4" (expiration time): OPTIONAL.  Same definition as "exp" claim in (#status-list-token-jwt). "TBD" (status list): REQUIRED.  The status list claim MUST specify the Status List conforming to the rules outlined in status-list- cbor. The following additional rules apply: The CWT MAY contain other claims. The CWT 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 CWTs with an invalid signature. 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 discretion of the verifying party. The following is a non-normative example for a Status List Token in CWT format: The following is the CBOR diagnostic output of the example above: </ins> 6.
6.3. <del> TBD </del> <ins> The Referenced Token MUST be encoded as a "COSE Web Token (CWT)" object according to RFC8392. The following content applies to the JWT Claims Set: "1" (issuer): REQUIRED.  Same definition as "iss" claim in (#referenced-token-jwt). "TBD" (status): REQUIRED.  The status claim is encoded as a "Status" CBOR structure and MUST include at least one data item that refers to a status mechanism.  Each data item in the "Status" CBOR structure comprises a key-value pair, where the key must be a CBOR text string (Major Type 3) specifying the identifier of the status mechanism, and the corresponding value defines its contents.  This specification defines the following data items: "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-jwt) but MUST be encoded as a "StatusListInfo" CBOR structure with the following fields: "idx": REQUIRED.  Same definition as "idx" claim in (#referenced-token-jwt). "uri": REQUIRED.  Same definition as "uri" claim in (#referenced-token-jwt). Application of additional restrictions and policy are at the discretion of the verifying party. The following is a non-normative example for a decoded payload of a Referenced Token: TBD: example 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)" RFC8152. It is required to encode the status mechanisms Referenced Tokens refer to using the "Status" CBOR structure defined in (#referenced- token-cwt). It is RECOMMENDED to use "status" for the label of the field that contains the "Status" CBOR structure. Application of additional restrictions and policy are at the discretion of the verifying party. The following is a non-normative example for a decoded payload of a Referenced Token: TBD: example </ins> 7.
"4" (expiration time): OPTIONAL.  Same definition as "exp" claim in status-list-token-jwt. <del> "65534" (status list): REQUIRED.  The status list claim MUST </del> <ins> "65534" (time to live): OPTIONAL.  Same definition as "ttl" claim in status-list-token-jwt. "65535" (status list): REQUIRED.  The status list claim MUST </ins> specify the Status List conforming to the rules outlined in status-list-cbor.
The following content applies to the CWT Claims Set: <del> "1" (issuer): REQUIRED.  Same definition as "iss" claim in referenced-token-jwt. </del> <ins> "1" (issuer): REQUIRED when also present in the Referenced Token. Same definition as "iss" claim in referenced-token-jwt. </ins> "65535" (status): REQUIRED.  The status claim is encoded as a "Status" CBOR structure and MUST include at least one data item
MUST be equal to that of the "iss" claim contained within the Referenced Token. <del> "sub": REQUIRED.  The "sub" (subject) claim MUST specify a unique string identifier for the Status List Token.  The value MUST be equal to that of the "uri" claim contained in the "status_list" claim of the Referenced Token. </del> <ins> "sub": REQUIRED.  The "sub" (subject) claim MUST specify the URI of the Status List Token.  The value MUST be equal to that of the "uri" claim contained in the "status_list" claim of the Referenced Token. </ins> "iat": REQUIRED.  The "iat" (issued at) claim MUST specify the time at which the Status List Token was issued.
List.  Each Referenced Token is allocated an index during issuance that represents its position within this bit array.  The value of the bit(s) at this index correspond to the Referenced Token's status.  A <del> Status List may either be provided by an endpoint or be signed and </del> <ins> Status List may either be provided via HTTPS or be signed and </ins> embedded into a Status List Token, whereas this document defines its representations in JWT and CWT.  Status Lists may be composed for expressing a range of Status Types.  This document defines basic
8.1. To obtain the Status List or Status List Token, the Relying Party <del> MUST send a HTTP GET request to the Status List Endpoint. Communication with the Status List Endpoint MUST utilize TLS.  Which version(s) should be implemented will vary over time.  A TLS server certificate check MUST be performed as defined in Section 5 and 6 of RFC6125. </del> <ins> MUST send an HTTP GET request to the URI provided in the Referenced Token. If the Status List is provided by an HTTP endpoint (and not as a Status List Token), the provider of the Status List MUST utilize TLS. Which version(s) should be implemented will vary over time.  A TLS server certificate check MUST be performed as defined in Section 5 and 6 of RFC6125. </ins> The Relying Party SHOULD send the following Accept-Header to indicate the requested response type:
The following content applies to the CWT protected header: <del> "16" TBD (type): REQUIRED.  The type of the CWT MUST be "statuslist+cwt" as defined in CWT.typ. </del> <ins> "16" (type): REQUIRED.  The type of the CWT MUST be "statuslist+cwt" as defined in RFC9596. </ins> The following content applies to the CWT Claims Set:
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> <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
"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> <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
applications can involve issuing a token whereby certain semantics about the token can change over time which are important to be able to communicate to relying parties in an interoperable manner, such as <del> whether the token is considered revoked by its issuer. This document defines a status list using JWT and CWT for representation that is capable of communicating the individual statuses of multiple tokens.  The document also defines how an issuer of a token references a status list in a JWT or CWT which has a status to convey. </del> <ins> whether the token is considered invalidated or suspended by its issuer. This document defines a Status List in JWT and CWT representations that describes the individual statuses of multiple Referenced Tokens. The statuses of all Referenced Tokens are conveyed via a bit array in the Status List.  Each Referenced Token is allocated an index during issuance which represents a position within this bit array and the value of the bit(s) at this position correspond to the Referenced Token's status.  The document also defines how an issuer of a Referenced Token in JWT or CWT representation references a Status List Token.  Status Lists may be composed for expressing a range of Status Types, the document defines basic Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types.  The Status List Token may be used by an issuer in the Issuer-Holder-Verifier model, as described in (XXX) to express the status of verifiable credentials (Referenced Tokens) issued by an issuer. </ins> The following diagram depicts the basic conceptual relationship. <ins> 1.1. Revocation mechanisms are an essential part for most identity ecoosystems.  In the past, revocation of X.509 TLS certificates has been proven difficult as traditional certificate revocation lists (CRLs) have limited scalability and the Online Certificate Status Protocol (OCSP) has additional privacy risks as the client is leaking the requested website to a third party.  OSCP stapling is adressing some of these problems at the cost of less up-to-date data.  Modern approaches use accumulator-based revocation registries and Zero- Knowledge-Proofs to accomodate for this privacy gap but face scalability issues again. The approach of this specification seeks to find a balance between scalability, security and privacy by minimizing the status information to mere bits and compressing the resulting binary data. Thereby a Status List may contain statuses of 100.000 or more Referenced Tokens, but still remain relatively small.  Placing large amounts of Referenced Tokens into the same list also enables a herd privacy towards the Issuer. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
3. <del> 3.1. </del> <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> <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> <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.
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 <del> the referenced status list JWT. </del> <ins> the referenced Status List Token. </ins> <del> The JWT MUST contain an "sts" (status) claim conforming to the </del> <ins> The JWT MUST contain an "status" (status) claim conforming to the </ins> rules outlined in The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. <del> 3.1.1. </del> <ins> 4.1.1. </ins> <del> The following rules apply to validating the "sts" (status) claim </del> <ins> The following rules apply to validating the "status" (status) claim </ins> The claim value MUST be a valid JSON object. <del> The claim value object MUST contain a "typ" (type) attribute with a string based value that represents the type of status list referenced.  The value MUST be equal to that of the "typ" attribute in the "sts_lst" claim for the referenced status list. </del> The claim value object MUST contain an "idx" (index) attribute with a numberic based value that represents the index to check for <del> status information in the status list for the current JWT.  The </del> <ins> status information in the Status List for the current JWT.  The </ins> value of this attribute MUST be a non-negative number, containing a value of zero or greater.  Refer to xx for details on the validation procedure. The claim value object MUST contain a "uri" attribute with a <del> string based value that identifies the status list containing the </del> <ins> string based value that identifies the Status List containing the </ins> status information for the JWT.  The value of this attribute MUST be a uri conforming to <del> 3.2. </del> <ins> 4.2. </ins> <del> The following rules apply to validating a JWT based status list. Application of additional restrictions and policy are at the </del> <ins> The following rules apply to validating a JWT based Status List Token.  Application of additional restrictions and policy are at the </ins> discretion of the verifying party. The JWT MUST contain an "iss" (issuer) claim that contains a
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> <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.
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> <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.
Optional parameters: n/a <del> Encoding considerations: binary; A JSON-based Status List is a JSON Object. </del> <ins> Encoding considerations: See status-list-json of this specification </ins> <del> Security considerations: See (#Security) of [ this specification ] </del> <ins> Security considerations: See Security of this specification </ins> Interoperability considerations: n/a <del> Published specification: [ this specification ] </del> <ins> Published specification: this specification </ins> <del> Applications that use this media type: Applications using [ this specification ] for updated status information of tokens </del> <ins> Applications that use this media type: Applications using this specification for updated status information of tokens </ins> Fragment identifier considerations: n/a <del> Additional information: File extension(s): n/a Macintosh file type code(s): n/a </del> <ins> Additional information: n/a </ins> Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de
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> <ins> Encoding considerations: See status-list-token-jwt of this specification </ins> <del> Security considerations: See (#Security) of [ this specification ] </del> <ins> Security considerations: See Security of this specification </ins> Interoperability considerations: n/a <del> Published specification: [ this specification ] </del> <ins> Published specification: this specification </ins> <del> Applications that use this media type: Applications using [ this specification ] for updated status information of tokens </del> <ins> Applications that use this media type: Applications using this specification for updated status information of tokens </ins> Fragment identifier considerations: n/a <del> Additional information: File extension(s): n/a Macintosh file type code(s): n/a </del> <ins> Additional information: n/a </ins> Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de
Optional parameters: n/a <del> Encoding considerations: binary; A CBOR-based Status List is a CBOR Object. </del> <ins> Encoding considerations: See status-list-cbor of this specification </ins> <del> Security considerations: See (#Security) of [ this specification ] </del> <ins> Security considerations: See Security of this specification </ins> Interoperability considerations: n/a <del> Published specification: [ this specification ] </del> <ins> Published specification: this specification </ins> <del> Applications that use this media type: Applications using [ this specification ] for updated status information of tokens </del> <ins> Applications that use this media type: Applications using this specification for updated status information of tokens </ins> Fragment identifier considerations: n/a <del> Additional information: File extension(s): n/a Macintosh file type code(s): n/a </del> <ins> Additional information: n/a </ins> Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de