Re: Verifiable Requests?

If I understand this right, I’d agree that is should not be up to the holder / presenter to have to map his/her claims to the needs of the verifier - but rather for the verifier to pull whatever claims from the VP that they need for their process 

Which does imply some kind of standard vocabulary of claims - and maybe even extra semantic equivalence vocabularies that declare mappings between well established but overlapping vocabularies.

Steven Capell
Mob: 0410 437854

> On 20 Dec 2020, at 9:14 am, Daniel Hardman <daniel.hardman@evernym.com> wrote:
> 
> 
> I said:
>  
>> > 3. How a response to a request explains the way that the response maps 
>> > to the request ("You asked me for either a driver's license or a 
>> > passport, plus proof of my current address. I chose to give you the 
>> > passport, and to prove my current address by showing you a utility 
>> > bill.")
> 
> And David responded: 
> 
>> I actually don't think this is needed. The returned VP is the holder's 
>> answer to the request. It contains the requested VCs embedded in it. So 
>> it is self-explanatory. (The Holder does not need to say its a utility 
>> bill because the VC itself will say what type it is). It is the 
>> responsibility of the verifier to see if the VP does contain the set of 
>> VCs that meets the SP's requirements.
> 
> I agree that this is not strictly required to answer the question, "Was my request satisfied (does the proof validate)?" However, I believe it could be quite helpful in cases where humans are trying to understand proof (as opposed to automation), and where the proof is complex. When I was working in machine learning, we initially focused on getting the right answer. Later, we learned to our chagrin that sometimes the calculations of our AI had to be explained to humans, and that there was no way to justify the calculations of a support vector machine juggling hundreds of inputs, to a mere mortal.
> 
> I don't think today's VC use cases are super complex yet, but I can imagine a time when we do our taxes or optimize investments or make hiring decisions based on complex proof interactions, and explaining which branching path among many possible valid options could be very helpful. See if this simple example resonates for you. A while back I had to fill out papers to help my daughter apply for citizenship. The proof requirements are things like "((2 documents from category A plus at least 3 from category B) or (1 document from category A, 1 document from category B, and 2 from category D)". The kind of software I'd like to write for a government worker evaluating a VC-based response to such a request would be one where the UI shows the branching possibilities and lights up the path that a given response took. I could maybe derive an algorithm for that based only on a response, but having an explanation would make it way easier...