search

decentralized-identity / presentation-exchange

Specification that codifies an inter-related pair of data formats for defining proof presentations (Presentation Definition) and subsequent proof submissions (Presentation Submission)
https://identity.foundation/presentation-exchange
Apache License 2.0
84 stars 37 forks source link

Clarify predicate or remove it from the spec #238

Closed kimdhamilton closed 2 years ago

kimdhamilton commented 3 years ago

There have been several issues describing concerns with predicate, such as the following:

Despite being closed, it doesn't seem like the concerns were addressed. I have the following additional concerns:

  1. What does predicate=preferred mean in terms of evaluating inputs? My guess is that it would be a means to select among candidate inputs, but that's not called out in the spec. 4.3.3 simply says the following:

If the predicate property of the field entry is present, a boolean value should be returned rather than the value of the Field Query Result. Calculate this boolean value by evaluating the Field Query Result against the JSON Schema descriptor value of the filter property.

Because there is no discussion of comparisons among candidate inputs, I'd conclude I should just treat predicate=preferred as a no-op at this level.

  1. There are no examples in the spec demonstrating the predicate field
  2. Discussion of various proof forms related to predicate occupies a lot of space in the spec (see screenshot), but they are not clearly tied in to the rest of the spec/examples (see concerns 1+2). It would be nice to clean up the spec by removing all of this. Screen Shot 2021-08-11 at 11 30 01 AM
swcurran commented 3 years ago

My view is that predicates are incredibly important for privacy reasons, whether the VC supports ZKP or not. It allows the verifier to provide to the holder requirements for whether a verifiable presentation will be accepted for a given business purpose. That helps the holder decide if they will respond to the request or not. Not responding to a request that will not be accepted is privacy preserving.

The ability to respond to a predicate with a ZKP is powerful, but the value is very much still there even without ZKPs. Further, AFAIK ZKP predicates are quite limited, whereas a general purpose expression (as I believe is supported in PE, but not certain), is very powerful.

kimdhamilton commented 3 years ago

The concerns I raise are the very practical ones of creating a testable spec.

swcurran commented 3 years ago

I would agree that clarification of both filter and predicate need review and clarification.

It appears to me that filter (not predicate) is what I referenced above in my comment about guidance from the verifier to the holder/prover about what will be accepted for a given use case. However, it appears from my read of the spec that the filter expression value should be included in the presentation returned to the verifier. Is that the intention? If so, the value will not be signed by the Issuer, so it is not verifiable. I would discourage that approach. For filters, I would think that verification is only possible if the prover includes the input claims (signed) to the expression, and the verifier verifies the input claims and then executes the expression to see if it meets the filter condition.

Further, correcting my assumption about predicates, I now assume that they are intended to be ZKP predicates (if so, let's make that explicit), and usable only if the VC format supports ZKP predicates. Did I get that right? When used, a claim for the predicate would be added as a claim in the presentation (unlike filters), with its value derived from the expression and verifiable based on the ZKP predicate algorithm.

Is that the intention?

kimdhamilton commented 2 years ago

to discuss Feb 10 2022: close or rephrase?