Add note about use of floating point in extensions passed through that clients do not recognize #1307
Conversation
…t clients do not recognize
|
My concern was that if different clients use different integer thresholds for passing through unrecognized extensions (and neither WebAuthn nor RFC 7049 specify a default threshold), then that will hinder bit-for-bit comparison or hashing of CTAP2 messages with the same content. This concern is not relevant if the only purpose of canonicalizing CTAP2 messages (both in WebAuthn and elsewhere) is, as the CTAP2 protocol states, "[t]o reduce the complexity of the messages and the resources required to parse and validate them", and not also to enable bit-for-bit comparison or hashing of CTAP2 messages with semantically equal content. My concern is not whether clients will convert some floating-point values to integers when they pass through unrecognized extensions, but at what integer threshold they do so. |
|
@peteroupc I don't think that should be a problem, at least for WebAuthn ceremonies. The RP has no direct control of the exact bytes being sent to the authenticator anyway (because the client can add random extra stuff to the CollectedClientData, for example), so you can't rely on the same input producing the exact same outputs even with deterministic signatures. |
|
If that's the case, then there should be an additional note that different clients might choose different integer thresholds for converting floating-point values to integers, and that this is not a problem because canonicalized CTAP2 messages generated by the protocol are not meant to be compared bit-for-bit with each other (either directly or via hash codes). This is unlike other protocols like DKIM and XML Signature, which do use canonicalization for bit-for-bit data comparison. Perhaps the CTAP2 protocol can also clarify that the canonical form it specifies is not intended to enable bit-for-bit comparisons either. |
index.bs
Outdated
| Note that the numeric conversion rules have the consequence that | ||
| when a client passes through an extension it does not recognize, | ||
| if the extension uses floating point values, | ||
| [=authenticators=] need to be prepared to receive those values as [=CBOR=] integers | ||
| when the floating point values used happen to be integers, | ||
| should the [=authenticator=] want the extension to always work without actual [=client=] support for it. |
There was a problem hiding this comment.
This is all one long sentence -- suggested rewrite (plus I'd move this Note to under line 4834 where numeric conversion is discussed):
Note: Due to Javascript's numeric conversion rules, any floating point values may be converted to integers. Thus, [=authenticators=] need to be prepared to receive those values as either [=CBOR=] floating-point or as [=CBOR=] integers. If this is not feasible, the extension may be designed with the [=client=] performing any necessary value type conversions.
|
For your information: See cbor-wg/CBORbis#117, which modifies the CBOR revision to include defaults for encoding JSON numbers as CBOR. |
Fixes #1273
Preview | Diff