There has been some prior discussion in the different WGs on advanced query language features with the main historic discussion point being value matching: Value matching as defined in OpenID4VP (see https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-1_0-wg-draft.html#selecting_claims) allows a Verifier to request a specific claim and provide a hint on the expected value.
There has been some discussions around what exactly should be normatively said around value matching and how to best make it work for different wallet architectures etc. while preventing all potential leakage of information.
Current text in OpenID4VP on value matching:
When a Claims Query contains a restriction on the values of a claim, the Wallet SHOULD NOT return the claim if its value does not match according to the rules for values defined in Section 6.3, i.e., the claim should be treated the same as if it did not exist in the Credential. Implementing this restriction may not be possible in all cases, for example, if the Wallet does not have access to the claim value before presentation or user consent or if another component routing the request to the Wallet does not have access to the claim value. It is ultimately up to the Wallet and/or the End-User if the value matching request is followed. Therefore, Verifiers MUST treat restrictions expressed using values as a best-effort way to improve user privacy, but MUST NOT rely on it for security checks.
with these privacy considerations:
When using DCQL values to match the expected values of claims, the fact that a claim within a certain Credential matched a value or did not match a value might already leak information about the claim value. Therefore, Wallets MUST take precautions against leaking information about the claim value when processing values. This SHOULD include, in particular:
- ensuring that a Verifier, in the response, cannot distinguish between the case where an End-User did not consent to releasing the Credential and the case where the claim value did not match the expected value, and
- preventing repeated or "silent" requests leaking data to the Verifier without the user's consent by ensuring that all requests, even if no response can be sent by the Wallet due to a values mismatch, require some form of End-User interaction before a response is sent.
In both cases listed here, it needs to be considered that returning an error response can also leak information about the processing outcome of values.
More generally speaking, there have also been discussions on more advanced syntax in the query language with one such example being value in array (e.g., specific country in nationalities array)
There has been some prior discussion in the different WGs on advanced query language features with the main historic discussion point being value matching: Value matching as defined in OpenID4VP (see https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-1_0-wg-draft.html#selecting_claims) allows a Verifier to request a specific claim and provide a hint on the expected value.
There has been some discussions around what exactly should be normatively said around value matching and how to best make it work for different wallet architectures etc. while preventing all potential leakage of information.
Current text in OpenID4VP on value matching:
with these privacy considerations:
More generally speaking, there have also been discussions on more advanced syntax in the query language with one such example being value in array (e.g., specific country in nationalities array)