IMHO, profiles are fine and appropriate for specifications that fundamentally are targeted to be building blocks for interoperable solutions, but not complete interoperable solution themselves. If i had a say, i would like to see a lot stronger text though such as MUST/SHOULD instead of non-normative requirements text in the profile section. I also think it would be appropriate the require specification (profile must have an RFC) instead of "profile text can be whatever" , and that RFCs expected to provide an interoperable solution MUST NOT refer to this document technology without also including or referring to or including such a profile. And example profile would be nice too. Call it ACRP - "Authors Completely Random Profile" or the like, so only feeble minded readers would use it. As you say, This is not specific to this draft, but IMHO applies to all similar cases of profiles, and yes, the IETF has not been particularily good about it, primarily because IMHO, we do have a history of actually building interoperable "Internet" solutions, and it seems to be primarily the IOT space that moves into what more and more looks like IDIC. Btw: RPL, RFC6550 is also not interoperable without profile. Example profile: RFC8994, section 6.12.1. But ROLL/RPL did never bothre to publish an RFC for the profile definition, so IMHO, the authors of this eat draft are doing quite well here in comparison in my book. The RPL book for example was that a profile specification for something that evolves and extends like RPL is better done as a living document == ongoing draft no RFC drops. No idea if that would be equally appropriate for EAT, or if extensions would better be done through IANA registries..). Cheers Toerless On Tue, Jun 07, 2022 at 04:26:28PM -0700, Laurence Lundblade wrote: > (sending again with corrections and because it doesn’t seem to have posted to the archive) > > Hi Elliot, > > To me EAT inherits extant interoperability issues in CBOR, COSE and CWT. Or perhaps we say EAT is a framework like CBOR, COSE and CWT. With profiles, EAT takes the issue head-on and does something about it. > > Yes, I sometimes think “I” in IETF is for interoperability and is fundamental to the IETF culture. I’ve been arguing lately to limit the number of forms of EAT for this reason. I am a bit surprised that CBOR, COSE and CWT don’t deal with the issue more directly. I really do believe in interoperability — and this belief led me to write much of the profiles section (kind of wondering what people would say). > > Here’s some of the issues: > > CBOR — RFC 8949 clearly allows for both indefinite and definite encoding. If one implementation chooses one and another the other, there will not be interoperability. > > COSE — No algorithms are mandated, not even for a receiver. No full key identification scheme is mandated (CMS at least had this). > > CWT — There are no required claims to send or to be able to receive. > > CBOR/JSON/… — This is somewhat new particularly with CDDL now useful to specify multiple encodings. RFC 8428 has this issue. > > To me this flexibility and consequently these interoperability issues are built in to the frame up and approach not only for EAT, but also for CBOR, COSE and CWT. I don’t think we want to change that approach. For example, we want the CBOR encoding flexibility and we want the COSE algorithm and key identification flexibility in specifications at this level. > > I can see adding some more wording to EAT that gives the background I’ve given above in the profiles section. I can’t see changing the approach to start mandating algorithms and encodings. Maybe there’s something else to do? > > Also, I don’t think PSA token gives tight interoperability. It doesn’t say which algorithms to use or how key identification works. Maybe that is OK. Maybe it is not. > > FIDO is a protocol that I know gives complete interoperability. For example in FIDO you MUST implement all of a set of crypto algorithms on the server side; the client side gets to choose. > > One more comment below. > > LL > > > > > On Jun 5, 2022, at 5:57 AM, Eliot Lear via Datatracker <noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>> wrote: > > > > Major: > > > > 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. > > > > 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. > > CoSWID is doing this with COSE. > > > > > 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. > > > > In short, the profile mechanism is harmful to the very concept of > > interoperability. > > -- > Iot-directorate mailing list > Iot-directorate@xxxxxxxx > https://www.ietf.org/mailman/listinfo/iot-directorate -- --- tte@xxxxxxxxx -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
