Usecases for value matching in DCQL

[leecam]

Issue to track use-cases for value matching in DCQL.

The payment use-cases requires value matching for performing SCA. In this scenario a webpage would like to confirm the user holds a certain credit card. Here the RP would pass the credit card number as a value that needs to be matched, to filter the results to that given card.

[paulbastian]

Any use case where I need to validate additional qualifications, e.g. employees need to prove their criminal record certificate to the employer. The employer already knows who you are, so he is interested in a credential matching a particular name.

[tlodderstedt]

A RP already knows the name of the user and wants to obtain further information, e.g. a prove of identity (through a mDL or PID). The wallet should ensure that only a matching credential is selected and presented. Otherwise, data from the wallet is disclosed that is useless and might pose a privacy issue.

This can be extended to generally filtering credentials in the wallet to ensure a high level of privacy preserving and disclosure of suitable data. Let's say the RP wants to obtain attestations of educational achievements for a certain domain (computer science only).

Another example would be to filter a credential by trust framework. The RP would specify the acceptable issuers or a symbolic name for the trust framework (e.g. "eIDAS QEAA providers"). This would ensure only credentials are considered that could be accepted by the RP.

[danielfett]

Making sure that the real_id claim is true might be a value matching use case.

[c2bo]

A lot of use-cases around education/qualification credentials would IMHO benefit from value matching - something where you already know certain things about the user (like the name) and want to get attestations about further qualifications etc. In those cases, giving a hint about expected values to the wallet/user would help to reduce the risk of sending data that does not match the expectation and might be denied/ignored by the RP (in which case it should not be sent).

I would currently envision this as something that is optional and could also be overruled by the user (e.g., names are not fully matching, but it's about the correct person) - best effort / hint. The feature would help users to make a better informed decision and avoid sending/leaking data when it's already clear that it would not fulfill the requirements of the RP.

[martijnharing]

The current text is a lot more stringent on what is expected. e.g. it says that claims SHOULD NOT be returned if they don't match. So when there is a request for "Martijn" for the first name value and I have a "MARTIJN" first name element, a very reasonable way of implementing the requirement is to just reject this request.
If instead the goal of value matching is to provide more of a hint but be very careful with actually rejecting a request based on values not matching, then it doesn't align well with the current text.

[Sakurann]

Making sure that the real_id claim is true might be a value matching use case.

very likely it is. Verifier has two entries in credential query: one with real_id = true and another one without and specify in credential_sets that the one with real_id = true is the priority, if it is present in the wallet.