openid / OpenID4VP

56 stars 19 forks source link

Is the behavior for DCQL array element selection with a values filter and selective disclosure on a higher level underspecified? #312

Open markuskreusch opened 5 days ago

markuskreusch commented 5 days ago

Scenario

Given the credential request

{
  "credentials": [
    {
      "id": "address-credential",
      "format": "vc+sd-jwt",
      "claims": [
        {
          "id": "zipcode",
          "path": [
            "addresses",
            null,
            "zipcode"
          ],
          "values": [
            "99999"
          ]
        },
        {
          "id": "street",
          "path": [
            "addresses",
            null,
            "street"
          ],
          "values": [
            "Small Street"
          ]
        }
      ]
    }
  ]
}

the credential claims

{
  "addresses": [
    {
      "street": "Large Street",
      "zipcode": "99999"
    },
    {
      "street": "Small Street",
      "zipcode": "11111"
    }
  ]
}

and the two addresses-arrays elements each as a disclosure. This means if an array element is disclosed, all contained values are disclosed as a whole because there is no SD possible on a per-claim basis in the array elements.


Questions

Wallets perspective: Is a credential returned and what is returned in the credential (disclosed)?

Verifier perspective: Which presentations will match the query, which will not?


Please think about this scenario before expanding the following section to see if there are differences in the interpretation of the standard before reading my ideas.

My understanding The verifier perspective is different from the wallet perspective because of the "SHOULD NOT return the claim" requirement when handling values for wallets. Because of this a wallet could always return something that does not match the values. For the scenarios given this is not that useful for a verifier though, because the verifier could not rely on a well-defined specific behavior and implementation. In addition, a verifier needs a defined way to check if a presentation matches a DCQL query. This query would make it impossible to fulfill the values conditions for "street" and "zipcode" both at the same time. I would expect, that no data is sent in this case by the wallet, but I am not sure if this actually follows from the spec or is more an assumption made by me. In addition, if there would be a "Small Street - 99999" entry it should be disclosed. Detecting this and implementing this is non-trivial, - I suppose - way more complex than intended, hard to test and error-prone. The complexity follows from the fact that an implementation must be able to handle all possible combinations of SD nesting, claims queries with values and the resulting interdependencies. A clear algorithm or formal definition of the claims sets + claims query matching process together with disclosure determination should be defined to have something predictable. Otherwise, I fear that differing implementations will develop.
charsleysa commented 5 days ago

My understanding is that without claim sets in the query, all claims specified are required. The values property in the claim queries is a constraint and all constraints for the specified claims must be satisfied.

So the query in your example would result in neither address satisfying all constraints therefore making this credential ineligible.