jiebi/CodeConvo huggingface dataset:
Code change:
Fixes most of Relaxes requirements on referenced token in terminology issuer in status list token is only required when also present in referenced token (and matching checked) reorder references

Related discussion:
text: 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
Code change:
Closes # URL
batch issued credentials might be revealed in an status list update, which might correlate the related referenced tokens/credentials
improve privacy/prevent tracking by regular re-issuance of referenced tokens

Related discussion:
text: 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
Code change:
Closes # URL
batch issued credentials might be revealed in an status list update, which might correlate the related referenced tokens/credentials
improve privacy/prevent tracking by regular re-issuance of referenced tokens

Related discussion:
text: 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
Code change:
Closes # URL
batch issued credentials might be revealed in an status list update, which might correlate the related referenced tokens/credentials
improve privacy/prevent tracking by regular re-issuance of referenced tokens

Related discussion:
text: 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.
Code change:
adds ttl to the generated examples: Rendered verison: URL
Should be fine now, with some minor fixes to rendering and adding the proposed values. Can you please check again NAME
It appears the example uses a text string instead of a byte string for the idx value.
Good catch, the referenced token example is wrong!

Related discussion:
text: "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.
Code change:
adds ttl to the generated examples: Rendered verison: URL
Should be fine now, with some minor fixes to rendering and adding the proposed values. Can you please check again NAME
It appears the example uses a text string instead of a byte string for the idx value.
Good catch, the referenced token example is wrong!

Related discussion:
text: Claim Name: "status" <ins> Claim Key: TBD (requested assignment 65535) </ins> Claim Description: Reference to a status or validity mechanism containing up-to-date status information on the CWT.
Code change:
adds ttl to the generated examples: Rendered verison: URL
Should be fine now, with some minor fixes to rendering and adding the proposed values. Can you please check again NAME
It appears the example uses a text string instead of a byte string for the idx value.
Good catch, the referenced token example is wrong!

Related discussion:
text: Specification Document(s): status-list-token-cwt of this specification <ins> Claim Name: "ttl" Claim Key: TBD (requested assignment 65534) Claim Description: Time to Live Change Controller: IETF Specification Document(s): status-list-token-cwt of this specification </ins> 13.4. This specification establishes the IANA "Status Mechanism Methods"
Code change:
Pretty straightforward fix for an oversight when relaxing the requirements for status list
The spec says: However, JWT defines as "REQUIRED if present in the reference token which means, the REQUIRED word is a bit misleading without the if-statement that follows. Either use OPTIONAL for , or also say in the CWT section.

Related discussion:
text: "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.
Code change:
Pretty straightforward fix for an oversight when relaxing the requirements for status list
The spec says: However, JWT defines as "REQUIRED if present in the reference token which means, the REQUIRED word is a bit misleading without the if-statement that follows. Either use OPTIONAL for , or also say in the CWT section.

Related discussion:
text: 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
Code change:
Pretty straightforward fix for an oversight when relaxing the requirements for status list
The spec says: However, JWT defines as "REQUIRED if present in the reference token which means, the REQUIRED word is a bit misleading without the if-statement that follows. Either use OPTIONAL for , or also say in the CWT section.

Related discussion:
text: Claim Name: "status" <ins> Claim Key: TBD (requested assignment 65535) </ins> Claim Description: Reference to a status or validity mechanism containing up-to-date status information on the CWT.
Code change:
Pretty straightforward fix for an oversight when relaxing the requirements for status list
The spec says: However, JWT defines as "REQUIRED if present in the reference token which means, the REQUIRED word is a bit misleading without the if-statement that follows. Either use OPTIONAL for , or also say in the CWT section.

Related discussion:
text: Specification Document(s): status-list-token-cwt of this specification <ins> Claim Name: "ttl" Claim Key: TBD (requested assignment 65534) Claim Description: Time to Live Change Controller: IETF Specification Document(s): status-list-token-cwt of this specification </ins> 13.4. This specification establishes the IANA "Status Mechanism Methods"
Code change:
The first and second sentence of this description seem contradictory to me. The first sentence seems to state that (all?) Status List Tokens should have a unique identifier included as their claim. The second sentence directly contradicts this uniqueness requirement. Perhaps I'm misunderstanding what is meant by 'uniqueness' in the first sentence, but in that case the language is quite ambiguous. As the claim seems to have been added solely for including the from the Referenced Token in the Status List Token (as described in ), perhaps the sentences should simply be reworded to not mention uniqueness. So something like: : REQUIRED. The (subject) claim MUST be equal to the claim contained in the claim of the Referenced Token.
The is basically the URI by which the Status List Token is retrieved. As Status List Tokens may be downloaded for offline use, further re-transmission or archiving, its important to also store the URI in the Token, such that it can be compared by others to the of the claim of the Referenced Token. I see that the text may be confusing, it should be clearer as "URI" may be better than "unique string identifier" and URI is unique anyway. How about: : REQUIRED. The (subject) claim MUST specify the URI of the Status List Token. The value MUST be equal to that of the claim contained in the claim of the Referenced Token.
Yes thank you, this wording clears it up. If you wanted to be very precise instead of you could write . But perhaps my suggestion is too verbose, what you've written gets the idea across.

Related discussion:
text: 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.
Code change:
"endpoint" is still mentioned in there, unsure we we completely want to get rid of it
Section '8.1. Status List Request' currently states: This seems redundant when the endpoint is used to retrieve a Status List Token, as the Token's integrity is already guaranteed by requiring it to be signed using an asymmetric cryptographic algorithm. If requiring TLS was intended for providing confidentiality of the Token, this seems unnecessary. The endpoint is publicly accessible - there does not seem to be any client authentication mechanisms described for it - thus the Tokens could be retrieved by anybody.
Hi NAME , thanks for the feedback! I think you are correct that we could relax using TLS when a Status List Token is queried. However, if an unsigned Status List is returned, we need TLS as an integrity mechanism.
Yes I vehemently agree :) Btw, perhaps the issue is a bit broader that just permitting plain HTTP when obtaining Status List Tokens. I don't think it's currently explicitly stated in the specification whether a Status List Provider should/must simultaneously provide both plain Status Lists and Status List Tokens. Ie the standard states that an RP should use the Accept-Header to indicate the requested response type, but it does not specify what the Status List Provider should do if it is unable to provide the requested response type. I think this is somewhat relevant under this issue as: if you were to simply add a sentence to the spec permitting plain HTTP for Status List Tokens then an Issuer would have to decide whether to put an HTTP or HTTPS URI in the claim of the Referenced Token but this somewhat contradicts with the Accept-Header mechanism which would seem to indicate (to the reader of the spec) that it's up to the RP to choose the response type. Perhaps the Issuer should explicitly specify supported response type(s) in the claim of the Referenced Token? Ie there could be an additional attribute in the object under the claim specifying the supported formats. Such an attribute could prove beneficial in other regards as well. For example, I don't immediately see an use case where an Issuer/Status List Provider would be providing cbor/cwt Status Lists for JOSE Referenced Tokens.
Section mentions Status List Endpoint. The term is not mentioned elsewhere in the specification nor is it defined.
Thanks for the feedback. Discussion Editors Call: connected to the discussion whether Status List Provider is an entity that shall be described in the spec intend to clarify the term for next iteration

Related discussion:
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 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
Code change:
Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex

Related discussion:
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 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
Code change:
Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex

Related discussion:
text: Status List as specified in status-list-json. The following example illustrates the CBOR representation of the <del> Status List: </del> <ins> Status List in Hex: </ins> <del> The following is the CBOR diagnostic output of the example above: </del> <ins> The following is the CBOR Annotated Hex output of the example above: </ins> 5.
Code change:
Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex

Related discussion:
text: discretion of the verifying party. The following is a non-normative example for a Status List Token in <del> CWT format (not including the type header yet): </del> <ins> CWT format in Hex: </ins> <del> The following is the CBOR diagnostic output of the example above: </del> <ins> The following is the CBOR Annotated Hex output of the example above: </ins> 6.
Code change:
Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex

Related discussion:
text: Application of additional restrictions and policy are at the discretion of the verifying party. <del> The following is a non-normative example for a decoded payload of a Referenced Token: </del> <ins> The following is a non-normative example of a Referenced Token in CWT format in Hex: The following is the CBOR Annotated Hex output of the example above: </ins> 6.4.
Code change:
Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex

Related discussion:
text: 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:
Code change:
Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex

Related discussion:
text: 8.3. <del> 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. 8.4. </del> TBD 9.
Code change:
Rendered Version: URL
COSE typ is now registered in IANA. Because of that, the TBD could be removed.

Related discussion:
text: 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:
Code change:
Adds a claim key for used in the status list token in CWT format and fixes the reference.

Related discussion:
text: "65534" (time to live): OPTIONAL.  Same definition as "ttl" claim in status-list-token-jwt. <del> "65535" (status list): REQUIRED.  The status list claim MUST </del> <ins> "65533" (status list): REQUIRED.  The status list claim MUST </ins> specify the Status List conforming to the rules outlined in status-list-cbor.
Code change:
Status List claim was referencing Chapter 4.1 instead of Chapter 4, which made it ambiguous whether to base64url-encode or not

Related discussion:
text: The allowed values for "bits" are 1, 2, 4 and 8. "lst": REQUIRED.  Byte string (Major Type 2) that contains the <del> Status List as specified in status-list-json. </del> <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
Code change:
Redered version: URL
the text is existing in JWT encoding, does it make sense to emphasize this change from standard base64url encoding again in our spec?
I like the solution in sd-jwt - they introduced it as terminology: Should we move that to terminology and reference via base64url in the text?

Related discussion:
text: "lst": REQUIRED.  JSON String that contains the status values for all the Referenced Tokens it conveys statuses for.  The <del> value MUST be the base64url-encoded (as defined in Section 2 of RFC7515) Status List as specified in status-list. </del> <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
Code change:
Redered version: URL
the text is existing in JWT encoding, does it make sense to emphasize this change from standard base64url encoding again in our spec?
I like the solution in sd-jwt - they introduced it as terminology: Should we move that to terminology and reference via base64url in the text?

Related discussion:
text: These bits are concatenated: <del> Resulting in the byte array and compressed/base64url encoded status </del> <ins> Resulting in the byte array and compressed/base64url-encoded status </ins> list: 11.
Code change:
Rendered version: URL
We should probably add a small section mentioning that should be set to when explaining the endpoint.

Related discussion:
text: server certificate check MUST be performed as defined in Section 5 and 6 of RFC6125. <ins> The HTTP endpoint SHOULD support the use of Cross-Origin Resource Sharing (CORS) CORS and/or other methods as appropriate to enable Browser-Based clients to access it. </ins> The Relying Party SHOULD send the following Accept-Header to indicate the requested response type: