Re: [Json] JSON and int64s - any change in current best practice since I-JSON

[Anders Rundgren <[e-mail]>]

On 2024-01-16 21:04, Rob Sayre wrote:
> To suggest a positive path forward:
> 
> https://es.discourse.group/t/cbor-js-and-the-cbor-object/1759 <https://es.discourse.group/t/cbor-js-and-the-cbor-object/1759>
> 
> That is the better fix in my opinion, because BigInts are not the only problem.

Indeed. If you want to "sign JSON" you will (using IETF standards) have wrap the JSON data in Base64Url.
By building on the CBOR Deterministic Encoding (CDE) standard in the workings (https://datatracker.ietf.org/doc/draft-ietf-cbor-cde/), you can sign serialized CBOR "as is".
You may try a signature scheme on-line which uses CDE: https://test.webpki.org/csf-lab

With the anticipated arrival of Post-Quantum Cryptography (PQC) requiring massive amounts of binary data, CBOR will prove to be a good choice.

Personally, I find the ability to represent CBOR as text as a complement to binary quite useful: https://cbor.me/.

Anders


> 
> JavaScript has precise number types now (Uint8Array etc etc), and CBOR can represent these well.
> 
> Browsers also have another serialization method called "Structured Clone", which does a lot more than JSON:
> https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm <https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm>
> 
> I mention this one to show that CBOR is totally tractable here.
> 
> People often try to adjust JSON or write schema systems to deal with these issues, but CBOR is a better way forward (imo) because it fixes many issues all at once.
> 
> thanks,
> Rob
> 
> 
> On Tue, Jan 16, 2024 at 9:09 AM Rob Sayre <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     Hi,
> 
>     I had the same thought as Pete a while back, but found that JS engines actually bar you from encoding these as JSON:
> 
>      > let two_55th = BigInt(2) ** BigInt(55)
>      > two_55th
>     36028797018963968n
>      > JSON.stringify(two_55th)
>     VM189:1 Uncaught TypeError: Do not know how to serialize a BigInt
>          at JSON.stringify (<anonymous>)
>          at <anonymous>:1:6
> 
>     I can't find the reference for this one, but the reason they gave was that /adding/ support broke too much running code, even though it would be easy to add, since the second command there sure does stringify that number.
> 
>     I think the issue was that too many programs rely on JSON.parse returning a JavaScript Number type (distinct from BigInt), so you'll run into problems like this TypeError:
> 
>      > let my_plain_number = JSON.parse("42")
>      > my_plain_number
>     42
>      > my_plain_number + two_55th
>     VM429:1 Uncaught TypeError: Cannot mix BigInt and other types, use explicit conversions
>          at <anonymous>:1:17
> 
>     So, I-JSON remains correct.
> 
>     thanks,
>     Rob
> 
> 
>     On Tue, Jan 16, 2024 at 7:11 AM Tim Bray <[e-mail] <mailto:[e-mail]>> wrote:
> 
>         Carsten is right. You probably wouldn’t use JSON if you weren’t likely to be interchanging it with other parties over the network, other parties you don’t control.  For quite a while, it has been quite likely that the other parties use JavaScript, and the limits I-JSON places on numbers are a result of this fact. This fact isn’t going away AFAIK.
> 
>         On Jan 16, 2024 at 6:22:31 AM, Carsten Bormann <[e-mail] <mailto:[e-mail]>> wrote:
>>         Hi Pete,
>>
>>>         On 2024-01-16, at 14:46, Pete Cordell <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>         Hi All,
>>>
>>>         In I-JSON it recommends encoding 64-bit values using a string because many parsers (in particular browsers) always represent numbers using floating point doubles.
>>
>>         (many parsers == JavaScript’s JSON.parse)
>>
>>>         We're over 8 years on from I-JSON and browsers now support things like BigInt.
>>
>>         I’d say the problem wasn’t so much the absence of BigInt, but the fact that JavaScript’s JSON.parse always parses JSON numbers as a JavaScript Number, which is exact only inside (-2**53, 2**53).
>>
>>>         Therefore, I'd be interested to hear if there is any community change of opinion on how 64-bit ints should be handled in JSON.
>>
>>         I think we’d first need wide support for a new equivalent to JSON.parse in JavaScript.
>>
>>         Grüße, Carsten
>>
>>         _______________________________________________
>>         json mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/json <https://www.ietf.org/mailman/listinfo/json>
>         _______________________________________________
>         json mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/json <https://www.ietf.org/mailman/listinfo/json>
> 
> 
> _______________________________________________
> json mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/json