Thanks Carsten,
First, I agree with you on the importance of "typ". As you know,
draft-ietf-cose-typ-header-parameter is defining a "typ" header parameter for
COSE, so we're providing a means of declaring the semantics of a COSE object in
another simple specification.
You wrote "In the COSE world, we try to be a bit more tied down on the
semantics of the information in a COSE data item. So you are motivating why
using a CWT as a header parameter that is not further qualified as to its
meaning in the COSE data item, should not be possible in COSE." I see what
you're saying but disagree both with the specifics and your conclusion. Yes,
CBOR does specify what the data type of a value is. But knowing that something
is a CBOR string doesn't tell you whether it's a family name or Pantone color
name or a postal address. You might respond, yes, but there are CBOR Tags, but
the use of CBOR Tags is optional (unless, of course, required by the profile
being used). You know no more about the semantics of COSE payloads than you do
about CBOR objects - again, unless you know the profile.
Indeed, taking your discussion to its logical conclusion, you might have also
written "So you are motivating why using a CWT Claims Set as a COSE payload
that is not further qualified as to its meaning in the COSE data item, should
not be possible in COSE." And yet that's exactly what RFC 8392 defines.
People have found it to be useful.
You wrote "What I am interested in right now is using these as COSE header
parameters." So am I. :-) When contained in COSE header parameters, without a
profile, you know exactly as much about the semantics of CWT claims as you do
when they occur in the payload. And with a profile, you know the semantics no
matter whether the CWT claims are in the payload or the header parameter. It's
parallel in its semantic contents either way. As I view it, that's as it
should be.
Therefore, practically, I'd ask you to support the registration of the header
parameter. At least three working groups need something like it. And I'd also
ask you to support us sharing the same header parameter number between EDHOC
and cwt-claims-in-headers. The EDHOC profile of it will specify that the "cnf"
claim MUST be present *and* how to use it. It's a profile - again, as it
should be.
Best wishes,
-- Mike
-----Original Message-----
From: Carsten Bormann <[email protected]>
Sent: Sunday, November 5, 2023 9:59 AM
To: Michael Jones <[email protected]>
Cc: lgl island-resort.com <[email protected]>; Francesca Palombini
<[email protected]>; [email protected];
[email protected]; [email protected]
Subject: Re: [COSE] [IANA #1284212] expert review for
draft-ietf-cose-cwt-claims-in-headers (cose)
On Nov 5, 2023, at 09:41, Michael Jones <[email protected]> wrote:
>
> Carsten, you asked " In all these cases, does the CWT added to the header
> form its own CWT that can be evaluated as such independently before jumping
> into the COSE object, or is it just intended to convey additional parameters
> to the processing intended for the COSE object with the other header
> parameters?"
>
> To be clear, even normal CWTs (and JWTs) are simply bags of claims. Their
> definitions express syntax - not fully-actionable semantics. Profiles define
> semantics for the kinds of CWTs (or JWTs) that they define.
> Cwt-claims-in-headers are the same. They define syntax for where you can put
> claims. It's up to profiles like lake-edhoc or SCITT to define how they're
> using those claims and what processing is associate with them.
> Cwt-claims-in-headers doesn't change anything in that regard.
Hi Mike,
thank you for elucidating this so clearly.
You provide a description of JWTs and CWTs.
What I am interested in right now is using these as COSE header parameters.
In the COSE world, we try to be a bit more tied down on the semantics of the
information in a COSE data item.
So you are motivating why using a CWT as a header parameter that is not further
qualified as to its meaning in the COSE data item, should not be possible in
COSE.
Together with an unambiguous “profile" identification, where the profile
defines the semantics of any CCSes/CWTs included unambiguously, CWTs (or CCSes)
do make sense in a COSE header.
Giving the header parameter carrying them a header parameter number that is
specific to the usage (profile, if you want to call it this way) is one way to
do this, and that is why I like the way EDHOC is using the kccs/kcwt header
parameters.
Using a future “typ” parameter might supply semantics as well; to make a
generic CCS/CWT header parameter useful we just would need to ensure that a
“typ” is present and that this “typ" actually does define the semantics of a
generic CCS/CWT header parameter (and possibly some restrictions on that
parameter and where it may occur). We could register a “typ” in conjunction
with the generic CCS/CWT header parameter.
Grüße, Carsten
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
