Hi Anders, > The WebAuthn/FIDO specification details CBOR serialization requirements
(As does COSE *for its internally constructed signing inputs*, not for what goes over the wire.) > while the EAT draft specifies multiple alternatives. Maybe we need to fix that then. > There must be a reason for that. The spirit is willing, but the flesh is weak. Well, actually, the spirit is the problem. We need to get better in the willpower to nail down unneeded choices. (Of which JSON vs. CBOR is one.) > To cope with (and potentially enforce/verify), different CBOR serialization > variants, CBOR tools typically provide options: > https://github.com/peteroupc/CBOR-Java/blob/master/api/com.upokecenter.cbor.CBOREncodeOptions.md This is a bit of a Cadillac implementation with lots of options, many of which have to do with API variants as opposed to encoding options. None of the latter ones will get in the way of EAT interoperability. > The proposal is simply defining something like an "I-CBOR" that could serve > as the foundation for future standards like EAT. I-JSON was necessary because JSON implementations claim to have ingested something and then give you something else, unless you stay in the fold of I-JSON. I’m not aware of a similar problem for CBOR, so I don’t know why we’d need I-CBOR. Yes, because of historical artifacts we have different deterministic/“canonical” encoding rules — but that is of interest only where you *need* deterministic encoding. COSE did the right thing and minimized that surface so it actually doesn’t matter which ones you are using. (CTAP2 actually did that too, IIRC, they just wrote down some additional rules that they don’t actually need. But I didn’t look at this for a while.) If you really do need deterministic encoding, it’s right there in STD94 (RFC8949). You need to remember that deterministic encoding spans all the way to the application, so slapping an I-something label on the encoder is not going to give you actual interoperability if you really do need deterministic encoding. Do we? Grüße, Carsten _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
