Which `credential_ids` entry must have Cryptographic Holder Binding?

credential_ids is a non-empty array, and the Wallet selects one of the Credentials it references:

credential_ids: REQUIRED. Non-empty array of strings each referencing a Credential requested by the Verifier that can be used to authorize this transaction. The string matches the id field in the DCQL Credential Query. If there is more than one element in the array, the Wallet MUST use only one of the referenced Credentials for transaction authorization.

Those Credential Queries may carry different values of require_cryptographic_holder_binding, and I could not find a rule for that case. A Verifier that lists three acceptable Credentials with the flag set to false on one of them leaves a Wallet three conformant options: reject the whole request, treat that one Credential as unusable here and authorize against another, or select it and present it with Holder Binding regardless. I could not find text selecting between them, and Section 8.6 does not appear to have a step checking that an authorization came back, so a Verifier cannot tell which happened.

The third option is only available to some formats. For SD-JWT VC, B.3 line 4259 makes the unbound form permissive: an SD-JWT without the Key Binding JWT MAY be returned, so a Wallet may present it bound and satisfy 8.4. For W3C Verifiable Credentials, B.1 forbids that:

If require_cryptographic_holder_binding is set to true in the Credential Query, the Wallet MUST return a Verifiable Presentation of a Verifiable Credential. Otherwise, a Verifiable Credential without Holder Binding MUST be returned.

There the unbound form is mandatory, so no conformant presentation can carry the transaction data signature, and only the first two options remain.

The flag is load-bearing for this feature rather than incidental to it. Section 8.4:

This is achieved by signing the transaction data used for user authorization with the user-controlled key used for proof of possession of the Credential being presented as a means for user identification/authentication.

A Credential presented without Cryptographic Holder Binding has no such key, so it cannot carry what 8.4 requires of every Credential Format:

The Wallet that received the transaction_data parameter in the request MUST include a representation or reference to the data in the respective Credential presentation.

B.3.3 is the only text that addresses the combination:

Wallets MUST reject requests with transaction data types that have the require_cryptographic_holder_binding parameter set to false.

Read as intended, that rejects the request. It still does not seem to resolve the mixed array, because it names a transaction data type while require_cryptographic_holder_binding is a Credential Query member defined in Section 6.1, so I cannot tell which referenced query it means. B.3.3 is also scoped to SD-JWT VC, leaving the other formats without even that.

So: should the constraint apply to every Credential Query referenced by credential_ids, or only to the one the Wallet selects? I could not tell from the text which was intended.

Start with Sections 6.1, 8.4, and 8.6, then compare the format-specific rules in B.1 and B.3.3. Determine whether the holder-binding constraint applies to every Credential Query referenced by credential_ids or only the selected Credential, and document consistent normative wording for the affected formats.