DCQL - can a verifier request selectively disclosable fields that may or may not be present in the VC

[MattiasLass]

Can a DCQL query be constructed for the following scenario?

• An mdoc document type with around 50-ish data elements out of which around 40 are optional (issuers may or may not include them in the VC).
• This document type is used by tens of different issuers. Each issuer could use a different combination of optional fields.
• Furthermore, even within one issuer different combinations could be used depending on what data on the holder of the document the issuer has available. This is all to say that there are essentially unlimited amount of combinations - a combinatorial blowout.
• The verifiers need to request all the data that the holder has available.

Based on section 6.4.1 the answer seems to be no. Am I correct or have I overlooked something?

• If the verifier provides no claims query, then the wallet must not present any data as all data elements in mdoc format seem to be selectively disclosable. Specification states: "The Wallet MUST return only the claims that are mandatory to present"
• If verifier adds all data elements to the claims query the wallet can only respond if it has all the claims available: "If the Wallet cannot deliver all claims requested by the Verifier according to these rules, it MUST NOT return the respective Credential."
• One idea on how to solve this would be to add different combinations of claims_sets to the query ordering them by the amount of information requested. However, this idea is not workable due to the combinatorial blowout

While the scenario I've described here is quite specific, if my assumptions are correct, it seems to point to larger issue that DCQL does not work well with optional data if those fields are selectively disclosable. In previous drafts, I believe, it was possible to request credentials solely by doctype/namespace.

[babisRoutis]

Hi @MattiasLass

I believe that it is pretty valid for a verifier to query for attributes that are optional (during issuance of course).

The Wallet MUST return only the claims that are mandatory to present

An attribute that is mandatory to present is :
a) An attribute that the verifier has requested AND
b) There is a value for this attribute (Either because it's mandatory or because it is optional and Issuer provided a value).

If the Wallet cannot deliver all claims requested by the Verifier according to these rules, it MUST NOT return the respective Credential.

Wallet must reply with all attributes requested by the verifier for which there is a value (Those are the mandatory and any optional for which Issuer provided a value).

In your case, the verifier may explicitly query for all optional attributes.

Perhaps the specification should clarify this.

[Sakurann]

WG discussion:

• There was a clarification brought up that the intent of the sentence "If the Wallet cannot deliver all claims requested by the Verifier according to these rules, it MUST NOT return the respective Credential." is that "Regardless of whether those claims are not present in the credential or not, if the wallet cannot return all mandatory credentials, it MUST NOT return the requested Credential". "Wallet must reply with all attributes requested by the verifier for which there is a value" is not how specification is intended.
• we discussed claims with the similar intent but different semantics, like same first name being expressed using local alphabet (chineese characters for example) and latin. and a travel use-case where first name in latin is the one legally required/recognized.

[Sakurann]

Personal opinion:

If the verifier provides no claims query, then the wallet must not present any data as all data elements in mdoc format seem to be selectively disclosable. Specification states: "The Wallet MUST return only the claims that are mandatory to present"

You're right. If the verifier provides no claims query, the wallet only returns all non-selectively disclosable claims. The relevant text in the spec is "Wallets MUST NOT send selectively disclosable claims that have not been selected according to the rules below." and “If claims is absent, the Verifier is requesting no claims that are selectively disclosable; the Wallet MUST return only the claims that are mandatory to present (e.g., SD-JWT and Key Binding JWT for a Credential of format IETF SD-JWT VC).”

(i guess the spec does not exactly say what the wallet does when the claims is absent and all the claims are selectively disclosable, but guess the wallets should logically deduct that it should not return the credential as opposed to returning a credential with zero claims, just to reveal that is has a credential)

If verifier adds all data elements to the claims query the wallet can only respond if it has all the claims available: "If the Wallet cannot deliver all claims requested by the Verifier according to these rules, it MUST NOT return the respective Credential."

Yes, as clarified above.

One idea on how to solve this would be to add different combinations of claims_sets to the query ordering them by the amount of information requested. However, this idea is not workable due to the combinatorial blowout

true. for privacy reasons, intentionally, the specification does not support a query a) present me all the claims in the credential (regardless whether they are selectively disclosable or not), b) give me this claim if you have it, but if you don't have it no need to return it.

so in my personal opinion, a lot should be solved by ecosystems/use-cases being intentional when defining at defining credential schemas/rulebooks about which claims are selectively disclosable and what is mandatory to be issued. and if the verifier just wants all the claims in the credential for the sake of it, without understanding the intent of those claims being optional/selectively disclosable, then that verifier should not get user's information. and it's good to have a query language that protects the user from such verifiers.

some other related meta thoughts. mandatory/optional for the issuer to issued does not directly translate into mandatory/optional to be presented to the verifier. and whether the issuer made a specific claim selectively disclosable or not has more direct relationship to mandatory/optional to be presented to the verifier.

[fkj]

The verifiers need to request all the data that the holder has available.

Can you explain a bit more what the use case for this would be? For privacy reasons it is a goal of the working group to avoid allowing a query to "request all data" in the general case.

We are aware that there are legitimate use cases which have large amounts of optionality, e.g. with addresses that can have different components/claims across jurisdictions and where you want to ask for "an address from any jurisdiction."

One idea on how to solve this would be to add different combinations of claims_sets to the query ordering them by the amount of information requested. However, this idea is not workable due to the combinatorial blowout.

From a specification standpoint, this idea might be workable for most "intended" use cases. It should be easy to generate all of the combinations from some internal representation of your query, and there are no defined length limits on queries. That being said, I understand that this is not an ideal developer experience and that some implementations may restrict query sizes for various reasons.

What I would suggest to solve this issue is to extend DCQL with some new syntax that allows verifiers to compress this kind of query without adding any expressivity to the language. This should be possible by adding the ability to combine claim_sets conjunctively.

For instance, consider the (simplified but representative IMO) case where you want ALL OF the following:

1. A name written with some local character set (e.g. Danish) OR a latinized/ASCII-fied version of the name
2. A "standard" driver's license "right to drive a car" OR a local variation that allows you to drive e.g. just automatic cars
3. An address consisting of a road name and a municipality OR an address consisting of a road name and a state

With the current DCQL syntax, you would need 8 claims sets (i.e. the query combinatorially explodes):

{
  "credentials": [
    {
      "id": "pid",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [ "https://credentials.example.com/identity_credential" ]
      },
      "claims": [
        {"id": "a", "path": ["name"]},
        {"id": "b", "path": ["name_latinized"]},
        {"id": "c", "path": ["road"]},
        {"id": "d", "path": ["municipality"]},
        {"id": "e", "path": ["state"]},
        {"id": "f", "path": ["right_to_drive"]},
        {"id": "g", "path": ["right_to_drive_automatics"]}
      ],
      "claim_sets": [
        ["a", "c", "d", "f"],
        ["a", "c", "d", "g"],
        ["a", "c", "e", "f"],
        ["a", "c", "e", "g"],
        ["b", "c", "d", "f"],
        ["b", "c", "d", "g"],
        ["b", "c", "e", "f"],
        ["b", "c", "e", "g"]
      ]
    }
  ]
}

What I would propose is introducing new DCQL syntax allowing something like this to express the same query:

{
  "credentials": [
    {
      "id": "pid",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [ "https://credentials.example.com/identity_credential" ]
      },
      "claims": [
        {"id": "a", "path": ["name"]},
        {"id": "b", "path": ["name_latinized"]},
        {"id": "c", "path": ["road"]},
        {"id": "d", "path": ["municipality"]},
        {"id": "e", "path": ["state"]},
        {"id": "f", "path": ["right_to_drive"]},
        {"id": "g", "path": ["right_to_drive_automatics"]}
      ],
      "claim_sets": [
        [
          ["a"],
          ["b"]
        ],
        [
          ["c", "d"],
          ["c", "e"]
        ],
        [
          ["f"],
          ["g"]
        ]
      ]
    }
  ]
}

The claim_sets above should be read (name OR name_latinized) AND ((road AND municipality) OR (road AND state)) AND (right_to_drive OR right_to_drive_automatics).
In this small example with only 8 options, the proposed syntax is not that much shorter, but I hope it's obvious that the pattern will scale much better.

I believe that only 1 layer of conjunction is necessary to express any query and that this extension to DCQL does not change the expressivity of the language.

[MattiasLass]

Thank you for the responses. @Sakurann 's comment captures well what the issue is about.

some other related meta thoughts. mandatory/optional for the issuer to issued does not directly translate into mandatory/optional to be presented to the verifier. and whether the issuer made a specific claim selectively disclosable or not has more direct relationship to mandatory/optional to be presented to the verifier.

Agreed. Something related that I was not explicit about in my original question: I believe the issue is specific to attestations issued in the mdoc format. Going by ISO/IEC 18013-5 it seems that all mdoc data elements (claims) must be selectively disclosable. Or in other words, issuers have no way of defining which claims are mandatory or optional to present for attestations in the mdoc format. Although given the number of different standards (and the number of different editions for those standards) governing mdocs, I'm not completely confident in my interpretation.

Meanwhile, we have devised two workarounds:

• Pivoting away from mdocs towards SD-JWT VCs for which the issuers can define which claims are selectively disclosable.
• The issuer could use empty values for all the optional elements they don't have information on. For example instead of leaving the data element uninitialized they would add it as an empty string. Technically, all the elements are present: the verifier could request them all and the wallet can satisfy the request. This is messy, introduces ambiguity, has poor experience for both users and developers, but would more or less match the behavior we require.

Can you explain a bit more what the use case for this would be? For privacy reasons it is a goal of the working group to avoid allowing a query to "request all data" in the general case.

Without going into specifics, the use case is essentially "guaranteed" holder identification without having any global identifiers (identity matching based on a broad set of holder's attributes). So a use case antithetical to privacy.

For what it's worth, I understand the goal/intent behind the approach the working group has chosen, and personally I'm sympathetic towards it. However, of its efficacy I'm not convinced of. As I've explained above, the issuer's can still force the oversharing of claims if they so require/wish.

[fkj]

Without going into specifics, the use case is essentially "guaranteed" holder identification without having any global identifiers (identity matching based on a broad set of holder's attributes). So a use case antithetical to privacy.

Yeah, this is a case where we really do want to allow verifiers to request whatever they need.
It seems unlikely that you would be able to convince every issuer you might need information from to do anything in particular for this use case, but maybe you are only targeting a specific jurisdiction/region?

For what it's worth, I understand the goal/intent behind the approach the working group has chosen, and personally I'm sympathetic towards it. However, of its efficacy I'm not convinced of. As I've explained above, the issuer's can still force the oversharing of claims if they so require/wish.

The intention is not to completely forbid verifiers from requesting all claims, but to make it inconvenient enough that everyone will not default to doing so instead of actually thinking through what they need and writing a query for that. The balance is hard to hit and will probably need to be reviewed as new use cases are brought to our attention.
I still think that an approach like I suggested above will make it inconvenient enough to request "all claims that may exist" that it will not be the default, but not so inconvenient that it is impossible if you really do need it.