Original text:
4.2. <del> TBD </del>  5.

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:
4.2.  <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.