Code change:
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.

Related discussion:
text: 5.2. <del> TBD </del> <ins> The Status List Token MUST be encoded as a "CBOR Web Token (CWT)" according to RFC8392. Applications MAY use the media type "statuslist+cwt" for a CWT in accordance with the rules outlined in this specification. The following content applies to the CWT protected header: "3" (content type): REQUIRED.  The CWT content type MUST be "statuslist+cbor". The following content applies to the CWT Claims Set: "1" (issuer): REQUIRED.  Same definition as "iss" claim in (#status-list-token-jwt). "2" (subject): REQUIRED.  Same definition as "sub" claim in (#status-list-token-jwt). "6" (issued at): REQUIRED.  Same definition as "iat" claim in (#status-list-token-jwt). "4" (expiration time): OPTIONAL.  Same definition as "exp" claim in (#status-list-token-jwt). "TBD" (status list): REQUIRED.  The status list claim MUST specify the Status List conforming to the rules outlined in status-list- cbor. The following additional rules apply: The CWT MAY contain other claims. The CWT 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 CWTs with an invalid signature. 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 discretion of the verifying party. The following is a non-normative example for a Status List Token in CWT format: The following is the CBOR diagnostic output of the example above: </ins> 6.