jiebi/CodeConvo huggingface dataset:
Code change:
Micha proposed to change REVOKED to INVALID, as it gives less intention whether this is a permanent state and the issuers could reflect a suspension also with a 1bit size status list as well
I'm in agreement with Kristina, the more I look at this the more I think we should have one possible enumeration of statuses rather than allowing every issuer to define their own, the question then becomes how big that set needs to be as it controls how many bits are allocated to each credential in the status list.
I'm fine with defining the first bit as valid/invalid. I think providing the option for additional bits offers benefits with acceptable tradeoffs
I've made some changes, please recheck NAME NAME
umm I thought we agreed to remove the concept of the "typ" attribute.. so no and no .
Yeah that was captured here NAME URL
But I assume the Status List Token will have a JOSE header to properly distinguish it from other JWTs, right?
I approve, but moved to separate issue
NAME typo on my end. yes, JWT should be typed ( claim present), the current spec also introduces a body claim as far as I can see, which is what I am not in agreement with.
NAME I am confused. so the idea is to merge this PR and then remove the "type" JWT claim in PR ?
comment edited, I got confused here as well. There is an issue open already as a task and I would like to not blow up the PRs too much
NAME ready for merge
I am a little confused with calling "VALID", "INVALID" Status List , but agreed this should be mergedOne minor typo

Related discussion:
text: 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.
Code change:
Micha proposed to change REVOKED to INVALID, as it gives less intention whether this is a permanent state and the issuers could reflect a suspension also with a 1bit size status list as well
I'm in agreement with Kristina, the more I look at this the more I think we should have one possible enumeration of statuses rather than allowing every issuer to define their own, the question then becomes how big that set needs to be as it controls how many bits are allocated to each credential in the status list.
I'm fine with defining the first bit as valid/invalid. I think providing the option for additional bits offers benefits with acceptable tradeoffs
I've made some changes, please recheck NAME NAME
umm I thought we agreed to remove the concept of the "typ" attribute.. so no and no .
Yeah that was captured here NAME URL
But I assume the Status List Token will have a JOSE header to properly distinguish it from other JWTs, right?
I approve, but moved to separate issue
NAME typo on my end. yes, JWT should be typed ( claim present), the current spec also introduces a body claim as far as I can see, which is what I am not in agreement with.
NAME I am confused. so the idea is to merge this PR and then remove the "type" JWT claim in PR ?
comment edited, I got confused here as well. There is an issue open already as a task and I would like to not blow up the PRs too much
NAME ready for merge
I am a little confused with calling "VALID", "INVALID" Status List , but agreed this should be mergedOne minor typo

Related discussion:
text: 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.
Code change:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Related discussion:
text: 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.
Code change:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Related discussion:
text: Claim Name: "status_list" Claim Description: A status list containing up-to-date status <del> information on multiple other JWTs encoded as a bitarray. </del> <ins> information on multiple tokens. </ins> Change Controller: IETF
Code change:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Related discussion:
text: Status Method Value: "status_list" Status Method Description: A status list containing up-to-date <del> status information on multiple other JWTs encoded as a bitarray. </del> <ins> status information on multiple tokens. </ins> Change Controller: IETF
Code change:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Related discussion:
text: Claim Key: TBD (requested assignment 65533) Claim Description: A status list containing up-to-date status <del> information on multiple other CWTs encoded as a bitarray. </del> <ins> information on multiple tokens. </ins> Change Controller: IETF
Code change:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Related discussion:
text: Status Method Value: "status_list" Status Method Description: A status list containing up-to-date <del> status information on multiple other CWTs encoded as a bitarray. </del> <ins> status information on multiple tokens. </ins> Change Controller: IETF
Code change:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Related discussion:
text: 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
Code change:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Related discussion:
text: 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
Code change:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Related discussion:
text: 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
Code change:
fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types

Related discussion:
text: Optional parameters: n/a <del> Encoding considerations: binary; </del> <ins> Encoding considerations: See status-list-token-cwt 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
Code change:
Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho

Related discussion:
text: SD-JWT-based Verifiable Credentials SD-JWT.VC introduce the usage of Status List in Section 3.2.2.2.  The "status" object uses the same <del> encoding as a JWT as defined in referenced-token-jwt. </del> <ins> encoding as a JWT as defined in referenced-token-jose. </ins> The following is a non-normative example for a Referenced Token in SD-JWT-VC serialized form as received from an Issuer:
Code change:
Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho

Related discussion:
text: 6.3. <del> The Referenced Token MUST be encoded as a "COSE Web Token (CWT)" object according to RFC8392. </del> <ins> The Referenced Token MAY be encoded as a "COSE Web Token (CWT)" object according to RFC8392 or other formats based on COSE. </ins> The following content applies to the CWT Claims Set:
Code change:
Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho

Related discussion:
text: "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- <del> jwt but MUST be encoded as a "StatusListInfo" CBOR structure </del> <ins> jose but MUST be encoded as a "StatusListInfo" CBOR structure </ins> with the following fields: "idx": REQUIRED.  Same definition as "idx" claim in <del> referenced-token-jwt. </del> <ins> referenced-token-jose. </ins> "uri": REQUIRED.  Same definition as "uri" claim in <del> referenced-token-jwt. </del> <ins> referenced-token-jose. </ins> Application of additional restrictions and policy are at the discretion of the verifying party.
Code change:
Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho

Related discussion:
text: The following is the CBOR Annotated Hex output of the example above: <del> 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)" RFC9052. It is required to encode the status mechanisms referred to in the Referenced Token using the "Status" CBOR structure defined in referenced-token-cwt. </del> <ins> ISO mdoc ISO.mdoc may utilize the Status List mechanism by introducing the "status" parameter in the Mobile Security Object (MSO) as specified in Section 9.1.2.  The "status" parameter uses the same encoding as a CWT as defined in referenced-token-cose. </ins> It is RECOMMENDED to use "status" for the label of the field that contains the "Status" CBOR structure.
Code change:
Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho

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 for an IssuerAuth as specified in ISO mDL (also referred to as signed MSO) in Hex: </ins> <del> TBD: example </del> <ins> The following is the CBOR Diagnostic Notation of the example above: </ins> 7.
Code change:
Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho

Related discussion:
text: Check for the existence of a "status" claim, check for the existence of a "status_list" claim within the "status" claim and validate that the content of "status_list" adheres to the rules <del> defined in referenced-token-jwt for JWTs and referenced-token-cwt for CWTs.  This step can be overruled if defined within the </del> <ins> defined in referenced-token-jose for JWTs and referenced-token- cose for CWTs.  This step can be overruled if defined within the </ins> Referenced Token Format natively Resolve the Status List from the provided URI
Code change:
Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho

Related discussion:
text: Change Controller: IETF <del> Specification Document(s): referenced-token-jwt of this </del> <ins> Specification Document(s): referenced-token-jose of this </ins> specification 14.3.
Code change:
Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho

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

Related discussion:
text: The claim value object MUST contain a "lst" (list) attribute with a string based value that represents the status values for all the <del> tokens it conveys statuses for.  The value MUST be a base64 encoded string using RFCXXX containing a GZIP compressed octet string RFC1952. </del> <ins> tokens it conveys statuses for.  The value MUST be computed using the algorithm described in jwt-status-list-claim-encoding. 3.2.2. Each status of a Referenced Token MUST be represented with a bit size of 1,2,4, or 8.  Therefore up to 2,4,16, or 256 statuses for a Referenced Token, depending on the bit-size, are possible.  This limitation is intended to limit bit manipulation necessary to a single byte for every operation and thus keeping implementations simpler and less error prone. The overall status list is encoded as a byte array.  Depending on the "bit-size" each byte corresponds to 8/(#bit-size) statuses (8,4,2, or 1).  The status of each Referenced Token is identified using an index that maps to one or more specific bits within the byte array.  The index starts counting at 0 and ends with "size" - 1(being the last valid entry).  The bits within an array are counted from least significant bit "0" to the most significant bit ("7").  All bits of the byte array at a particular index are set to a status value. The complete byte array is compressed using gZIP RFC1952. The result of the gZIP compression is then encoded as base64 encoding as defined in Section 4 of RFC4648 and stored as a string. Example of a byte representing 8 statuses (1-bit status list) with indices 0,1,2,3,4,5,6,7 (1 byte): Example of a more complex status list of length 12 using 2 bit statuses (3 bytes): </ins> 3.3.
Code change:
As the similar requirement was relaxed on SD-JWT, I think we should consider the same.

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 via HTTPS or be signed and embedded into a Status List Token, whereas this document defines its representations in JWT and CWT.  Status Lists may be composed for expressing a range of Status Types.  This document defines basic Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types.  The document also defines how an issuer of a Referenced Token references a Status List (Token). </del> <ins> Status List may either be provided via HTTPS or be protected within a Status List Token by cryptographic signature or MAC, whereas this document defines its representations in JWT and CWT.  Status Lists may be composed for expressing a range of Status Types.  This document defines basic Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types.  The document also defines how an issuer of a Referenced Token references a Status List (Token). </ins> An example for the usage of a Status List is to manage the status of issued access tokens as defined in section 1.4 of RFC6749.  Token
Code change:
As the similar requirement was relaxed on SD-JWT, I think we should consider the same.

Related discussion:
text: The JWT MAY contain other claims. <del> The JWT MUST be digitally signed using an asymmetric cryptographic algorithm.  Relying parties MUST reject the JWT if it is using a Message Authentication Code (MAC) algorithm.  Relying parties MUST reject JWTs with an invalid signature. </del> <ins> The JWT MUST be secured using a cryptographic signature or MAC algorithm.  Relying Parties MUST reject JWTs with an invalid signature. </ins> Relying parties MUST reject JWTs that are not valid in all other respects per "JSON Web Token (JWT)" RFC7519. Application of additional restrictions and policy are at the <del> discretion of the verifying party. </del> <ins> discretion of the Relying Party. </ins> The following is a non-normative example for a Status List Token in JWT format:
Code change:
As the similar requirement was relaxed on SD-JWT, I think we should consider the same.

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