Re: Verifiable Requests?

I try to take a broader perspective based on auditability here
https://lists.w3.org/Archives/Public/public-did-wg/2021Jan/0005.html and
here https://lists.w3.org/Archives/Public/public-did-wg/2021Jan/0004.html
Is it helpful in this context?

Adrian

On Mon, Jan 4, 2021 at 5:08 PM Liam McCarty <liam@unumid.org> wrote:

> 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 <http://www.UnumID.org>
>
> 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.
>
>
>
>