Clarification on schema in Input Descriptors

[nklomp]

Hi,

As we are implementing a PE library in typescript, we got a question which triggered internal discussion, so I guess the wording currently might not be explicit enough how the schema(s) in the Input Descriptors should be matched in the input evaluation.

4.1.1 lists:

The Input Descriptor Object MUST contain a schema property. The value of the schema property MUST be an array composed of objects as follows:

- The schema object MUST contain a uri property, and its value MUST be a string consisting of a valid URI for an acceptable Claim schema.

- The schema object MAY contain a required property. If present, the value of this property MUST be a boolean. A value of true indicates that the given schema object is required to be the schema of the inputs used to fulfill the given Submission Requirement.

So schema must be an array, which is also reflected in the JSON schema (no pun intended).

Then in the input evaluation at 4.3.1 it mentions:

For each candidate input:
1. The URI for the schema of the candidate input MUST match one of the Input Descriptor schema object uri values exactly.

If the Input Descriptor schema object uri is a hashlink or similar value that points to immutable content, then the content of the retrieved schema must also match.

If one of the values is an exact match, proceed, if there are no exact matches, skip to the next candidate input.

Our current understanding of the above is that even if a VC has multiple contexts/schemas as long as we find a single first match from the VC context array against a single schema mentioned in the Input descriptor schemas array we should continue.

If that is correct probably that goes counter to what one might intuitively expect. I guess it is being used to denote that you can have multiple distinct schemas and/or multiple versions of a schema to match the input descriptor instead of denoting that the VC must match all the schemas.

Intuitively some in our team as well as an external implementor would expect that the VC needs to match all schemas in the descriptor. I guess that could pose problems with the matching of actual VC attributes against these schemas down the line though.

It would also mean that people that for instance might make easy mistakes, because they are used to having 2 or more context values in the VC, like for instance

 "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],

If one simply would use these in the input descriptor thinking it needs to match these contexts collectively what effectively happens is that it accepts almost all VCs given "https://www.w3.org/2018/credentials/v1" is in there.

Is our assumption above correct, and if so, we might want to make it a bit more explicit in the spec, because I have a feeling multiple implementers and users of PE might be making mistakes here.

[David-Chadwick]

This issue was discussed in the Presentation Exchange/OIDF special session today and it was suggested that this field should be removed entirely, partly due to the confusion of what precisely it refers to, but more importantly, because it is unnecessary as the constraints object can be used to directly refer to any property of VC (including the type and credentialSchema properties), without there being any confusion about which property is being referred to.

[nklomp]

Hehe guess that works indeed. Although I gues having a quick way to narrow down on a schema is nice from a user perspective as almost everyone will probably use that. Going through the constraints route is more precise, but also slightly harder

[David-Chadwick]

I don't think the user will be involved in this, but rather the wallet software will use the descriptor to filter out credentials that match what the verifier requires, and then it will ask the user to choose if there is more than one credential that matches a verifier's requirement. Having ambiguity in what the verifier wants risks the chance of the user sending a credential that the wallet think matches, but the verifier then rejects the user's request

[nklomp]

With user I meant the perspective of a verifier, as that is the location where the input descriptor would be created. There will be software that can generate these descriptors, but there will also be a lot of developers/tech-consultants creating these by hand

[decentralgabe]

Please see my comments here on the intention of the schema #256 (comment)

@nklomp I agree it would be less ambiguous to allow "any one of these schemas..." or "exactly these schemas..."