Re: [Rats] EAT Profiles

[Laurence Lundblade <[e-mail]>]

> On Sep 12, 2022, at 2:59 PM, Michael Richardson <[e-mail]> wrote:
> 
> Second, the next bunch of items:
> 
>> Use of JSON, CBOR, or both: CBOR only.
>> CBOR Map and Array Encoding: Only definite length arrays and maps.
>> CBOR String Encoding: Only definite-length strings are allowed.
>> CBOR Preferred Serialization: Encoders must use preferred serialization,
>> and decoders need not accept non-preferred serialization. 
>> COSE/JOSE Protection: See Section 8.
>> Detached EAT Bundle Support: DEB use is permitted.
>> Verification Key Identification: COSE Key ID (kid) is used, where the key
>> ID is the hash of a public key (where the public key may be used as a raw
>> public key, or in a certificate).
>> CBOR Tags: CBOR Tags are not used.
> 
> I really don't like the EAT has not made a clear judgement on these things
> already.   I'd really really like EAT to be far more opinionated.

CWT has most of this variability and it is a standards track RFC. Should the CWT authors have been more opinionated? Should someone write a follow-on RFC to it that says what CBOR serialization it should use, what key ID scheme to use, ...?

I don’t know if there have or have not been interoperability issues with CWT deployment. Probably there’s few issues with the CBOR parts because everyone just follows along with the preferred serialization and no one is trying to implement CWT in pure hardware. Possibly there are some issues with algorithm selection. Probably there just isn’t very much deployment, so we haven’t run into much. 

I’m not trying to be argumentative here. I just want to get to the bottom / heart of the issue.

> 
> The above list looks like it will be 95% of CBOR-based EAT "profiles"
> Could EAT just write this down, and give it a name?

What I wonder about here is layered or partial profiles.

We could write down the CBOR serialization selections and call it a profile, but that doesn’t give 100% end-end interoperability because it doesn’t pick the COSE algorithm, key identification scheme and such.

I’m a bit scared of the notion of partial/layered profiles because that adds complexity to EAT, but it doesn’t seem out of the question.

I’m open to solutions here and want to figure out what makes good sense.


> That way, we can well tested libraries that do the right thing here.
> I think that really this is where Eliot is coming from.

My COSE/CWT/EAT libraries deals with the variability this way:
- Receiving indefinite length maps/arrays — Supports because the CBOR library does. Can be turned off by #ifdef to save object code.
- Receiving Indefinite length strings — Not supported because a memory allocator is required and my library doesn’t want to depend on one
- Preferred serialization — Always sends it and can receive it
- Sending non-preferred — The point of this would be to reduce object code or implement in HW. This is not supported.
- Algorithms — Variable support for depending on library version and crypto library used
- Key ID — Public APIs allow caller to do what they want
- Custom COSE headers — No support yet, but eventually by public API so caller can do what they want.
- Claims — Public APIs allow the caller to do what they want

The library uses a mix of approaches for different issues. It has to be flexible because it may be used in a variety of use cases. It doesn’t guarantee interoperability by itself.


> EAT is all a la carte, and we are asking for a coordinated, three course set-menu.
> (Please pair the wine with the fish.)

Good analogy! :-)

The desire for small code size is a really big factor here. Weight watchers are definitely implementing EAT in scenarios where code and memory size are big issue.

Not sure we can provide one set menu when some are vegan, some are teetotalers and some have nut allergies, and some really really like cheese steak with a beer.

Maybe EAT is the restaurant supply company and the profile authors are the restaurants with the set menu?

LL