Hi all,
we concluded the discussion with the following results:
- the CWT tag MUST not be present, as this is implicit by providing
applicaiton MIME type
- the COSE tags MUST be present and use either COSE_Sign1_Tagged or
COSE_Mac0_Tagged
As we allow both and the data structures differ in COSE, Takahiko
convinced us that it makes sense to use the tags (see
https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/311#issuecomment-3690295443).
At the same time we limit to Sign1 and Mac0, as we don't expect multi
signatures and we don't have this for JWT either.
We just released -15 that includes these changes.
Best regards,
Paul+Christian+Tobias
On 12/17/25 10:13, Christian Bormann wrote:
Hi David,
We have not seen any use-case that would require tagging - which is also why we
propose to explicitly remove it to make implementations simpler.
Within the scope of the draft and every discussion we’ve had so far about
envisioned usage of this draft, there is always explicit (e.g., media type for
http retrieval) or implicit (e.g., information present in a specific context)
knowledge of the type.
Best Regards,
Christian
On 16. Dec 2025, at 00:44, David Waite
<[email protected]> wrote:
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]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
