jiebi/CodeConvo huggingface dataset:
Code change:
We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL

Related discussion:
text: 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:
Code change:
after writing this I figured out changing the byte ordering, i.e. starting with byte 0 on the left might be a little more intuitive?
Yeah with fresh eyes I definately think that would be better.
reversed byte order and added the index to the ascii art

Related discussion:
text: 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.
Code change:
after writing this I figured out changing the byte ordering, i.e. starting with byte 0 on the left might be a little more intuitive?
Yeah with fresh eyes I definately think that would be better.
reversed byte order and added the index to the ascii art

Related discussion:
text: 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
Code change:
fixes the examples to use constant timestamps in gzip encoding minor changes/fixes to the ascii art / code blocks

Related discussion:
text: 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:
Code change:
reorder section on Referenced Token and Status List Token URL
I did a first review of this draft. As a newbie to the topic, I found the following issues: I miss a description of the fundamental concept, i.e. the status list itself is a JWT (issued by the same issuer issuing the JWTs), the status list JWT is obtained from a URL hosted by that issuer or another party, the link between the JWT and its status list is provided through data in the JWT. I suggest to add this in the Introduction (or an Overview) section. When reading Section 3.1. for the first time I was confused whether it describes the status list JWT or the JWT referring to the status list. I think it is the latter and it should be clear to the reader on first sight. I think the order of definition should be changed. Right now, I'm supposed to understand how a status list JWT is used in a JWT without even knowing what that status list JWT is. I suggest to change order: 1) Overview of the concepts, 2) specify status list JWT (structure and where/how to obtain), 3) embedding in a JWT (syntax, processing rules, ...).
Agree on 1+2. As mentioned in we need a better word describing the "Token" that is being described by the status List. I will make a PR using "Subject Token" as this comprises both JSON and CBOR formats. Agree on 3 as well.
For reordering it would make sense to get forward with the existing PRs first and do it afterwards..
Addressing some of these issues in
What's left to do: reorder Status List Token first and Referenced Token afterwards

Related discussion:
text: Relying parties MUST reject JWTs that are not valid in all other respects per "JSON Web Token (JWT)" RFC7519. <del> 4.2.1. </del> <ins> 4.1.1. </ins> The following rules apply to validating the "status_list" (status list) claim
Code change:
reorder section on Referenced Token and Status List Token URL
I did a first review of this draft. As a newbie to the topic, I found the following issues: I miss a description of the fundamental concept, i.e. the status list itself is a JWT (issued by the same issuer issuing the JWTs), the status list JWT is obtained from a URL hosted by that issuer or another party, the link between the JWT and its status list is provided through data in the JWT. I suggest to add this in the Introduction (or an Overview) section. When reading Section 3.1. for the first time I was confused whether it describes the status list JWT or the JWT referring to the status list. I think it is the latter and it should be clear to the reader on first sight. I think the order of definition should be changed. Right now, I'm supposed to understand how a status list JWT is used in a JWT without even knowing what that status list JWT is. I suggest to change order: 1) Overview of the concepts, 2) specify status list JWT (structure and where/how to obtain), 3) embedding in a JWT (syntax, processing rules, ...).
Agree on 1+2. As mentioned in we need a better word describing the "Token" that is being described by the status List. I will make a PR using "Subject Token" as this comprises both JSON and CBOR formats. Agree on 3 as well.
For reordering it would make sense to get forward with the existing PRs first and do it afterwards..
Addressing some of these issues in
What's left to do: reorder Status List Token first and Referenced Token afterwards

Related discussion:
text: it conveys statuses for.  The value MUST be computed using the algorithm described in jwt-status-list-claim-encoding. <del> 4.2.2. </del> <ins> 4.1.2. </ins> 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
Code change:
reorder section on Referenced Token and Status List Token URL
I did a first review of this draft. As a newbie to the topic, I found the following issues: I miss a description of the fundamental concept, i.e. the status list itself is a JWT (issued by the same issuer issuing the JWTs), the status list JWT is obtained from a URL hosted by that issuer or another party, the link between the JWT and its status list is provided through data in the JWT. I suggest to add this in the Introduction (or an Overview) section. When reading Section 3.1. for the first time I was confused whether it describes the status list JWT or the JWT referring to the status list. I think it is the latter and it should be clear to the reader on first sight. I think the order of definition should be changed. Right now, I'm supposed to understand how a status list JWT is used in a JWT without even knowing what that status list JWT is. I suggest to change order: 1) Overview of the concepts, 2) specify status list JWT (structure and where/how to obtain), 3) embedding in a JWT (syntax, processing rules, ...).
Agree on 1+2. As mentioned in we need a better word describing the "Token" that is being described by the status List. I will make a PR using "Subject Token" as this comprises both JSON and CBOR formats. Agree on 3 as well.
For reordering it would make sense to get forward with the existing PRs first and do it afterwards..
Addressing some of these issues in
What's left to do: reorder Status List Token first and Referenced Token afterwards

Related discussion:
text: 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
Code change:
Defines the HTTP GET API URL
We need to document end to end the validation procedure for a JWT and CWT referencing a status list including resolution of the status list, validation of the status list and how to get the status information for the JWT referencing the status list.

Related discussion:
text: 7. <ins> 7.1. To obtain the Status List or Status List Token, the Verifier MUST send a HTTP GET request to the Status List Endpoint.  Communication with the Status List Endpoint MUST utilize TLS.  Which version(s) should be implemented will vary over time.  A TLS server certificate check MUST be performed as defined in Section 5 and 6 of RFC6125. The Verifier SHOULD send the following Accept-Header to indicate the requested response type: "application/statuslist+jwt" for Status List JWTs "application/statuslist+cwt" for Status List CWTs If the Verifier does not send an Accept Header, the reponse type is assumed to be known implicit or out-of-band. 7.2. In the successful response, the Status List Provider MUST use the following content-type: "application/statuslist+jwt" for Status List JWTs "application/statuslist+cwt" for Status List CWTs In the case of "application/statuslist+jwt", the response MUST be of type JWT and follow the rules of jwt-status-list-format-and- processing.  In the case of "application/statuslist+cwt", the response MUST be of type JWT and follow the rules of cwt-status-list- format. The response SHOULD use gzip Content-Encoding as defined in RFC9110. 7.3. If caching is required (e.g., to enable the use of alternative mechanisms for hosting, like Content Delivery Networks), the control of the caching mechanism SHOULD be implemented using the standard HTTP Cache-Control as defined in RFC9111. 7.4. 8. </ins> TBD Define parallel CWT representations for Status Lists and Referenced Tokens.
Code change:
Defines the HTTP GET API URL
We need to document end to end the validation procedure for a JWT and CWT referencing a status list including resolution of the status list, validation of the status list and how to get the status information for the JWT referencing the status list.

Related discussion:
text: 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
Code change:
Defines the HTTP GET API URL
We need to document end to end the validation procedure for a JWT and CWT referencing a status list including resolution of the status list, validation of the status list and how to get the status information for the JWT referencing the status list.

Related discussion:
text: 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
Code change:
Defines the HTTP GET API URL
We need to document end to end the validation procedure for a JWT and CWT referencing a status list including resolution of the status list, validation of the status list and how to get the status information for the JWT referencing the status list.

Related discussion:
text: List Provider may be the issuer of the Status List but may also be outsourced to a trusted third party. <del> 10. </del> <ins> 11. </ins> This document specifies no IANA actions.
Code change:
Use term Relying Party and Issuer URL
Sometimes we use Verifier, sometimes we use Relying Party. After deciding this, we should add them to the Terminology
As this is moving to OAuth Security working Group, we should adopt Relying Party as terminology

Related discussion:
text: 7.1. <del> To obtain the Status List or Status List Token, the Verifier MUST send a HTTP GET request to the Status List Endpoint.  Communication with the Status List Endpoint MUST utilize TLS.  Which version(s) should be implemented will vary over time.  A TLS server certificate check MUST be performed as defined in Section 5 and 6 of RFC6125. </del> <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.
Code change:
Use term Relying Party and Issuer URL
Sometimes we use Verifier, sometimes we use Relying Party. After deciding this, we should add them to the Terminology
As this is moving to OAuth Security working Group, we should adopt Relying Party as terminology

Related discussion:
text: 9.2. <del> TODO consumers/Verifiers of the status list should be aware if they fetch the up-to-date data </del> <ins> TODO consumers/Relying Party of the status list should be aware if they fetch the up-to-date data </ins> 9.3.
Code change:
Use term Relying Party and Issuer URL
Sometimes we use Verifier, sometimes we use Relying Party. After deciding this, we should add them to the Terminology
As this is moving to OAuth Security working Group, we should adopt Relying Party as terminology

Related discussion:
text: from tracking the usage of the Referenced Token when the status is being checked.  If an Issuer offers status information by referencing a specific token, this would enable him to create a profile for the <del> issued token by correlating the date and identity of Verifiers, that are requesting the status. </del> <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
Code change:
Use term Relying Party and Issuer URL
Sometimes we use Verifier, sometimes we use Relying Party. After deciding this, we should add them to the Terminology
As this is moving to OAuth Security working Group, we should adopt Relying Party as terminology

Related discussion:
text: TODO elaborate on increased privacy if the status list is hosted by a third party instead of the issuer reducing tracking possiblities TODO evaluate deifnition of Status List Provider?  An entity that hosts <del> the Status List as a resource for potential verifiers.  The Status List Provider may be the issuer of the Status List but may also be outsourced to a trusted third party. </del> <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.
Code change:
Change typo in Status List Token sub claim description URL
The in the "Status List JWT Format and Processing Requirements" section has 'The JWT MUST contain a "sub" (subject) claim that contains an unique string identifier for that Referenced Token.' but I believe it should be "... unique string identifier for that Status List Token."
that's correct, thanks for pointing this out Brian

Related discussion:
text: the Referenced Token. The JWT MUST contain a "sub" (subject) claim that contains an <del> unique string identifier for that Referenced Token.  The value </del> <ins> unique string identifier for that Status List Token.  The value </ins> MUST be equal to that of the "uri" claim contained in the "status" claim of the Referenced Token.
Code change:
gathering some ideas on privacy and security considerations
Looking good NAME you should be able to run 'make fix-lint' locally to fix the whitespace issues
Need to remove the trailing whitespaces for the markdown tooling to be happy

Related discussion:
text: 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.