Value matching clarifications

[davidz25]

I'm implementing DCQL right now (draft 24) and it's not clear to me from the spec how to implement value matching. Some observations

• The standard says about values that it's "An array of strings, integers or boolean values that specifies the expected values of the claim." ... however it goes together with a path so the value to compare against might indeed be an object (e.g. "path": ["address"]) where address is an object with street_address, postal_code etc elements. Why don't we allow values to also include objects?

• For ISO mdoc, it's not at all clear how to match. Yes, trivial cases where the data element is a tstr or boolean (e.g. major type 7) or integers (major type 0 and 1)... but what about things like full-date (which according to RFC 8943 is a string with tag 1004), for example, should we automatically drop all tags? In that case you can use e.g. values = ["2025-02-11"] to match a full-date. I think we should have concise language for the implementer here and not have them guess what the intent is.

[c2bo]

The whole topic of value matching is still something that will need a bit more work imho and where there is ongoing discussion in the WG. The initial proposal by @danielfett also included more advanced options like applying transformations to claims (similar to https://openid.bitbucket.io/ekyc/openid-connect-advanced-syntax-for-claims.html#name-defining-transformed-claims).

I agree that we probably need to be more explicit on data types and especially how matching works for formats not based on JSON serialization.

On-going discussion on value matching: #307