Re: Verifiable Requests?

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

Further to Daniels response and making it more concrete in reference to the
VC data Model, ZKP capable signature schemes like BBS+ mean that the
subject/holder never directly reveals the credential that was issued to
them, they instead always derive a proof of knowledge of that credential
and selectively decide what to reveal from the credential in the resulting
proof. Current draft of this approach can be found here
<https://w3c-ccg.github.io/ldp-bbs2020/> and reference implementation
<https://github.com/mattrglobal/jsonld-signatures-bbs>.

As a side note, I'm sure the following comparative points are already quite
well understood in this community w.r.t to the hashing and salting based
redaction scheme vs ZKP's, but in case others have not noted the
differences before, I see the following interesting properties (others may
also have more to add).

*Pro's of Hashing redaction scheme*
- No requirement of any new cryptographic primitives just the composition
of existing ones which makes implementations simpler.

*Pro's of ZKPs*
- Simpler associated cryptographic material, with the hashing based
redaction scheme you have to per attribute keep track of, the attribute
value, the attribute specific salt, and the attribute specific hash plus
the overarching signature that signs all the hashes. Whereas ZKP schemes
like BBS+ only require you to keep track of the attribute values and the
signature that protects their authenticity much more akin to traditional
digital signatures and therefore quite aligned to the current VC data model.
- No signature based correlation of credentials, because the signature in a
ZKP enabled VC is never revealed, instead merely proved knowledge of, via a
derived proof, this vector of possible correlation is removed.
- Increased difficulty for relying collusion. In the hashing based
redaction scheme if two parties receive redacted proofs for the same
credential that reveal different attributes, they can simply exchange the
salt and attribute values with each other to reveal further information
from their respective proofs.
- Deriving a proof, authenticates possession of underlying credential. In
the hashing based redaction scheme, deriving a redacted proof on its own
does not protect against replay attacks so it must be instead combined with
an authentication scheme (e.g did auth). Deriving a proof using a ZKP
enabled VC includes the provision for a nonce and any other
arbitrary information that is useful in the resulting proof, meaning there
is no need for an external authentication scheme.

To answer your original question, I'd say because redaction schemes require
you to coordinate quite a bit more information in order for them to
function it's not obvious to me where this information should go in a VC
(e.g the attribute specific nonce and attribute specific hash).

Thanks,
[image: Mattr website] <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
[image: Mattr website] <https://mattr.global> [image: Mattr on LinkedIn]
<https://www.linkedin.com/company/mattrglobal> [image: Mattr on Twitter]
<https://twitter.com/mattrglobal> [image: Mattr on Github]
<https://github.com/mattrglobal>
This communication, including any attachments, is confidential. If you are
not the intended recipient, you should not read it - please contact me
immediately, destroy it, and do not copy or use any part of this
communication or disclose anything about it. Thank you. Please note that
this communication does not designate an information system for the
purposes of the Electronic Transactions Act 2002.


On Sun, Dec 20, 2020 at 11:14 AM 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
>>
>>
>>

-- 
This communication, including any attachments, is confidential. If you are 
not the intended recipient, you should not read it - please contact me 
immediately, destroy it, and do not copy or use any part of this 
communication or disclose anything about it. Thank you. Please note that 
this communication does not designate an information system for the 
purposes of the Electronic Transactions Act 2002.