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.
Best wishes,
-- Mike
-----Original Message-----
From: Carsten Bormann <[email protected]>
Sent: Sunday, November 5, 2023 8:05 AM
To: lgl island-resort.com <[email protected]>
Cc: Michael Jones <[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 4, 2023, at 20:28, lgl island-resort.com <[email protected]> wrote:
>
>
>> On Nov 4, 2023, at 8:03 PM, Carsten Bormann <[email protected]> wrote:
>>
>> On Oct 27, 2023, at 20:57, lgl island-resort.com <[email protected]>
>> wrote:
>>>
>>> It seems like this is in hand, but FYI, in EAT, we want to use ccs to bring
>>> the “eat_profile” claim up from the CWT Claims-Set to the top level so that
>>> dispatch of the EAT processing can be done before processing COSE. It is
>>> possible that COSE is providing encryption making it a lot of work to
>>> access the “eat_profile" claim. The “eat_profile" is kind of a sub-type
>>> mechanism in EAT.
>>
>> This is an interesting example.
>>
>> It seems more obvious to me to just extract that one claim and define a
>> parameter, with well-defined semantics!, for just that.
>
> I mentioned these in another thread/message:
>
> - OEMID claim also to dispatch to OEM-specific attestation processors
>
> - When the EAT is encrypted, any other claim you want in the clear for
> processing before decryption
>
> - In general dispatch, pre-processing and early error checks before full CWT
> processing, particularly for encrypted CWTs
>
> Because the claims that are candidate for all this may not be known all at
> once, it’s nice to have the general facility for any claim, rather than
> having to define each COSE parameter.
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?
BTW, it seems that “eat-profile” might play a quite similar role to “typ” (I’m
not suggesting to merge these, just to use this similarity for thinking about
the space).
Grüße, Carsten
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
