Re: Verifiable Requests?

This is a frustrating conversation that I’m sure would be better had using our voice.

As one of the editors of the DIF Presentation Exchange spec I must reiterate that there is a gap between a Presentation Definition, and an instance of a definition that is a “request,” which is precicely why I started this thread. The idea of a request is out of scope of the DIF effort, which aims to be agnostic to proofs and envelopes.

Daniel,

Your points are good, but I’m a bit confused so I’ll share my understanding of each:

  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.
Yes, it’s intended to be a preliminary proof authenticating the request. Today there’s really no way for a holder to interrogate a requester for proper proof, in absent of that, a requester signing the assertion that they’re sending is a benefit. Better than a completely unauthenticated request, no?
Looking at the VP, the problem is the same. The holder has to read the mind of the requester when generating a presentation. What if the verifier said “I don’t care about that DID of yours, I want proof from these other 12 DIDs!” It does seem like this idea is being given more scrutiny than the VP part of the spec. Then, I ask again, can we consider adding VRs or removing VPs?

  1.  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.
This is a gap and we should consider an error handling path. But really, if there’s a problem the holder can choose not to respond – just like they would today if they got a request they didn’t care to respond to. Or, better yet, send the requester’s DID a DIDComm message asking to re-send with different creds.

  1.  You can't recurse.
  2.  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").
See earlier point on the same problem with VPs. My idea was to be a data format, not a protocol. Just like VPs. I agree a protocol is needed for these types of interactions, and out of scope for what DIF’s Presentation Exchange hoped to accomplish, at least for v1.

Perhaps the most sensible thing would be to remove VPs from the spec, and push both VPs and VRs (data format + protocol) into DIDComm.

Gabe

From: Liam McCarty <liam@unumid.org>
Date: Monday, January 4, 2021 at 2:08 PM
To: daniel.hardman@evernym.com <daniel.hardman@evernym.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>, Credentials Community Group <public-credentials@w3.org>
Subject: Re: Verifiable Requests?
All great points, Daniel.

Honestly I think our differences here may be largely semantic. If the DIF presentation definition spec accomplishes what you mentioned, then that sounds basically like what Gabe proposed as verifiable requests — it has the notion of “presentation request”. I may just not know enough about the various communities’ efforts, which is my bad.

The interaction/sub-interaction sequence you describe makes perfect sense to me. I mentioned the same concept in one of the early emails in this thread but came to a different conclusion — that both sides playing multiple roles made the role definitions way too confusing. I think what you’re advocating for is that we stick with the low level “primitives” so to speak, and I can certainly see benefits of that. What I’ve been advocating for is creating some higher level abstractions to make understanding and using the specs easier.

It certainly seems like the notion of a Verifiable Presentation was motivated by the same idea, at least in part. In the W3C spec, it says the goal is to ensure “authorship of the data is verifiable”. This doesn’t seem strictly necessary, in the sense that you might instead stick with the “primitive” of a Verifiable Credential and not abstract beyond that. But a Verifiable Presentation is useful because it’s a higher level concept and because it wraps data potentially from multiple sources together under one signature.

What I’ve been claiming is that a Verifiable Request may be similar. It’s not strictly necessary — the verifier can prove they’re legitimate by acting as a holder and presenting a credential to a holder acting as a verifier (already the terms are getting to be a mouthful…). But it’s arguably a pretty useful higher level concept to have a “request” and for it to be verifiable. Data about the verifier and about what they’re requesting can be wrapped together under one signature.

Anyway, I definitely see what you’re saying and the clear merits of your approach. And I don’t think we’re actually saying such different things as it seems. If only semantics were easier!

Thanks for the detailed and thoughtful responses.

Best,

Liam

Liam McCarty
Co-Founder of Unum ID<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.UnumID.org&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=OYe3SDzMbpaV9pcS4069tLdSQS6TzjtwBSGRhiCozgY&s=F1KmlEJvFWe1kCjmzA0KrBKOYBOB0TdLN7vBptng8IQ&e=>


On Jan 4, 2021, at 3:32 PM, Daniel Hardman <daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>> wrote:

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.