Discussion: Profiles support

[setrofim]

EAT (https://ietf-rats-wg.github.io/eat/draft-ietf-rats-eat.html) allows the use of any claims defined by CWT or JWT, in addition to those expressly defined by the EAT standard. All claims are considered optional by EAT.

It is impractical to try to evaluate all the possible claims (as the set is essentially unbounded). Also, specific applications may require certain claims to always be present or have additional constraints on their values. It is proposed that this additional functionality is handled via EAT token "profiles".

A profile will handle the following:

• Interpreting and validating additional claims, not defined in the core claims in the EAT standard.
• Defining claims that are mandatory (in the context of that profile).
• Enforcing additional constraints on (both, core and extended) claims' values. (For core claims such constraints would have to result in strictly narrower valid ranges).
• Enforcing inter-claim constraints. E.g, if claims are mutually-exclusive or the values of one are constrained by the values of another.

This thread is to discuss how such profiles might be added to the existing Eat implementation.

[setrofim]

A concrete example of a profile that would define additional claims and add mandatory and inter-claim constraints is Arm PSA token: https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-05

[thomas-fossati]

It looks like there are two obvious options:

1. Extend:
   1. Group the additional claims needed by a given profile into a new struct type (say, type MyProfile struct {});
   2. Embed MyProfile into the the top level Eat;
   3. Provide a func MyProfileValidator(e Eat) error that can access the extended EAT token in its entirety and apply all the intra and inter-claim constraints needed to satisfy the profile.
2. Compose:
   1. Wrap each EAT claim with its JSON and CBOR tags, and make it publicly exportable;
   2. Create a type MyProfile struct {} which embeds the (cherry-picked) EAT claims, and adds its own;
   3. Handle validation of MyProfile in a func (MyProfile) Validate() error method.

I'd personally prefer the (less intrusive, inherently distributed) "compose" approach , however, I think Submods of the "non-token" type, which are recursively defined in terms of Eat, are problematic to handle in that context.

[setrofim]

I second the the preference for composition. However I don't think claims should be contained within the profile. The profile should wrap the token as a whole, and then provide interpretation and validation of the underlying claims, but it should not contain any of the "data"; and therefore, there would be no need for JSON/CBOR tag for the profile -- the only thing that gets serialised is the Eat.

Somewhat orthogonal to the Profiles, is the need for the EAT token to contain arbitrary claims -- this is specified by the spec itself and is not an extension to the format (well, strictly speaking, any CWT or JWT claims, rather than completely arbitrary). However, as we cannon provide strong type definitions for such claims, they would have to be deserialised into something like a map[int]interface{} (can we define a recursive IntMap type that enforces the integer key requirement?)

The Profile would then allow interpreting those "generic" claims as strongly typed and named values. However, the "master" value for each claim should be contained within the Eat, and not the profile. E.g. setting the ArmPsaProfile.ImplementationId value should result in writing to key -75003 in underlying Eat map.