Re: Verifiable Requests?

>
> Couldn’t we say the exact same thing about requests? (Here I mean request
> as a noun not a verb.) “There are many ways of encoding requests for
> VCs/VPs, and what’s best depends on the use case. But we’d benefit from a
> spec that provide a standard of certain best practices (like cryptographic
> proof of provenance) and a common language to ensure they can all
> interoperate.”
>

Yes. That's why the DIF developed the presentation definition spec.


> Daniel, all respect to you, truly, but the analogy of courtroom testimony
> makes no sense to me. Like Gabe said, I wouldn't give testimony in a back
> alley if a random person asks me to. I'd do a visual “spot check” to make
> sure the courtroom and judge are legitimate, just as I’d ask a supposed FBI
> agent to see their badge. (And how much better I’d feel if I could
> cryptographically check they’re a real agent, rather than rely on my
> untrained eye!)
>

Of course you wouldn't give testimony in a back alley. My point wasn't that
you don't need to authenticate verifiers sometimes; it was that when you
*do* authenticate them, you don't need a new data format or a new protocol
to do so; there's already a spec for that. When you ask the FBI agent to
see their badge, you are temporarily casting them in the prover role rather
than the holder role, and you are assuming the verifier role. So the
sequence is:

*[interaction 1]*

   - FBI as verifier asks you as prover to prove you're a US citizen using
   your passport.

*[sub interaction 2, roles reversed]*


   - You as verifier ask the FBI agent as prover to prove they're actually
   a legitimate agent.
   - FBI agent as prover furnishes legitimate agent proof to you as
   verifier.


   - You as prover furnish citizenship proof to FBI agent as verifier.

This is flexible and powerful. You can skip the sub interaction if you like
(e.g., instead of an FBI agent asking for your passport, it's now a cinema
employee asking for your movie ticket; the stakes don't justify reciprocal
proof). You can change who participates in sub interaction 2 (FBI agent
proves to your lawyer instead of to you). You can recurse (FBI agent says
they are willing to prove to lawyer, but only if you prove the lawyer
represents you... etc). Each layer of interaction has its own tests for
correctness, its own error-handling criteria, its own subtleties around
which standards of proof are acceptable, its own repudiation settings, its
own regulatory compliance profile.

If, on the other hand, you imagine satisfying all need for verifying the
verifying through a specialized "verifiable request" format+protocol, you
end up with a fragile mess:

[interaction 1: roles locked to FBI = verifier and you = prover]

   - FBI as verifier asks you as prover to prove you're a US citizen using
   your passport, AND provides proof (since they're using a 'verifiable
   request' format) that they're a legitimate FBI agent.
   - You as prover say, "Well, that's great that you're an FBI agent, but
   what I really want to know is whether you are on the special intra-agency
   task force that's charged with investigating the crime. I will only prove
   this to an agent who has standing on my case, not to a random FBI agent."

...you have some problems:

   1. The verifiable request concept you're trying to justify isn't
   flexible enough to anticipate everything that might be needed; the FBI
   agent has to guess about what sort of verification standards might apply to
   them. They might guess wrong.
   2. There is no error-handling path for the part of the protocol that
   verifies the request--only the part that verifies the response. A response
   of the prover who wants the verifier to provide more verifiability is
   indistinguishable from a response that's refusing to cooperate.
   3. You can't recurse.
   4. You assume that the party that needs to verify the verifier is
   identical to the party that is being asked to provide proof (no provision
   for "prove it to my lawyer").

...etc.

Verifiable requests are not the way to keep you from testifying in a
metaphorical back alley; plain old verifiable credentials and the
presentation definitions that DIF is working on are all you need. Just nest
the interactions.

But in a future where I have tons of personal data stored in a digital
> wallet, phishing is going to be *far *more of a problem. Today, it’s
> difficult for me to share lots of data all at once. When it’s way easier to
> do so, I sure hope I have more than a gist of whether someone asking for
> the data is legitimate.
>

Right. And you ask whether they're legitimate using the same format that
they ask you for proof of something -- not a different one.