Re: Verifiable Requests?

>
> I prefer to have the validation software algorithm work out the path and
> then tell the human verifier what this is, rather than relying on the
> holder('s wallet) to explain this to my code. As my previous message
> indicated, the wallet's explanation could be wrong. So I would prefer
> not to rely on it (it also introduces an attack vector for a malicious
> wallet).
>

I was imagining that any party receiving a proof would ask the binary
question, "Does this validate in a way that satisfies my request?" using
only the content of the evidence itself to answer. That, I believe, is
foundational. Thus, a malicious wallet could not lie about whether their
evidence is adequate, no matter how they explain it.

What this leaves is the possibility that a malicious wallet could provide
valid, satisfying evidence -- but lie in their explanation of which
acceptable path through the branching logic it took: "I gave you a passport
and three utility bills" when the truth is it gave a driver's license and
three utility bills instead (either of which was acceptable to the
verifier). I had been thinking that the risk of this kind of lie was
unimportant. But I suppose cybersecurity history tells us that any
opportunity to lie will eventually be manipulated by malicious people in
some surprising way that causes mischief -- so perhaps you are right.

I think the reason this explanation construct resonated so much for me is
that when we use ZKPs, and the prover combines fields from multiple
credentials into one verifiable presentation, we are already seeing
situations where software can evaluate the correctness of the evidence just
fine, but it takes a paragraph of text to explain what variant of
acceptable evidence was presented. So the need for explanation is real.
You're proposing that the explanation be generated, and I can see why
that's safer. But the challenge is that I can't generate a human-friendly
description of the evidence, because its pieces don't exist anywhere along
the interaction conducted via software. The request doesn't actually
contain human-friendly phrases like "Show me your driver's license or your
passport" -- it contains stuff that would mystify a mere mortal, like
"(issuer_did = X and schema = Y) OR (issuer_did = A and schema = B)" -- so
the best generated explanation we can give, from the data itself, looks
algebraic and uses terms that the verifier may not understand.

Pondering...