Ambiguous Language in Input Evaluation

[kimdhamilton]

In Input Evaluation 2, there is an ambiguity, possibly because "Field Query Result" is undefined.

Suppose we have an input constraint like this:

"constraints": {
  "fields": [
    {
      "path": ["$.issuer", "$.vc.issuer", "$.iss", "$.issuer.id"],
      "purpose": "Looking for credentials from did:web issuer",
      "filter": {
        "type": "string",
        "pattern": "did:web:example.com"
      }
    }
  ]
}

Then suppose the input contains this VC:

{
  "issuer": {
    "id": "did:web:example.com"
  }
}

Input Evaluation Step 2 excerpt is below:

2. If the constraints property of the Input Descriptor is present, and it contains a fields property with one or more field objects, evaluate each against the candidate input as follows:
3. Iterate the Input Descriptor path array of JSONPath string expressions from 0-index, executing each expression against the candidate input. Cease iteration at the first expression that returns a matching Field Query Result and use the result for the rest of the field’s evaluation. If no result is returned for any of the expressions, skip to the next candidate input.
4. If the filter property of the field entry is present, validate the Field Query Result from the step above against the JSON Schema descriptor value.

Not knowing what "Field Query Result" means, based on context, I would expect this input VC not to match this filter. Here's why:

• At step 2.1, evaluator halts at $.issuer, returning an object (not string)
• Evaluator then moves to step 2.2, applies the filter, and it doesn't match (it's an object, not a string)

Step 2.1 seems to imply we stop at the first JSONPath match -- not the first JSONPath match that also matches the filter.

Asking because this behavior differs from here, which considers both JSONPath and filter, and therefore my VC matches.

Obviously, it's easy to clean up my example to avoid this problem, but this seems like a good opportunity to clarify the spec as well.

[kimdhamilton]

p.s. I can make a stab at a PR, just wanted to confirm which is intended before doing so. I'd lean towards removing the term "Field Query Result", which is undefined and otherwise unused in the rest of the spec.

[JaceHensley]

Oh interesting that's a really good edge case, I agree with you

[csuwildcat]

@kimdhamilton good catch! My code is written to do the right thing, but the language does need a tweak to tell the loop to keep going if the filter doesn't eval against a given JSON Path-located expression. Thank you for this, we all really appreciate your eagle eyes 🦅 👀

[csuwildcat]

@kimdhamilton merged #241, will close this when Brent has tweaked all the predicate language throughout the spec.

[csuwildcat]

This has been addressed in @kimdhamilton's merged PR