Re: Verifiable Requests?

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...