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: 6.3. <del> TBD </del> <ins> The Referenced Token MUST be encoded as a "COSE Web Token (CWT)" object according to RFC8392. The following content applies to the JWT Claims Set: "1" (issuer): REQUIRED.  Same definition as "iss" claim in (#referenced-token-jwt). "TBD" (status): REQUIRED.  The status claim is encoded as a "Status" CBOR structure and MUST include at least one data item that refers to a status mechanism.  Each data item in the "Status" CBOR structure comprises a key-value pair, where the key must be a CBOR text string (Major Type 3) specifying the identifier of the status mechanism, and the corresponding value defines its contents.  This specification defines the following data items: "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-jwt) but MUST be encoded as a "StatusListInfo" CBOR structure with the following fields: "idx": REQUIRED.  Same definition as "idx" claim in (#referenced-token-jwt). "uri": REQUIRED.  Same definition as "uri" claim in (#referenced-token-jwt). Application of additional restrictions and policy are at the discretion of the verifying party. The following is a non-normative example for a decoded payload of a Referenced Token: TBD: example 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)" RFC8152. It is required to encode the status mechanisms Referenced Tokens refer to using the "Status" CBOR structure defined in (#referenced- token-cwt). It is RECOMMENDED to use "status" for the label of the field that contains the "Status" CBOR structure. Application of additional restrictions and policy are at the discretion of the verifying party. The following is a non-normative example for a decoded payload of a Referenced Token: TBD: example </ins> 7.