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.

[martijnharing]

• 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.

It could, but this means that the RP has to make a change to the request. This means that the RP at request time has to be aware of the fact that in order to allow wallets to deviate from the preferred order, it should therefore not use the claim_sets element but use different credentials. We are therefore making things more complicated for the RP, because even though from an RP perspective both options are equivalent, it still has to think how a wallet may deal with them.

• 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?

Following the requirements in the specification, you have to return the first element that you can return. In this example this would be element_y for the first claims_set and element_x for the second claims_set. However, returning element_x would also satisfy both claim_sets and this should therefore be allowed.

• 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.

Agreed, so this shouldn't be logic that we are requiring wallets to implement, but I don't see why we have to forbid wallets from implementing it if they want to.

• 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.

The current mDL specification has logic that allows returning an age_over_25 element when age_over_21 is requested. Since different countries around the world have different age requirements, there is currently not a mandated set of age_over_xx elements. Note that this is not a generic mdoc feature, but specific to document types like mDL, so it may not be a great example.

---

All these examples are edge-cases to some extent, but there are probably more edge cases like these that we may want to support if it comes at no cost. I currently don't see a reason why we need to mandate the wallet to follow the order, given that we do recommend the wallet to follow it (and therefore allow a simple implementation).
If the only reason to actually mandate the order is such that it would support the "conditional element" function, then I think it's easier and cleaner to keep that as a specific function, then to not have that specific function but having the risk of making UX worse by mandating the claim_sets order for all requests.

[danielfett]

• 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?

Following the requirements in the specification, you have to return the first element that you can return. In this example this would be element_y for the first claims_set and element_x for the second claims_set. However, returning element_x would also satisfy both claim_sets and this should therefore be allowed.

I still don't quite get it, I suspect a misunderstanding somewhere. The rule is to return the first set of claims that the wallet can return. So if your request is this:

"claim_sets": [ ["el_x", "el_y"], ["el_a", "el_x"] ]

and if the credential contains both el_x and el_y, the Wallet will return el_x and el_y.

[martijnharing]

• 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?

Following the requirements in the specification, you have to return the first element that you can return. In this example this would be element_y for the first claims_set and element_x for the second claims_set. However, returning element_x would also satisfy both claim_sets and this should therefore be allowed.

I still don't quite get it, I suspect a misunderstanding somewhere. The rule is to return the first set of claims that the wallet can return. So if your request is this:

"claim_sets": [ ["el_x", "el_y"], ["el_a", "el_x"] ]

and if the credential contains both el_x and el_y, the Wallet will return el_x and el_y.

But in this case, returning only el_x actually satisfies both of the arrays in the claim_sets, therefore returning just el_x satisfies the request from the RP (and be sufficient to satisfy the use case). However, the current processing logic mandates returning el_x and el_y even though el_x would be sufficient.

Edit: just noted that in the quoted text the order of the elements in the array was changed, which nullifies the argument. The intended example was if the RP would say: "claim_sets": [ ["el_y", "el_x"], ["el_a", "el_x"] ].

[Sakurann]

"claim_sets": [ ["el_x", "el_y"], ["el_a", "el_x"] ]

But in this case, returning only el_x actually satisfies both of the arrays in the claim_sets, therefore returning just el_x satisfies the request from the RP (and be sufficient to satisfy the use case).

How did you come to that conclusion? The example claim_sets "claim_sets": [ ["el_x", "el_y"], ["el_a", "el_x"] ] means that el_x and el_y, or el_a and el_x needs to be present. If el_x alone satisfies the request, claim_sets would look like "claim_sets": [ ["el_x", "el_y"], ["el_a", "el_x"], ["el_x"] ] , which would logically makes sense, where RP says "wallet, I really need el_y and el_a, in addition to el_x, but if you don't have those, give me el_x and i will use other processes to get el_y and el_a"

[Sakurann]

WG discussion.

• testing is a concern if this is not mandatory.
• DHS Real ID compliance needs "mandatory". but it is not clear if Real ID is a legit use-case. and if it is not, not mandatory is ok.
• one suggestion: expected behavior is "mandatory", but if the wallet has a very strong reason to deviate, it is allowed to?

[awoie]

WG discussion.

• DHS Real ID compliance needs "mandatory". but it is not clear if Real ID is a legit use-case. and if it is not, not mandatory is ok.

we can also agree that the DHS Real ID use case (or required if present) can be covered by issuer selection / query by value and we are good.

[martijnharing]

Any updates on this topic?

The language at the beginning of 6.3.1.1 currently explicitly says "the wallet MUST return the first option that it can satisfy". Any objections to making a PR for changing this to SHOULD?