Make following the claim_sets order in the vp query recommended instead of mandatory

[martijnharing]

Issue created to discuss the open discussion that we deferred as part of the query language PR discussion.

According to the current language, the wallet is mandated to return the data elements as they are ordered in claim_sets. Since there should be no difference to the RP which of the options in claim_sets is returned, there is no necessity to mandate this behavior for the wallet. It should definitely be recommended to follow the order because the RP is expected to order the options according to the best privacy preserving option.

Some examples why the wallet may want to deviate:

• Request for [on_device_auth, portrait], where the on_device_auth element requires an external factor and the wallet could make a choice whether it can or it's a good option or use that external factor. The current language would not allow this.
• Request for [element_y, element_x] and [element_a, element_x] where the credential contains element_x and element_y. Returning the first element element of the array would result in returning more than required since element_x satisfies the request, but the current language requires to send element_x and element_y
• The RP makes a mistake in the order and puts [date_of_birth, age_over_21]. This will likely result in date_of_birth to be returned as default behavior, but I don't see a reason why we would prohibit the wallet to return age_over_21 in this scenario.
• Request for [age_over_50, date_of_birth], the wallet wants to return age_over_65 because it doesn't have age_over_50. At least for mDL a request for age_over_21 may be answered with age_over_xx with xx being 21 or higher.

Therefore the proposal is to change MUST to SHOULD to return the first element that can be returned from the claims_set.

[danielfett]

• Request for [on_device_auth, portrait], where the on_device_auth element requires an external factor and the wallet could make a choice whether it can or it's a good option or use that external factor. The current language would not allow this.

This can be covered by giving two options in credential_sets.

• Request for [element_y, element_x] and [element_a, element_x] where the credential contains element_x and element_y. Returning the first element element of the array would result in returning more than required since element_x satisfies the request, but the current language requires to send element_x and element_y

I don't understand this example. Why would element_x satisfy the request if x and y are required?

• The RP makes a mistake in the order and puts [date_of_birth, age_over_21]. This will likely result in date_of_birth to be returned as default behavior, but I don't see a reason why we would prohibit the wallet to return age_over_21 in this scenario.

It would require significant effort to automatically determine the most privacy-preserving way to respond to a request.

• Request for [age_over_50, date_of_birth], the wallet wants to return age_over_65 because it doesn't have age_over_50. At least for mDL a request for age_over_21 may be answered with age_over_xx with xx being 21 or higher.

The wallet should not return claims not requested by the verifier. It doesn't know what the verifier understands and it is probably safe to assume that the verifier knows enough about the basic credential structure to avoid the mistake of not listing one of the standard claims that might be useful.