Re: [Rats] Where does a EAT end? - consensus?

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

To summarize, it appears the way to address the issue of a potential for non-interoperability of “top-level” statements in the EAT draft is to acknowledge that this potential exists, and that it can be accommodated in a variety of ways that don’t need to be discussed within the EAT draft.

Does anyone disagree that this addresses the issue?

-Ned

From: RATS <[e-mail]> on behalf of Giridhar Mandyam <[e-mail]>
Date: Thursday, June 2, 2022 at 1:40 PM
To: Thomas Fossati <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Rats] Where does a EAT end? (was: Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

> Not sure I follow: profiles are type constraints that apply to *existing* top-level EAT types.  They can't be used to extend the number and shape of base EAT types.

I was commenting on interop, not on extension of top-level EAT types.  I don’t think we need to provide a mechanism to extend the base EAT types within the EAT specification itself.  I’ve already mentioned with the example of JWT’s that the underlying specifications such as JS allow for that today.

If someone has identified a new field that must be added at the top-level of an EAT, they are welcome to come up with their own specification, as described in https://github.com/ietf-rats-wg/eat/pull/194.  I personally don’t think we should call it an EAT at that point, but that is a minor point.

-Giri

From: Thomas Fossati <[e-mail]>
Sent: Thursday, June 2, 2022 1:30 PM
To: Giridhar Mandyam <[e-mail]>; [e-mail]
Subject: Re: [Rats] Where does a EAT end? (was: Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)


WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
> Giridhar Mandyam <[e-mail]<mailto:[e-mail]>> wrote:
> > > I think the underlying data structures make it extensible,
> > > independent of the CDDL notation.  However if an implementor
> > > chooses to extend EAT without an accompanying standard as a
> > > result, then interoperability may not be assured.  Therefore it is
> > > in an implementor’s interest to define a standard if they are
> > > seeking interop.
>
> > The core difference is the extensibility story for the claims-set is
> > governed by the CWT Claims registry, whilst the EAT type system has
> > no such mechanism (yet).
>
> I don’t agree:  the profile definition addresses interop – see
> https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat#section-7.
> Up to this point, no-one has objected to the way profiles are defined
> in the specification, nor the lack of a registry.

Not sure I follow: profiles are type constraints that apply to
*existing* top-level EAT types.  They can't be used to extend the number
and shape of base EAT types.

FWIW, I'm a big fan of profiles.





IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.