You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
COSEAlgorithmIdentifier is defined as a long, but AuthenticatorAttestationResponseJSON.publicKeyAlgorithm is a long long. While RPs are likely based on 64-bit platforms, it seems unnecessary to require 64-bit signed integers when a 32-bit signed integer is sufficient. What is the reason for this deviation? Is it based on "common" JSON libraries that model numbers as 64-bit signed integers?
The text was updated successfully, but these errors were encountered:
Fixes#2065.
`AuthenticatorAttestationResponseJSON` was added in the L3 drafts, so
we can easily change
`AuthenticatorAttestationResponseJSON.publicKeyAlgorithm` to type
`long` (or `COSEAlgorithmIdentifier`) since L3 isn't formally released
yet. `AuthenticatorAttestationResponseJSON.publicKeyAlgorithm` is also
in output (covariant) position, so changing its type to be more
restrictive is even backwards compatible.
I support this change. As discussed in last weeks' call, ff you look at the COSE algorithm registration rules, it's the numbers outside the 16-bit spaces that are clearly outliers. There's no hint of ever going beyond 32-bit identifiers.
COSEAlgorithmIdentifier
is defined as along
, butAuthenticatorAttestationResponseJSON.publicKeyAlgorithm
is along long
. While RPs are likely based on 64-bit platforms, it seems unnecessary to require 64-bit signed integers when a 32-bit signed integer is sufficient. What is the reason for this deviation? Is it based on "common" JSON libraries that model numbers as 64-bit signed integers?The text was updated successfully, but these errors were encountered: