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
