Re: [Rats] EAT Profiles

["Smith, Ned" <[e-mail]>]

This thread started out about interoperability and has morphed into code reuse. Both are reasonable topics, but did the interoperability topic get resolution?

Profile Interoperability summary:

  *   Given n profiles, we need n libraries because each profile is different from the other (n-1) profiles. (even if there is 99% code reuse, there is still 1% that is different otherwise they would be the same profile).
  *   Not clearly stated, but implied(?) that profiles don’t have optionality (otherwise there would be more than one profile hiding inside a profile). Agree?
  *   Profile identifiers are globally distinguishable/unique (there’s no profile registry – and we don’t want one?). Implied: if a profile changes there is a new profile identifier assigned.
  *   A goal of profiles is to remove optionality that is possible under EAT?
  *   Another goal is a profile is a subset of EAT (more constrained)
  *   Another goal is a profile can be a superset of EAT (extended to satisfy product specific considerations). Are there any constraints on proper/improper ways to specify “superset” functionality (e.g., only by way of a defined extension point)?
  *   Other I’ve overlooked?
-Ned

From: RATS <[e-mail]> on behalf of Thomas Fossati <[e-mail]>
Date: Monday, September 19, 2022 at 7:19 AM
To: Michael Richardson <[e-mail]>
Cc: Hannes Tschofenig <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Rats] EAT Profiles

hi Michael,

On Mon, Sep 19, 2022 at 2:18 PM Michael Richardson <[e-mail]<mailto:[e-mail]>> wrote:

Hannes Tschofenig <[e-mail]<mailto:[e-mail]>> wrote:
    > [Hannes] We have created a library that produced an EAT based on our
    > profile and it was not too complex.

You missed the point.
You create *A* library that deals with *your* profile.

So, we need N libraries for N-profiles, and since the EAT document has quite
a large number of possible combinations, each use of EAT will wind up with
its own library.  There will be no reuse, which was the point of doing this work.

I have to strongly disagree with the conclusion that "there will be no reuse".
We reuse *a lot* of existing library code: COSE (~8k LOC), CBOR (~17k LOC) & EAT (~3.5k LOC for the claims we inherit).
On top of that we push the profile-specific code that adds the PSA attester claims and wraps all the other bits together into one interface.  That amounts to (~3k LOC), which, considering we support two profiles (current and legacy) with one codebase, I reckon it's OK.  Besides, with this library we support both attesters and verifiers.
Basically, the delta amounts to defining the claims' set that have no EAT equivalent.  I expect anyone designing an EAT-based token today to take advantage of the richer EAT vocabulary compared to what was available to us when we started the PSA token work (i.e., March 2019).

    > [Hannes] Maybe you could post it to the TEEP list.

The EAT question is what a profile should say here.

IME §6.2. of EAT is doing a great job.  The only surprising bit in TEEP (for me) is the absence of mandatory claims: can it really contain *any* claims and still be called a TEEP token?  It seems strange, but as it's been said, this is really a question for the TEEP WG to answer.

cheers,
--
Thomas