[c2bo]

Closes #718

Should this be added to 1.0 errata?

[brentzundel]

Discussed in group: @c2bo will attempt to rephrase.

[jogu]

One extra complication is that we should at least be clear how this dcql query is processed:

{
  "credentials": [
    {
      "id": "my_credential",
      "format": "mso_mdoc",
      "meta": {
        "doctype_value": "org.iso.18013.5.1.mDL"
      },
      "claims": [
        {
          "id": "age_over_18",
          "path": [
            "org.iso.18013.5.1",
            "age_over_18"
          ]
        },
        {
          "id": "age_in_years",
          "path": [
            "org.iso.18013.5.1",
            "age_in_years"
          ]
        },
        {
          "id": "age_birth_year",
          "path": [
            "org.iso.18013.5.1",
            "age_birth_year"
          ]
        },
        {
          "id": "birth_date",
          "path": [
            "org.iso.18013.5.1",
            "birth_date"
          ]
        }
      ],
      "claim_sets": [
        [
          "age_over_18"
        ],
        [
          "age_in_years"
        ],
        [
          "age_birth_year"
        ],
        [
          "birth_date"
        ]
      ]
    }
  ]
}

In particular in the case where the credential has both age_in_years and age_over_19 (but not age_over_18) which claim is it intended the wallet returns? (I guess a similar question may arise in the ISO 18013-5 query language too, I'm not sure how that handles it but we may want to handle it in a similar/the same way for the sake of everyone's sanity)

[c2bo]

If the wallet supports the matching of age_over_18 to age_over_19 with the logic introduced by this PR, then that is the first option in claim_sets that matches and should be returned imho.

[jogu]

So semantically we'd treat it as equivalent to requesting all the age_over_xx values? i.e.

"credentials": [
    {
      "id": "my_credential",
      "format": "mso_mdoc",
      "meta": {
        "doctype_value": "org.iso.18013.5.1.mDL"
      },
      "claims": [
        {
          "id": "age_over_18",
          "path": [
            "org.iso.18013.5.1",
            "age_over_18"
          ]
        },
        {
          "id": "age_over_19",
          "path": [
            "org.iso.18013.5.1",
            "age_over_19"
          ]
        },
...
        {
          "id": "age_over_98",
          "path": [
            "org.iso.18013.5.1",
            "age_over_98"
          ]
        },
        {
          "id": "age_over_99",
          "path": [
            "org.iso.18013.5.1",
            "age_over_99"
          ]
        },
        {
          "id": "age_in_years",
          "path": [
            "org.iso.18013.5.1",
            "age_in_years"
          ]
        },
        {
          "id": "age_birth_year",
          "path": [
            "org.iso.18013.5.1",
            "age_birth_year"
          ]
        },
        {
          "id": "birth_date",
          "path": [
            "org.iso.18013.5.1",
            "birth_date"
          ]
        }
      ],
      "claim_sets": [
        [
          "age_over_18"
        ],
        [
          "age_over_19"
        ],
...
        [
          "age_over_98"
        ],
        [
          "age_over_99"
        ],
        [
          "age_in_years"
        ],
        [
          "age_birth_year"
        ],
        [
          "birth_date"
        ]
      ]
    }
  ]

[c2bo]

So semantically we'd treat it as equivalent to requesting all the age_over_xx values? i.e.

...

Yes, that would be my interpretation - you basically request the first matching one which is identical to your query.

[brentzundel]

Discussed today, language seems acceptable. Needs more approvals to merge. @jogu will review

[jogu]

So semantically we'd treat it as equivalent to requesting all the age_over_xx values? i.e.

It turned out my understanding here wasn't correct (thanks to Gareth for explaining the rules better) - the rules in 18013-5 are more complex and an equivalent DCQL query would need value matching as well. i.e.

{
  "credentials": [
    {
      "id": "my_credential",
      "format": "mso_mdoc",
      "meta": { "doctype_value": "org.iso.18013.5.1.mDL" },
      "claims": [
        { "id": "age_over_18", "path": ["org.iso.18013.5.1", "age_over_18"] },
        { "id": "age_over_19", "path": ["org.iso.18013.5.1", "age_over_19"], "values": [true] },
        { "id": "age_over_20", "path": ["org.iso.18013.5.1", "age_over_20"], "values": [true] },
        …
        { "id": "age_over_99", "path": ["org.iso.18013.5.1", "age_over_99"], "values": [true] },
        { "id": "age_over_17", "path": ["org.iso.18013.5.1", "age_over_17"], "values": [false] },
        { "id": "age_over_16", "path": ["org.iso.18013.5.1", "age_over_16"], "values": [false] },
        …
        { "id": "age_over_00", "path": ["org.iso.18013.5.1", "age_over_00"], "values": [false] },
        { "id": "age_in_years", "path": ["org.iso.18013.5.1", "age_in_years"] },
        { "id": "age_birth_year", "path": ["org.iso.18013.5.1", "age_birth_year"] },
        { "id": "birth_date", "path": ["org.iso.18013.5.1", "birth_date"] }
      ],
      "claim_sets": [
        ["age_over_18"],
        ["age_over_19"], ["age_over_20"], …, ["age_over_99"],
        ["age_over_17"], ["age_over_16"], …, ["age_over_00"],
        ["age_in_years"],
        ["age_birth_year"],
        ["birth_date"]
      ]
    }
  ]
}

So for an age_over_18 query, if you get a true claim back (for any age_over_xx), the user is definitely over 18, if you get a false claim back, they're definitely under 18. If the wallet only has age_over_19 false, then in my example query it would return age_in_years instead.

I think that's what Christian's text already says will happen.

[c2bo]

Just to make sure we don't forget:

Should this be added to 1.0 errata?

Imho, it would make sense, wdyt?

[jogu]

Just to make sure we don't forget:

Should this be added to 1.0 errata?

Imho, it would make sense, wdyt?

yes, I think we should do that. It clarifies something that's likely important to a bunch of people, and there's no good reason to have different behaviour between 1.0 and 1.1 (in fact that would actively be bad).

[brentzundel]

discussed today: we settled on keeping SHOULD rather than MUST and kept the language consistent. @c2bo will add the changes to v1.0 as well. Ready for final review.