Re: Verifiable Requests?

David, I agree -- it’s important to verify the authenticity of the request before responding.

Daniel,

You said:
When you give testimony in court, the dynamics are asymmetric. The court requests your testimony; you give a verifiable response. You take an oath to tell the truth. The court does not. This asymmetry is normal. It is not *universal* -- I can imagine a witness agreeing to testify, but only after demanding proof that the court is legitimate, etc. But we don't fix that corner case by modeling the process of giving testimony as a reciprocal/symmetric process. We allow the giver-of-testimony and the requester-of-testimony to exist in an asymmetric relationship, with non-equivalent duties and powers -- and then we apply the asymmetric relationship in a new direction to compensate (ask the court to prove its legitimacy), as needed.

I see what you’re saying, but I would equate this, using the courtroom analogy, to being called for testimony and showing up to give it. I probably wouldn’t respond to a request for testimony asking me to go to the a back alley behind a mediocre pizza joint — I need to know that the request is authentic before responding to it, and, where to respond to (callback uri). Certainly I can choose to write to any prosecutor/defense attorney and present compelling testimony, in which case, they may choose to depose me or bring me on as a witness.

What I'm saying is that "Verifiable" Requests are not and need not be a thing, because usually the burden of proof on the request doesn't justify the "verifiable" label. A request is just like any sentence, statement, or message. If you need to say anything on the record so it's non-repudiable, great -- do that. We don't need a format to make it verifiable, and in particular we don't need to standardize requests for credential material as a format *for the purpose of verifiability.* We want to standardize requests for a different purpose.

I do believe wallets/agents need to be able to discern legitimate requests in order to respond to them. I foresee a world where our wallets have inboxes, much like email. Email has really failed at spam filtering, and the VC world can do better, I think VRs can help.

I’d love to hear others on the list weigh in, and know the proper steps to get this added to an up-coming meeting’s agenda for discussion.

Gabe

From: David Chadwick <D.W.Chadwick@kent.ac.uk>
Date: Sunday, December 20, 2020 at 3:29 AM
To: daniel.hardman@evernym.com <daniel.hardman@evernym.com>
Cc: Credentials Community Group <public-credentials@w3.org>
Subject: Re: Verifiable Requests?
I agree with Daniel. The receiver simply needs to know that the request
is coming from the remote party, whoever that is.

There has been a lot of research on trust negotiation. In this model the
two parties progressively disclose their increasingly confidential
credentials to each other. The use case I like to use is, a CIA agent is
in a Moscow hotel who wants to connect to a CIA server in the US. The
comms link is secure against a DY attacker, but the agent does not know
who is at the other end of the secure channel. Neither does the server.
So both parties have to start off in public mode, just like a tourist
accessing a US travel site.

Each side sends its policy (presentation request) for this level to the
other, along with its VP that satisfies the other's policy of the
previous level.

Kind regards

David

On 19/12/2020 22:01, Daniel Hardman wrote:
> Gabe said:
>
> >On the surface I agree with you. My stance then is either Verifiable
> Presentations should be removed from the VC spec, or Verifiable
> Requests be added. If you disagree, I’d like to know how you view
> Verifiable Presentations and Requests as asymmetric.
>
> When you give testimony in court, the dynamics are asymmetric. The
> court requests your testimony; you give a verifiable response. You
> take an oath to tell the truth. The court does not. This asymmetry is
> normal. It is not *universal* -- I can imagine a witness agreeing to
> testify, but only after demanding proof that the court is legitimate,
> etc. But we don't fix that corner case by modeling the process of
> giving testimony as a reciprocal/symmetric process. We allow the
> giver-of-testimony and the requester-of-testimony to exist in an
> asymmetric relationship, with non-equivalent duties and powers -- and
> then we apply the asymmetric relationship in a new direction to
> compensate (ask the court to prove its legitimacy), as needed.
>
> What I'm saying is that "Verifiable" Requests are not and need not be
> a thing, because usually the burden of proof on the request doesn't
> justify the "verifiable" label. A request is just like any sentence,
> statement, or message. If you need to say anything on the record so
> it's non-repudiable, great -- do that. We don't need a format to make
> it verifiable, and in particular we don't need to standardize requests
> for credential material as a format *for the purpose of
> verifiability.* We want to standardize requests for a different purpose.
>
> This does not mean I'm against a standard format for making requests
> for credential material. I actually love the idea of the presentation
> definition that DIF's proposing. What I'm against is the idea that
> such a request needs special format properties to make it verifiable.
> It doesn't. It shouldn't have the word "verifiable" in front of it. If
> we want our request to be on the record, include a digital signature
> over its hash, or use some other auditable authentication, or
> whatever. No format changes needed. If what we want to do is check the
> bona fides of the party making the request, we do that by reversing
> the holder and verifier roles temporarily, and asking the verifier to
> prove something to us using VCs of their own, before we honor their
> own request for proof. There's already a format for that.
>
>
>
>
> On Sat, Dec 19, 2020 at 10:15 AM David Chadwick
> <D.W.Chadwick@kent.ac.uk <mailto:D.W.Chadwick@kent.ac.uk>> wrote:
>
>     Hi Daniel
>
>     I would revise your requirements somewhat as follow
>
>     On 19/12/2020 04:06, Daniel Hardman wrote:
>     > FWIW, here are the things that I think we need to standardize:
>     >
>     > 1. A credential and a presentation (the VC spec)
>     > 2. How a credential is requested (what the new DIF spec calls a
>     > "presentation definition", which is quite powerful and generally
>     > useful, IMO)
>
>     Rather I would say: How a set of credentials, or alternative sets of
>     credentials, are requested.
>
>     This request needs to be fully flexible to cater for (as near as
>     possible) any conceivable requirements of the SP. In our
>     implementation
>     we use DNF and CNF as these can present any set of requirements.
>
>     > 3. How a response to a request explains the way that the
>     response maps
>     > to the request ("You asked me for either a driver's license or a
>     > passport, plus proof of my current address. I chose to give you the
>     > passport, and to prove my current address by showing you a utility
>     > bill.")\
>
>     I actually don't think this is needed. The returned VP is the
>     holder's
>     answer to the request. It contains the requested VCs embedded in
>     it. So
>     it is self-explanatory. (The Holder does not need to say its a
>     utility
>     bill because the VC itself will say what type it is). It is the
>     responsibility of the verifier to see if the VP does contain the
>     set of
>     VCs that meets the SP's requirements. There is little point in the
>     holder giving an explanation because:
>
>     a) the explanation could be acceptable but the actual VC may not
>     be (I
>     am showing you a utility bill, but the utility bill issuer is
>     unknown to
>     the verifier)
>
>     b) the explanation might not be acceptable, but the VC might be (I am
>     sending you my employment card (instead of passport), but this
>     contains
>     the holder's current address)
>
>     c) the explanation could be false and the VC could be something
>     entirely
>     different to the explanation, so what does the verifier believe, the
>     explanation or the actual VC? (I am giving you my passport but the
>     VC is
>     an employment certificate.)
>
>     So I see no useful purpose for the explanation. I don't believe it is
>     needed, but worse, I think it complicates the processing by the
>     verifier.
>
>     Kind regards
>
>     David
>
>