Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
peteroupc opened this issue Aug 17, 2018 · 9 comments
Closed

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

peteroupc opened this issue Aug 17, 2018 · 9 comments
Assignees
@jcjones
Labels
stat:breaking stat:Discuss type:editorial type:technical
Milestone
L2-WD-02

Comments

@peteroupc
Copy link

peteroupc commented Aug 17, 2018 •
edited

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 (232? 231? 264? some other threshold?) should be encoded as integers as or as floating-point numbers, since the relevant threshold is "implementation-defined".
@peteroupc peteroupc changed the title Unspecified CBOR encoding of integer numbers above a threshold Unspecified CBOR encoding of integer numbers due to unspecified threshold Aug 17, 2018
@peteroupc peteroupc changed the title Unspecified CBOR encoding of integer numbers due to unspecified threshold Unspecified CBOR encoding of high-valued integer numbers due to unspecified threshold Aug 17, 2018
@nadalin nadalin added this to the L2-WD-00 milestone Aug 22, 2018
@agl
Copy link
Contributor

agl commented Sep 12, 2018

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
Copy link
Contributor

agl commented Feb 6, 2019 •
edited

(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
Copy link
Contributor

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.

@agl agl modified the milestones: L2-WD-01, L2-WD-02 Feb 20, 2019
@nadalin
Copy link
Contributor

nadalin commented Jun 12, 2019

@jcjones Please review

@selfissued
Copy link
Contributor

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

@peteroupc peteroupc mentioned this issue Jun 12, 2019
Closed
@jcjones
Copy link
Contributor

jcjones commented Jul 31, 2019

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

@jcjones jcjones closed this as completed Jul 31, 2019
@peteroupc
Copy link
Author

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

@peteroupc
Copy link
Author

peteroupc commented Aug 10, 2019 •
edited

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
Copy link
Author

peteroupc commented Aug 10, 2019 •
edited

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.

@peteroupc peteroupc mentioned this issue Aug 10, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jcjones jcjones

Labels
stat:breaking stat:Discuss type:editorial type:technical
Projects
None yet
Milestone
L2-WD-02
Development

No branches or pull requests
6 participants
@agl @equalsJeffH @jcjones @peteroupc @selfissued @nadalin