Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt

[Alexander Clouter <[e-mail]>]

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