Semantic vacuum

[David-Chadwick]

The current way that PE works is that it filters credentials based on their JSON properties, which typically are short form user friendly strings such as: subject, iss, degree, qualification, mail etc. However there is no context to these strings, and no guarantee that the string the RP places in the PD is actually the string that the RP wants. For example, a wallet may hold two or more different types of credential (JWT, VC, Z-CAP, ISO mDL etc.) that each contain the same JSON property name, but these have different semantics. Alternatively two different credentials of the same type, but from different issuers, might have the same property names that are semantically different. Consequently, the RP may be sent credentials it did not want and did not think it had requested.

The way that W3C Verifiable Credentials handles this is via the @context property, which guarantees that each short form user friendly string refers to a globally unique URI, so that is clear that strings with the same syntax are or are not semantically different.

Whilst the format property of PDs goes some way to solving this problem, it is not a full solution for several reasons i) format is only specified as MAY be present, so need not be present ii) format does not cater for verifiable credentials of the same type from different issuers who use the same property names for semantically different properties.

Similarly the frame property does not fully solve this issue as it only applies to credentials that are constructed using JSON-LD.

[JaceHensley]

You could have a field constraint that targets "@context" (with the caveat of needing to escape the "@"). This is also similar to the issues: https://github.com/decentralized-identity/presentation-exchange/pull/258 and https://github.com/decentralized-identity/presentation-exchange/issues/272, and it seemed like we wanted to just have fields handle all of these requirement types (value vs "shape" testing)

[David-Chadwick]

@JaceHensley Good point. A field constraint on "@context" would solve the issue for VCs. But this assumes that we have a solution for the @ character leading a property name.

I think it would be good to add a note to the Implementation Guide (or similar document) to the effect that Best practice when selecting VCs is to always have an "@context" field constraint to ensure that the correct short form property names are being targeted.

[JaceHensley]

I wonder if we should add an optional "semantic" property to Field Constraints?

[bumblefudge]

Discussed on today's call, not sure we can think through this and add a Field Constraint prop that satisfactorily accomplishes this for non-LD use-cases quickly enough for v2.0. Any chance you could come and check in with the group about it next week, @David-Chadwick ?

[bumblefudge]

Also, any additional help with the @ escape issue definitely welcome from JSONPath wizards

[csuwildcat]

I filed an issue on the JSONPath IETF repo and they promptly informed me that querying for properties with special characters using bracket notation already is the standard form that allows for selection of properties that have characters like @ in them: https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/issues/189

Any issues folks have brought up here must be with a lib that doesn't conform to the spec, but in my testing, most libs are handling this properly, as the spec directs them to.

[csuwildcat]

Group is open to Implementation Guide inclusion of advisement on semantic disambiguation. See Issue #336 for more info on Implementation Guide.