Lack of clarity regarding Numbers in the Abstract Data Model

[jonnycrunch]

I've finally unraveled the problems regarding representing numbers in the Abstract Data Model and we will need to discuss this more. While we currently don't have properties in the DID document that rely on numbers, we haven't yet gotten to consensus regarding how to unambiguously represent them in the abstract data model and this will lead to errors in implementations especially across core representations.

In particular, JavaScript number system treats all numbers as floating point, which may result in silent loss of precision in decoding integers with more than 53 significant bits.

In comparison, a CBOR-based core representation of the DID document could represent floating-point numbers in any of the three formats (half-precision, single-precision, and double-precision).

In the CBOR representation section I attempted to constrain the model to only double-precision even for integral values. Despite this we still have a disconnect with the CBOR able to represent 64 bits of significance compared to JSON's 53 bits.

[rhiaro]

This is a duplicate of #361 but adds important commentary. Can I suggest merging them?

[jonnycrunch]

move to #361