Unspecified CBOR encoding of high-valued integer numbers due to unspecified threshold

[peteroupc]

Section 9 contains the following text:

When the JavaScript value is a non-integer number, it is converted to a 64-bit CBOR floating point number. Otherwise, when the JavaScript type corresponds to a JSON type, the conversion is done using the rules defined in Section 4.2 of [RFC7049] (Converting from JSON to CBOR), but operating on inputs of JavaScript type values rather than inputs of JSON type values.

However, because section 4.2 of the RFC says the following:

JSON numbers without fractional parts (integer numbers) are represented as integers ...; integers longer than an implementation-defined threshold (which is usually either 32 or 64 bits) may instead be represented as floating-point values.

and section 9 doesn't specify a threshold in this sense, then CBOR canonicalization is not possible if those integers are present — as a result it is not specified unambiguously whether certain integers higher than a threshold (2³²? 2³¹? 2⁶⁴? some other threshold?) should be encoded as integers as or as floating-point numbers, since the relevant threshold is "implementation-defined".

[agl]

I think we should write something to state the obvious here, that implementations are not allowed to arbitrarily change integers into floating-point values. However, it seems unlikely that we'll tidy this up prior to PR.

[agl]

(From the call of 2019-02-06:)

It's also possible for a floating-point value in Javascript to happen to be an integer. Thus the type of the translated CBOR will depend on the values of the input, which seems like it would break things.

However, since we don't have any implementations of the generic transform of extensions that I'm aware of, we could change things in level two without breaking any existing systems.

[selfissued]

Note that if values used by an extension are floating point, the extension can specify that they always be represented as floating point - even if values happen to be integers. The location extension https://www.w3.org/TR/webauthn/#sctn-location-extension does this for the coordinate values, for instance.

[nadalin]

@jcjones Please review

[selfissued]

Unless @jcjones disagrees, I believe that we should close this with no action.

[jcjones]

I agree with closing this no action. Ultimately, this has to be some other spec's fix.

[peteroupc]

Cross-referencing the issue for the draft revision of the CBOR specification.

[peteroupc]

I should make an observation: Strictly speaking there are no "integer numbers" (that is, integer number types) in JavaScript (until perhaps recently with BigInt). JavaScript until recently has only one number type, namely a 64-bit floating-point number (of the class Number), and no integer types such as 16-, 32- or 64-bit signed integers. In that case, the phrase "When the JavaScript value is a non-integer number..." should perhaps be changed to "When the JavaScript value is of the type Number..." if that is what section 9 means.

[peteroupc]

I see that currently, of the defined WebAuthn extensions, only biometricPerfBounds includes number types, namely float, in client extension inputs. This suggests to me that—

• section 9 can simply say "When the JavaScript value is a float [or float or double]..." rather than "When the JavaScript value is a non-integer number", and
• WebAuthn should discourage new extension definitions that use any number type other than float (or double) in their client extension inputs.

With these changes, this issue becomes resolved as moot.