Re: Verifiable Requests?

Yeah, Wayne and I have already discussed having this topic at an upcoming
meeting (& Gabe emailed with us), so we're on it.

Give us a moment to come back from the break - there's been a lot in flux &
in prep for the election.

-H

On Tue, Jan 5, 2021 at 12:26 PM Kim Hamilton <kimdhamilton@gmail.com> wrote:

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

-- 
Heather Vescent <http://www.heathervescent.com/>
Co-Chair, Credentials Community Group @W3C
<https://www.w3.org/community/credentials/>
President, The Purple Tornado, Inc <https://thepurpletornado.com/>
Author, The Secret of Spies <https://amzn.to/2GfJpXH> (Available Oct 2020)
Author, The Cyber Attack Survival Manual
<https://www.amazon.com/Cyber-Attack-Survival-Manual-Apocalypse/dp/1681886545/>
(revised,
Dec 2020)
Author, A Comprehensive Guide to Self Sovereign Identity
<https://ssiscoop.com/>

@heathervescent <https://twitter.com/heathervescent> | Film Futures
<https://vimeo.com/heathervescent> | Medium
<https://medium.com/@heathervescent/> | LinkedIn
<https://www.linkedin.com/in/heathervescent/> | Future of Security Updates
<https://app.convertkit.com/landing_pages/325779/>