Re: Verifiable Requests?

Hi Steve

On 19/12/2020 22:17, Steve Capell wrote:
> Disclaimer : I’m a newbie in this group and, reading the various 
> threads, it’s obvious that the people in this group are WAY more 
> experienced than me in this domain
>
> So - apologies in advance whenever I ask a dumb question!
>
> Steven Capell
> Mob: 0410 437854
>
>> On 20 Dec 2020, at 9:12 am, Steve Capell <steve.capell@gmail.com> wrote:
>>
>> One vp activity that might impact the vc data model is selective 
>> redaction

The W3C spec uses the term selective disclosure, which is subtly 
different. Redaction means you see the whole document with bits blacked 
out. Disclosure means you only show selective parts of the document and 
does not mandate that you have to also disclose the redacted parts.


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

Correct


>>  Furthermore, I can do that without going back to the issuer to ask 
>> for a new vc containing a specific subset.


I dont believe there is anything in the W3C spec that says this i.e. 
neither condones nor forbids it.


>>
>> We do this in international trade with the hash per element approach 
>> defined in the https://www.openattestation.com/ 
>> <https://www.openattestation.com/> framework.


The implementation guidelines suggest 3 ways: atomic credentials, hashed 
values and ZKPs but does not state these are the only ways. A fourth way 
is returning to the issuer.

>>
>> But it needs a VC model that includes the salted /hashed element tree 
>> - otherwise the redacted VP can’t work

This hashed method is being standardised in the ISO mDL standard (mobile 
driving licenses) but it currently does not support W3C VCs, it has its 
own way of formatting licenses.


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

There are at least 4 known ways as I have just outlined

Kind regards

David


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

Received on Sunday, 20 December 2020 10:47:16 UTC