Original text:
5.2. Where JSONPath is used as a part of a security mechanism, attackers <del> can attempt to evoke unexpected behavior, or take advantage of differences in behavior between JSONPath implementations. This also applies to underlying technologies such as UTF-8 (see RFC3629), the Unicode character set, and JSON.  A characteristic of JSON that can lead to varying results is the fact that JSON objects are unordered; therefore, the order in which results of a JSONPath query reflect the presence of JSON object members can vary with </del>  implementations. 

Reviewer comments:
See also . Fixes URL
I have read the latest draft of section 5.2 "Attacks on Security Mechanisms that Employ JSONPath" and I'm having trouble figuring out what it's saying and what would be useful for implementors. On consideration, I think the following is true. If the JSON text to which you're applying a JSONpath follows the rules of I-JSON [RFC7493] the results should be deterministic and repeatable for the same JSON text from one JSONpath implementation to another. On the other hand, if you have JSON with dupe object keys, or 300-digit numbers, or broken UTF16 surrogates, you really have no expectation of deterministic behavior. I think (do others agree?) that given I-JSON, conforming JSONpath implementations should be deterministic? Anyhow, I'd replace section 5.2 with text saying something like "If your security mechanism includes the use of JSONpath implementations, you should be aware that results will be nondeterministic and interoperation can fail if a JSON text you are processing includes constructs that are deprecated but allowed by [RFC8259]. Deterministic behavior can be expected for any JSON text conformant with [RFC7493].
Note that in URL, I didn't adopt the language above to describe certain constructs as "deprecated but allowed" by RFC 8259 since that RFC does not use the term deprecation. Please feel free to object to this in the PR.
It's been previously mentioned in the issues, but the draft should say something about the danger of attack from a query that triggers overflow in a recursive step. The JSONPath recursion operator, given how it's implemented in many implementations, is vulnerable to attack, in situations where a JSONPath expression is provided as a parameter. It's pretty obvious that some, perhaps even most, implementations would not be able to pass Google fuzzer, were that a scenario. Note that enterprises take the risk of vulnerability through recursion very seriously. In my opinion, some limits on recursion levels ought to be specified.
Interesting. Wouldn't such a stack overflow attack be bounded by the JSON document? I guess where an attacker can provide both the JSON document and the JSONPath, there is an opportunity for stack overflow. But there is a more general resource exhaustion attack if attackers are allowed to provide arbitrarily large JSON documents. I agree that JSONPath implementations may wish to defend themselves by imposing recusion limits, memory limits, etc., but I'm not sure I'd want to go as far as requiring specific limits in the spec.
I believe so, but as you also mention, the attacker could supply both. Or supply a document that exploits a JSONPath with a recursive operator. Of course, a hostile document raises more issues than for just JSONPath. Pull parsers also may exhibit recursion, Microsoft guards against that by limiting .Net JSON parser depth by default to 64. My own view is that in today's world, anything that suggests recursion should be flagged.
Ok, and based on the advice in URL on DOS attacks, I'll put together a PR to flag up the risk of a DOS attack due to recursion and see how that goes down.

Revised text:
5.2. Where JSONPath is used as a part of a security mechanism, attackers  <ins> can attempt to provoke unexpected or unpredictable behavior, or take advantage of differences in behavior between JSONPath </ins> implementations. <ins> Unexpected or unpredictable behaviour can arise from an argument with certain constructs described as unpredictable by RFC8259. Predictable behavior can be expected, except in relation to the ordering of objects, for any argument conforming with RFC7493. Other attacks can target the behaviour of underlying technologies such as UTF-8 (see RFC3629) and the Unicode character set. </ins>