Hi Carsten,
Just like JWTs and CWTs, the CWT Claims Set in the header parameter is a data
structure. It's the applications using them that profile them to use
particular claims and assign them specific semantics in their context. An
OpenID Connect ID Token defines semantics for a particular kind of JWT, just
like STIR defines semantics for other kinds of JWTs. SCITT is assigning
semantics to a particular use of the CWT Claims header parameter.
The draft-ietf-cose-cwt-claims-in-headers creates a syntax to which
applications will assign semantics.
-- Mike
-----Original Message-----
From: Carsten Bormann <[email protected]>
Sent: Friday, October 27, 2023 3:42 AM
To: Francesca Palombini <[email protected]>
Cc: Michael Jones <[email protected]>;
[email protected]; [email protected]; [email protected]
Subject: Re: [IANA #1284212] expert review for
draft-ietf-cose-cwt-claims-in-headers (cose)
The part that I don’t understand is the semantics.
LAKE/edhoc kccs/kcwt is clear: This is the identity, and here (cnf) is the key
for that.
For claims-in-headers we know that the syntax is one of CCS/CWT, but I don’t
think there is any text that indicates what links this information with the
COSE data item.
It might be dangerous to leave the semantics of including the claim set/CWT to
the context.
It might be OK, and JWT might lead us into experience that this is so.
It might be OK, if we explicitly say “there is no semantics” (e.g., presenting
a key does NOT mean this is the key that applies here).
I haven’t done the digging yet to find out.
Grüße, Carsten
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
