Exactly, and to Brian's point: > Looking at it from a different perspective, this could be represented as a > limited CWT claims set (to only allow specific claims) alongside the COSE key > which would separate the two concerns.
One could imagine a subset of CWT Claims, called COSE_Key_Usage, and a COSE_Key_With_Usage that would be a pair of (COSE_Key, COSE_Key_Usage), and then you could have a Set of them much like you can have a COSE_KeySet today, and OIDC-style workflows are exactly one of the places where this would come in handy. Amaury ________________________________ From: [email protected] <[email protected]> on behalf of Ilari Liusvaara <[email protected]> Sent: 23 February 2026 17:26 To: cose <[email protected]> Subject: [COSE] Re: [EXTERNAL] Re: Key restriction metadata On Mon, Feb 23, 2026 at 03:56:14PM +0000, Amaury Chamayou wrote: > For what it's worth, we have a similar requirement in our > implementation of SCITT, where the keys exposed by the service for > the purpose of receipt verification are currently exposed as a > COSE_KeySet. > > We currently use application-specific, custom tstr values in the > COSE_Key, as allowed by RFC_9052, to describe the sequence number > range that a given key is applicable to. > It would be useful to have an interoperable way to describe > constraints on key usage though, such as time range, sequence number > range etc, whether it is embedded in the key, or travels next to it > in a COSE_KeySetForPurpose. That sounds like application-specific grab bag of attributes. However, there are cases where that kind of thing is appropriate (e.g., attested workflow attributes for OIDC, as those are wildly dependent on the runner). -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
