Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Presentation Definition extensions? #36

Open
dalebowie opened this issue Jan 13, 2025 · 0 comments
Open

Presentation Definition extensions? #36

dalebowie opened this issue Jan 13, 2025 · 0 comments

Comments

@dalebowie
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant