A security review finds that an untrusted server publishes an inputSchema with deeply nested anyOf and oneOf branches, and validating arguments against it ties up the client's validator for minutes. Which mitigation does the specification recommend?
Select an answer to reveal the explanation.
Short Explanation
A schema can be a weapon: nest enough anyOf branches and your validator chokes. So you put a fence around it with depth limits, subschema caps or a time budget. Don't believe that switching dialects makes the problem vanish.
Full Explanation
Composition keywords such as anyOf, oneOf, allOf and if/then/else, together with $defs, make schemas expressive but can be expensive to evaluate. The specification therefore says implementations SHOULD apply reasonable bounds, for example a maximum schema depth, a cap on the total number of subschemas, or a per-validation time budget, so that a malicious schema cannot act as a denial-of-service vector against the validator. The bounds work regardless of where the schema came from or which dialect it uses. Requiring a $schema keyword changes nothing about cost, because declaring a dialect does not disable composition keywords; 2020-12 and other dialects all support them. Converting to draft-07 is based on a false premise, since draft-07 also includes anyOf and oneOf, and a rewrite would not remove the nesting. Skipping validation for tools carrying readOnlyHint is unsafe twice over: annotations are untrusted hints unless the server is trusted, and a read-only tool still needs its inputs validated. Exam caveat: the specification also requires servers to validate all tool inputs, so both ends need sensible limits on schema processing. Operational check: run the validator against a deliberately deep composite schema and confirm it stops at the configured depth, subschema or time limit and reports an error.