Re: [Rats] EAT Profiles

[Thomas Fossati <[e-mail]>]

hi Michael,

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

>
> Hannes Tschofenig <[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