Re: [Rats] EAT Profiles

[Michael Richardson <[e-mail]>]

Smith, Ned <[e-mail]> wrote:
    > There are two other "EAT" profiles published besides the TEEP profile
    > (https://datatracker.ietf.org/doc/draft-tschofenig-rats-aiss-token/ and
    > https://datatracker.ietf.org/doc/draft-tschofenig-rats-psa-token/
    > ). The AISS profile lists the subset of EAT that it uses (see
    > [1]). They are described as "EAT Profiles". The AISS profile uses a few
    > EAT code points but seems to redefine structures such as nonce-label as
    > an aiss-hash-type. Unless I'm not reading it right this is different
    > from the EAT definition [2]. The AISS profile is within the EAT
    > definition for nonce, namely .size 32, .size 48 and .size 64 are a
    > subset of .size (8..64). I'd have to see the CBOR encodings for each to
    > be certain, but it seems they would have the same encoding and would
    > satisfy an EAT schema check. But a AISS schema check would likely
    > reject some other nonce statements that pass a schema check written to
    > the EAT draft.

I didn't look at the document yet, but it seems that getting the claims right
is probably an important and reasonable thing that users should be doing.
It seems odd to redefine things.

    > Is this a good example of what the WG intends in terms of how profiles
    > should work?

    > To Michael's earlier point, the aiss seems to do a lot of work to
    > arrive at a profile (given it appears to use just 3 EAT claims and each
    > is redefined as a more constrained interpretation of the EAT type
    > definition at the leaf.

I think that it should be simpler... even just your paragraph above is making
me wince.

    > developer must implement the profile schema also. This implies schema
    > compliant profiles incur development cost to be vetted as subsets of
    > the EAT schema. The EAT draft doesn't seem to expect automated schema
    > acceptance (by the EAT schema) as profiles can be human readable
    > text.

I would expect that one could write an EAT checker (or verify evidence in a
Verifier) without knowing which EAT user was in use.  That's why I'd like to
see EAT define a small number (<10) "profiles".
I don't think that such tools need to know the details of all the claims to be
able to produce a result.  Obviously some claims may need to be in particular
formats to be acceptable, but that should be a semantic layer constraint,
rather than a syntactic layer constraint.

    > In short, should a profile of EAT could pass an automated schema check
    > based on independent implementation of an EAT schema checker without
    > foreknowledge of the profile's schema? The intention seems to be that
    > (at least a subset of) the profile schema is subset of the EAT
    > schema. Should that subset be checkable by automated means?

I'd like to answer yes.
That's how we arrive at re-useable code libraries, which is a major argument
for doing this work.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-