It's sometimes possible to use an alternate encoding to get around security checks (CAPEC-267). While the JSON spec may be strict on what is valid, popular parsers don't necessarily conform perfectly .
My question is thus: what alternate encodings are allowed by the standard, and what ones are allowed by popular parsers? Of the alternate encodings that exist, how confident can we be that they can't be used in an attack? The specific attack I'm concerned with is avoiding a white- or black-list checking the json key names in untrusted input, but I'd be interested in hearing of other attacks possible through alternate encoding of JSON keys - for my benefit and that of others.
 For example, the spec states that key names are case sensitive. Golang's encoding/json package prefers case-sensitive matches but will fall back to case-insensitive key matching - see (json.Unmarshal()).
(Edit) Use case: I'm involved in developing a network-attached appliance. Normally it is controlled by the cloud; however, if it gets misconfigured that isn't possible - or if the end user does not configure their network in a way we can understand. Uptime is highly important to the customers, so I'm working on a mechanism whereby a "rescue" file is written to usb key by the end user and then plugged into the appliance. Some tasks, such as restarting particular processes, are deemed safe and so a signature isn't necessary.
Since I can't imagine every possible issue, there's also a provision for a JSON key whose value is shell commands - obviously far more dangerous. I have a blacklist blocking dangerous command keys like this unless a signature is present and valid. Currently, I'm simply doing a case-insensitive text search for each
"key_name" (including quotes, to reduce the chance of false positives), while the data is still encoded as json. As long as an attacker can't use something else in place of quotes or use some sort of encoding, I think my very simple blacklist will function well.
I originally planned to post to StackOverflow but decided this was a better fit. Apologies if that isn't so.