On Mon, 4 Mar 2024, at 19:11, Alan DeKok wrote: > The downside is that CBOR is likely more expressive than TLVs, and > perhaps what people should be moving towards. There's no reason to > stick with TLVs simply because we've been using them for years. It's > 2024, new technologies exist.
The problem is the framing does not use any of the expressive parts of CBOR. So this is not really relevant here. >> (I'm not fixed on using CBOR for the message format, but since CTAP2 also >> uses CBOR at least the client needs to have a CBOR library anyway.) > > I think tho that the EAP implementations don't need to implement CBOR > in order to do CTAP2, right? They just hand the data to another > library, and it does the work. My understanding here is that the document as it is requires a CBOR serialiser, even if you then intend to just those opaque materials to a CTAP2 library; this is why a CBOR framing description is in the document. Right? Using an entire serialiser to support only a map carrying attributes with 1->3 *predetermined* keys seems a bit of a cannon to deal with a mosquito solution as they go. As a hypothetical, would people have a stronger opinion here if CBOR was swapped for protocol buffers or ASN.1 in the document? EAP-EDHOC on the other hand (which uses CBOR/COSE) allows an EAP implementation to readily extract the components of EDHOC without having to understand how to serialise EDHOC; enabling straight forward outsourcing to a library. Cheers _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
