protocol middleware for RFC 0510: usability problem

[llorllale]

Middleware added in PR #2472

This middleware uses the presexch.PresentationDefinition.CreateVP(credentials, options) to create the VP in P-E format. It obtains the values for the credentials argument from a VP submitted by the user via the service.DIDCommAction.Continue() function by using the presentproof.WithPresentation() option.

What is the problem here? It requires the user to create a VP in the first place, defeating the use of the logic in presexch.PresentationDefinition.CreateVP(). The flow currently looks like this:

1. presentation request message received
2. event fired to the user
3. user fetches all required credentials somehow
4. user passes these credentials to event.Continue()
5. the middleware creates a VP of type PresentationSubmission.
6. The VP is sent without proof attached (it might have in the case of BBS+, I haven't checked)

Step 3 and 6 are the biggest problems here. How does the user figure out which credentials are required? How can the verifier verify a VP without proof (it cannot)?

Aside from adding a proof on this VP, we are missing an important cog in the machine: the presentation definitions criteria needs to be transformed into a query/process that is run against the verifiable store to fetch the required credentials. There are several ways this can be done (user is exposed to a utility function that fetches the matching credentials from the store and then passes them to event.Continue(), PresentationDefinition.CreateVP() can do it automatically given a handle on the verifiable store, etc.

[llorllale]

Spoke with @soluchok

The problems are recognized in the following order of priority:

1. missing proof: this will be added once the BLS primitives are added to the KMS and Crypto interfaces
2. filter the credentials in the database:
   • requires some more thought given the latest design of the Store interface
   • some low hanging fruits seem to be to tag each credential by their schema and issuer