Re: Verifiable Requests?

>So I’m curious how the W3C model will support redaction in VPs without any
impact to the VC model?

The way we solve this is to derive a new artifact, just in time for a
proving interaction. We're not redacting from the presented credential;
we're building a new credential with nothing redacted but nothing
superfluous presented. MS has proposed to do it by going back to the
issuer; ZKP-oriented credentials do it by creating a new artifact for each
proving interaction; Workday discussed a clever way to do this merkle
proofs instead of full-blown ZKPs at IIW a while back.

On Sat, Dec 19, 2020 at 3:12 PM Steve Capell <steve.capell@gmail.com> wrote:

> One vp activity that might impact the vc data model is selective redaction
>
> I thought (could be wrong) that the idea of a VP is that, as a holder, I
> can choose a subset of claims to present to a verifier.  Furthermore, I can
> do that without going back to the issuer to ask for a new vc containing a
> specific subset.
>
> We do this in international trade with the hash per element approach
> defined in the https://www.openattestation.com/ framework.
>
> But it needs a VC model that includes the salted /hashed element tree -
> otherwise the redacted VP can’t work
>
> So I’m curious how the W3C model will support redaction in VPs without any
> impact to the VC model?
>
> Steven Capell
> Mob: 0410 437854
>
> On 20 Dec 2020, at 9:03 am, Daniel Hardman <daniel.hardman@evernym.com>
> 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>
> 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
>>
>>
>>