Hi Eliot, thanks very much for the review. One quick comment on this point: On Sun, Jun 5, 2022 at 1:57 PM Eliot Lear via Datatracker <noreply@xxxxxxxx> wrote: > The most major problem with the document is this: > > 7. Profiles > > This EAT specification does not gaurantee that implementations of it > will interoperate. The variability in this specification is > necessary to accommodate the widely varying use cases. An EAT > profile narrows the specification for a specific use case. An ideal > EAT profile will guarantee interoperability. > > This is quite counter-cultural to the IETF. You start with the > smallest set of functionality and then expand outward to cover > different use cases that make use of different extensions. I'm > not saying that profiles would not be necessary, but that some > additional thought be given to extension mechanisms. Maybe what is not immediately clear is that EAT is not a complete protocol but a framework. The EAT framework provides: * A type system -- the base claims-set & a few aggregation types; * Security envelopes based on COSE, JOSE; * CBOR and JSON serialisations; * A number of pre-defined semantics (the defined "claims") that one can readily reuse. So, a mechanism to identify specific kinds of EAT-based PDUs needs to be there from the onset, otherwise one wouldn't know how to instantiate the framework for their use case. And that's precisely the role of the profiles. For an example of a profiled EAT that builds on the EAT framework to create (demonstrably) interoperable attestation evidence see the PSA token [1]. [1] https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html > This statement in particular is quite disturbing. > > In some cases CDDL may be created that replaces CDDL in this or other > document to express some profile requirements. > > Not only is this counter-cultural, but it would require an Updates: > header on any such profile, and would further just be plain out > confusing. I don't think the "Updates" would be required: the CDDL defines a type constraint that is applicable to the specific profile, it doesn't modify the base type. See for example the way PSA restricts the nonce claim [2]. https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#section-3.1.1 > In short, the profile mechanism is harmful to the very concept of > interoperability. On the contrary, without profiles it would be probably impossible to interoperate. Cheers, thanks, -- Thomas -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
