> Its primary intended use is in cryptographic authentication contexts, particularly ones where JSON is used as a human-friendly alternative representation of d

> Its primary intended use is in cryptographic authentication contexts, particularly ones where JSON is used as a human-friendly alternative representation of data in a system which otherwise works natively in a binary format. The author might care to take a look at canonical S-expressions, a format from the 90s which attempted to do the same thing for many of the same reasons, and has the advantage of being rather more elegant. E.g: { "s:string":"s:Hello, world!", "s:binary":"b64:SGVsbG8sIHdvcmxk", "s:integer":"i:42", "s:float":42.0, "s:timestamp":"t:2016-11-02T02:07:30Z" } could be: (string "Hello, world!" binary [b]|SGVsbG8sIHdvcmxk| integer [i]"42" float [f]"42.0" timestamp [t]"2016-11-02T02:07:30Z") Which is a perfectly valid encoding, but can use the canonical encoding (useful for cryptographic hashes): (6:string13:Hello, world!6:binary[1:b]13:Hello, world!7:integer[1:i]2:425:float[f]4:42.09:timestamp[1:t]20:2016-11-02T02:07:30Z) Which can be encoded for transport as: {KDY6c3RyaW5nMTM6SGVsbG8sIHdvcmxkITY6YmluYXJ5WzE6Yl0xMzpIZWxsbywgd29ybGQhNzpp bnRlZ2VyWzE6aV0yOjQyNTpmbG9hdFtmXTQ6NDIuMDk6dGltZXN0YW1wWzE6dF0yMDoyMDE2LTEx LTAyVDAyOjA3OjMwWik=} Granted, 'elegance' is in the eye of the beholder, but I like it. I also think that there's a deeper concern with any shallow notion of types. An application doesn't care so much about 'some integer' as it does about 'a valid integer for this domain,' and that concern is what leads to schemas and profiles and things like that. Just encoding the machine type of a value is insufficient: one has to encode the domain type, which means conveying the domain, which means assuming some sort of shared knowledge.