Re: [COSE] [IANA #1284212] expert review for draft-ietf-cose-cwt-claims-in-headers (cose)

[Michael Jones <[e-mail]>]

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 <[e-mail]> 
Sent: Sunday, November 5, 2023 9:59 AM
To: Michael Jones <[e-mail]>
Cc: lgl island-resort.com <[e-mail]>; Francesca Palombini <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
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 <[e-mail]> 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