Input validation requires resource limits but names none

Section 14.13, Parsing of untrusted inputs, sets the requirement:

Wallets MUST treat all incoming requests as untrusted input. To mitigate injection and resource exhaustion attacks, Wallets MUST implement input validation on the Authorization Request and its enclosed DCQL query.

The steps beneath it are introduced at SHOULD level, "Wallets SHOULD at least implement the following steps:", and the one addressing resource exhaustion names no quantity:

Apply resource limits: Enforce maximum length restrictions on strings, maximum depths for nested objects, and maximum item counts for arrays within the query.

Searching the document for any other sentence stating a maximum or an upper bound, I found none. The only other size-related remarks are informative ones explaining that a response can exceed redirect URL length, which is why direct_post exists.

So two Wallets can choose different limits and both conform, and the same request bytes are accepted by one and refused by the other with every element of the request conformant.

The Verifier cannot diagnose that. Section 8.5's invalid_request conditions are four specific situations, none about limits, and the inherited definition in RFC 6749 covers a request that "is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed". A well formed request that is merely too large for one Wallet is none of those. That leaves error_description, which is free text, so there is no machine-readable signal.

To be clear about what this is not asking: not schema validation. #748 records the working group deciding against defining a JSON schema, with reasons, and ignoring unknown properties is the right call. Nor does this dispute that the requirement in Section 14.13 applies to the whole request rather than being narrowed by the list of steps beneath it.

The narrower question is whether the requirement can be met in an interoperable way as written. Should there be a floor that every Wallet must accept, or should the limits be explicitly profile-defined? And either way, is an error code needed for a request that exceeds a Wallet's limits?

Read Section 14.13, Section 8.5, and the inherited RFC 6749 definition of invalid_request. Review issue #748 for the schema-validation decision, then determine whether the specification should define a minimum accepted limit or profile-defined limits, and whether exceeding them needs a machine-readable error. Done means a specific resolution can be adopted in the relevant normative text.