Presentation Definition extensions?

[dalebowie]

Have you considered how to handle some additional scenarios with the presentation definition? Two scenarios I've come across are below. They both reference the example in the README and particularly make modification to this section:

            fields: [{
                path: ["$['org.iso.18013.5.1']['family_name']"],
                intent_to_retain: false,
              }],

As an extended thought, would it also be possible to have the same procedure available for the Verifier to perform as part of their verify function call? If the verifier is presented with a DeviceResponse, they might want to ensure it meets all their criteria per a presentation definition specification.

Scenario 1: field doesn't exist on the mdoc

            fields: [{
                path: ["$['org.iso.18013.5.1']['resident_country']"],
                intent_to_retain: false,
              }],

This is a valid, but optional mDL field. Some mDL credentials might have it, others might not. Even when a credential doesn't have it, the device response can be created and then a subsequent verification pass. I would expect this to fail or at least have some catchable error.

There is a TODO and question in the relevant code block: https://github.com/auth0-lab/mdl/blob/main/src/mdoc/model/DeviceResponse.ts#L310-L313

Scenario 2: field doesn't meet filter constraint

            fields: [{
                path: ["$['org.iso.18013.5.1']['family_name']"],
                filter: {
                    type: "string",
                    const: "Smith",
                },
                intent_to_retain: false,
              }],

The minted credential in the example is for the family name Jones, but despite asking for a Smith credential, this part of the constraint is ignored and the result is the Jones credential is deemed enough to satisfy this constraint.