This seems appropriate, as these should not be ambiguous within their context.
It sounds like there is currently no need for the same sort of optional CBOR tag to distinguish status lists themselves. However, do you see a reason to register that for future application use? -DW > On Dec 15, 2025, at 2:28 PM, Paul Bastian <[email protected]> wrote: > > Hi all, > > we have received feedback and questions regarding the CBOR tagging for the > Status List Token in CWT format and suggest to make a normative change. > Currently, the draft -14 does not make any statement whether: > - the CWT strcuture is tagged (see > https://datatracker.ietf.org/doc/html/rfc8392#section-6) > - the COSE Sign1 (or similar) structure is tagged (see > https://datatracker.ietf.org/doc/html/rfc9052#name-basic-cose-structure) > > As we currently do not make any statement, this leaves implementations > parsing a Status List Token in CWT format to expect 4 different options. > Within interop testing for OpenID4VCI we have seen a lot of struggels with > similar CBOR structures. Within ISO 18013-5 the choice was to always use > untagged variants. > At the same time, we already require to use application/statuslist+cwt when > the Status List Token is received within a HTTP response. > > We are suggesting a normative change to require the untagged version for CWT > and any COSE signing/MAC structure, to reduce implementation complexity and > give clear guidance by adding the following sentence: "The Status List Token > MUST not be tagged with the tags defined in section 6 of {{RFC8392}} or in > section 2 of {{RFC9052}}." A Pull request can be found on our Github > repository: https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/322 > > Paul+Christian+Tobias > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
