You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
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.
The text was updated successfully, but these errors were encountered:
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:
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
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
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.
The text was updated successfully, but these errors were encountered: