Original text:
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>  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>  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

Reviewer comments:
This PR adds: CBOR/CWT encoding for status list and status list info Example implementation for CBOR/CWT Not included yet: examples for referenced tokens (COSE, CWT) but that should be trivial to add. URL
The decoded cbor is: The list does not seem to be valid zlib.
I've tried with cyberchef and it seems to work for me: -> zlib inflate =
You are right, I probably tried on the hexstring :D
I assume there will be a lot of comments. I had some troubles with the claim language for non-CWTs btw. Please review and give feedback. NAME NAME NAME
I was wondering whether it would be better to define a CDDL for Status, StatusList and StatusListInfo. Basically, having a high-level CDDl description of all objects and then having some specific sections for JWT, COSE, CWT that define how they are used in the corresponding objects.
Also keep in mind that claim for CWT will require IANA to assign us an integer number, so we can use it in the CWT.
There is a problem with the width of the CBOR diagnostic notation examples. The datatracker only allows a width of 72, but cborg defaults to 100 and apparently can't be configured in CLI mode.
I can write a small JS script that uses the cborg library and configures the width to 72. Would this be even possible? I didn't check by myself.
Yes that would be possible and is the only option I have found so far. I was searching for a pure python solution (which would be cleaner imho) but that seems to be not possible right now.
The abstract, intro, diagrams wrt referenced tokens description should refer to COSE and JOSE instead of CWT/JWT. Otherwise, non-CWT COSE objects such as ISO 18013-5 MSO cannot use this spec. Same applies to SD-JWT VC encoded secured using JWS.
We adjusted the terminology already, but the text in the introduction is not matching yet. In fact COSE is already mentioned at all places, so the question is whether we should align things and say Referenced Token = JOSE/COSE-based
Use reference to RFC9052 instead of RFC8152
As described in the title, detail the CWT representation of the status list which is complementary to the JWT representation.
Maybe a naive question but what's the motivation for this draft having the two representations? When positioned as a companion of the SD-JWT VC draft and aiming for the OAuth WG, it seems like keeping the scope tighter and only having the JWT representation would be sufficient/okay/preferable.
NAME credential formats like mDocs do not have a status/revocation mechanism hence a CWT based representation is beneficial to these applications as they dont typically have JWT support.
I dunno, I'm not convinced that necessitates having multiple status list token representations. Especially in one draft. This draft, which again is being positioned as a companion to the SD-JWT VC. I suspect the work would be more palatable for adoption with a scope that's reflective of that. But maybe that's just me. Thanks for the context.

Revised text:
Abstract This specification defines status list data structures for  <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.  <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