Re: [Rats] EAT Profiles

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

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. 

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. 

The aiss token profile defines an aiss-token map structure [3] that is signed by COSE_Sign1. But I'm not sure if the  aiss-token map is correct CDDL since my experience in working with map structures expects there should be code points defined for each item as in [4] (latitude, logngitute, etc...) and [5] (where ueid-label extends the claims-set-claims map). 

I struggle to understand how a schema checker informed by an aiss compliant schema could be evaluated to show that it also satisfies an independently developed schema checker written based on the EAT draft. If a constraint of profiles is this (the profile compliant structure must satisfy a schema check developed independently, then more is needed to connect the dots IMHO). The alternatives seem to be that (a) compliance checking is manual which doesn't scale or (b) schema compliance can't be achieved via an independent developer; the 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. It does expect that schemas can be accepted. (e.g., "A profile may also reuse one or more already defined claims, either as-is or with values constrained to a subset or subrange."; which I interpret as something like [1]. But a profile may also be a superset of EAT schema - "A profile may define, and possibly register, one or more new claims if needed."

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?

-Ned

[1]
; from EAT
   nonce-label = 10
   ueid-label = 256
   profile-label = 265
   aiss-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64
   aiss-nonce = (
       nonce-label => aiss-hash-type
   )

[2]
   $$Claims-Set-Claims //=
       (nonce-label => nonce-type / [ 2* nonce-type ])

   nonce-type = JC< tstr .size (10..74), bstr .size (8..64)>

[3]
  aiss-token = {
       aiss-nonce,
       aiss-instance-id,
       aiss-profile,
       aiss-implementation-id,
       aiss-lifecycle,
       aiss-boot-odometer,
       aiss-watermark,
   }

[4]
location-type = {
      latitude => number,
      longitude => number,
      ? altitude => number,
      ? accuracy => number,
      ? altitude-accuracy => number,
      ? heading => number,
      ? speed => number,
      ? timestamp => ~time-int,
      ? age => uint
  }

[5]
$$Claims-Set-Claims //= (ueid-label => ueid-type)

On 9/16/22, 9:15 AM, "RATS on behalf of Laurence Lundblade" <[e-mail] on behalf of [e-mail]> wrote:


    > On Sep 16, 2022, at 8:38 AM, Hannes Tschofenig <[e-mail]> wrote:
    > 
    > Hi Michael, Hi Laurence,
    > 
    > I am curious why it matters whether an EAT is a CWT (or not).

    EAT makes normative reference to CWT and JWT. If EAT didn’t it would have to replicate text from them, for example the section on creating and validating CWT/JWT.

    EAT shares the CWT/JWT registries rather than creating new ones.

    It seemed better than striking out on our own with something new. Mike Jones agreed.

    It makes it more likely that a library implementation will be able to support both to reduce object code on a device occasionally.

    LL


    _______________________________________________
    RATS mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/rats