Floating-point values in the CTAP2 canonical CBOR encoding form #1263
Comments
|
I believe the intent was that integers get 'compressed' to slimmer types to hold their information, such as immediate or 1-byte form, when appropriate - but that implementations aren't expected to know that e.g. a floating-point value can be stored losslessly into a binary16. I would expect extensions and attestations to specify the specific kind of floating-point representation they expect (like the location extension today) |
|
I see that currently, of the WebAuthn extensions, only the location extension uses floating-point values, namely The issue I raised is important especially because the draft revision of CBOR defines a data model that includes binary64 floating-point values regardless of how they were encoded in a CBOR document (whether with the 64-, 32-, or 16-bit encoding). To encourage reuse of code implementing the CTAP canonical form, the matter of how to encode floating-point numbers should be left to the CTAP canonical form rather than delegated to extensions, attestations, etc., that may use such floating-point numbers. Since only the location extension uses such numbers at the moment, that may be as simple as saying that "all floating-point values are encoded as 64-bit CBOR floating-point numbers" in the CTAP canonical form. |
|
closing since this is now submitted in the CTAP-land.... |
|
How can I track the status of this issue? As I learned once before, the issue tracker for FIDO specs is apparently closed to the public. |
|
we'll note resolution here. I added this to fido-alliance/fido-2-specs#711: NOTE: Upon resolving this issue (ie, by landing a corresponding PR, or closing it in some other fashion (no action, superseded, etc), please note the resolution over in a comment on #1263 |
The CTAP2 canonical CBOR encoding form includes the following rule: "The representations of any floating-point values are not changed". Unfortunately, for canonicalization purposes, this is too vague, since this rule enables two "canonical" documents, produced by two different implementations, to represent the same floating-point number, depending on what data type that number was before it was encoded (e.g.,
floatvs.double). (Note that CBOR allows three different encodings for floating-point numbers; namely, 64-, 32-, and 16-bit.)The intent of this rule may be that—
The CTAP specification uses the word "floating-point" only once, so it doesn't clarify this matter. This is just one of several considerations for defining "canonical" encoding of "floating-point values"; see, for example, section 4.2.2 of the draft revision of CBOR.
The text was updated successfully, but these errors were encountered: