Re: Verifiable Requests?

/cc Wayne, Heather

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

Loud and clear, Gabe. :) This is usually a good time for the chairs to
offer to discuss on a call. What we'd want is someone to create a structure
for and drive the discussion. Gabe -- I think you'd be the best candidate
for that.

The flow could be this:

   1. Summary of your proposal [Gabe]
   2. Briefly outline the concerns raised in this thread, as well as your
   responses [Gabe]
   3. Q&A: chairs will maintain the queue so respondents to this thread and
   others can weigh in (if they feel there's something missing from #2)
   [Chairs]
   4. Identify next steps: chairs identify options from discussions in
   1-3 + community discussion [Chairs]

If this sounds good, please reach out to Wayne and Heather with a day that
works for you (note CCG meeting time has been rescheduled to Wednesdays at
10am PT). I think this would need a good chunk of the meeting; at least 35
minutes.

The new meeting time doesn't work for me unfortunately, but I'll be
following along asynchronously in the usual ways.

Thanks,
Kim





On Mon, Jan 4, 2021 at 2:41 PM Gabe Cohen <gabe.cohen@workday.com> wrote:

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