Clarify Presentation Submission

[David-Chadwick]

Clarify that Presentation Submission is not mandatory for any target protocol

[csuwildcat]

I don't understand how a protocol would know which items are being submitted against which criteria if they don't do this. If this is made optional, what will the instructions be in the spec? Is this what we really intend to say: "Presentation Submission objects are optional, and if not present, just kind of figure out what things they threw at you somehow, k thx bye!" ?

[David-Chadwick]

I don't understand how a protocol would know which items are being submitted against which criteria if they don't do this. If this is made optional, what will the instructions be in the spec? Is this what we really intend to say: "Presentation Submission objects are optional, and if not present, just kind of figure out what things they threw at you somehow, k thx bye!" ?

@csuwildcat Are you saying that a wallet that potentially has orders of magnitude more credentials than are in the set sent to the RP, and that does not have access to a presentation submission, and that normally has less processing power than the RP, is somehow able to determine which of these credentials match the presentation definition, but the RP is not able to do the same thing? If you expect the wallet to "just kind of figure it out", then why cannot you expect the RP to do the same thing? In other words, whatever algorithm the wallet has implemented to figure it out can equally well be implemented by the RP to figure it out.

[nklomp]

In principle I agree with @David-Chadwick's opinion. It does raise a question though.

How would it work with a definition and VP that might be left open to interpretation because the definition might not be very well defined? On the wallet side a human could have been involved in the actual selection/mapping, which is not available on the verifier side. So the human has a direct impact on the submission data and thus the JSON path relationship between the definition and the VP path.

Let's say I have a VP with 3 VCs and let's say these have different purposes, but might have a field like for example bank account number that differs. The definition next to other fields, is looking for that bank account number, but now basically has 2 values. With submission data, the person associated with the wallet, could have said it was the bank account nr from VC 1. The verifier might be unable to pick the correct VC for it (really depends on the definition of course).

Of course it could be left up to the verifier to return an error if the result would be ambiguous

[David-Chadwick]

@nklomp I dont think your argument holds much water. Could you please give a specific example of where you scenario could exist rather than a vague suggestion. For example, if the RP required 3 identical VC types for different purposes, then it is likely to send 3 requests, not one. A real life example is getting an e-boarding card from Easy Jet on my smart phone. I can get boarding cards for my whole family on my phone. But I have to provide passenger details first (passport number etc.). Easy Jet asks me to fill in each passenger details separately. It does not send one request and expect me to return n different passport details. This real life use case can easily be migrated to a VC system by returning one passport VC for each passenger request. No presentation submission is needed. In fact, if the majority of RP requests only require one VC in response (which I suspect they will, such as age verification), then no presentation submission is needed. We should not complicate the majority of uses for the outlying use cases.

[nklomp]

My point was about the 'asymmetry' between the holder where a person can actually associate data with the submission data, which a verifier cannot do.

Examples are basically everything where there can be 2 or more of similar data that do really belong to me. Example: Phone numbers or e-mail addresses. You want my private and work phone numbers and/or e-mail addresses. The definition could be looking for my private e-mail address and work address, both could have similar constraints. There are many examples/forms that actually want that type of info from people. I might have multiple VCs that actually contain that information. As a holder I can associated the correct addresses with the correct definition fields. Something the verifier cannot do without the definition at hand.

Similar examples for PII of children etc.

Obviously you could create multiple interactions or restrict the definitions so that it might not happen, but reality is that there are many of these situations, so not sure I agree with your assertions. I believe at the minimum it should be pointed out that omitting submission data, means taking extra care to create definitions that do not leave room for ambiguity.

[csuwildcat]

There's no ambiguity if you check for the right credentialSchema or type member, which PE allows for. I agree with @nklomp that omitting Presentation Submission objects is an unnecessary footgun that only serves to reduce interop, fragment the ecosystem, and introduce more needless failures.

[David-Chadwick]

@nklomp Good examples. Thankyou. These do not indicate where presentation submissions are always absolutely necessary (for example, the VCs could be of different types, or have properties of different types: home phone number, work phone number etc. allowing the RP to determine which VC matches which of its requirement), but they are examples of where a PS would always ensure that no ambiguity exists in the returned VP. I suggest that the solution to this is that the transfer protocol has a field (PS required) that can be set to true or false by the RP, to indicate where a PS is required to help it determine which credential matches which requirement.

[David-Chadwick]

PR#309 proposes a resolution of this issue by including a field in the presentation definition that allows the RP to indicate whether it requires the presentation submission or not

[bumblefudge]

@David-Chadwick is this stale given what happened with 309, or is there a new PR coming based on the "just-in-time" generation of a PS idea?

[dtmcg]

@David-Chadwick @dwaite do you have further input here? we will close this item in the PE meeting May 19th

[csuwildcat]

Closing PR per decisions of the WG surrounding this topic.