RE: Selective Disclosure of lists

I suppose a Verifier could stipulate that Holder needs to present a VC that includes a “IsThisTheTruthAndTheWholeTruth” type of property/declaration in its interactions with the Holder …like one might stipulate in real life.  I don’t think there’s any magic here.  It’s up the Holder to decide whether or not they want to be compliant with this type of requirement and whether to continue engaging with the Verifier (and visa versa).

From: David Chadwick <d.w.chadwick@verifiablecredentials.info>
Sent: June 8, 2021 11:58 AM
To: Jeremy Townson <jeremy.townson@gmail.com>
Cc: W3C Credentials Community Group <public-credentials@w3.org>
Subject: Re: Selective Disclosure of lists


Hi Jeremy
On 08/06/2021 18:09, Jeremy Townson wrote:
David,

The conclusion I draw is that the verifier should avoid infering properties of the VC from document metadata, such as node counts, or counts of items in a list. On the other hand, the issuer should add properties explicitly to the document (e.g. numDirectors=2).

This  is one solution, but I am looking for a generic one.


Trying to calculate any property of the VC by implication seems to produce errors.

Is this really a problem of selective disclosure. If an issuer creates a VC containing a list of directors, without stating whether it is a complete list, the document signature won't encapsulate such information so such a claim cannot be verified. Is surely does not matter if the document is subsequently redacted or not?

This kind of problem seems to spring up elsewhere. Could the issuer infer that a list is up to date as of  this year if the VC's issuance date is recent for example? It feels like only applications can decide this. To that end, perhaps a 'numDirectors=6' approach would be the simpest and most reliable.

Did you have something more cunning in mind?

Yes. If the verifier's policy says either "give me the complete list of property X" or "give me whatever you want to disclose from property X" then whatever result is returned and signed by the issuer will conform to the verifier's policy and the verifier wont have to infer anything. In the first case selective disclosure will be forbidden, in the second it wont be. This is the solution we are working towards, but we wondered if anyone had other ideas.

Kind regards

David



Regards,
Jeremy



On Tue, 8 Jun 2021 at 13:47, David Chadwick <d.w.chadwick@verifiablecredentials.info<mailto:d.w.chadwick@verifiablecredentials.info>> wrote:

One example is the list of directors and list of secretaries of a company. A list might be empty (allowed), or the holder might wish to remove specific names before disclosing the list to the verifier. The issue is how can the verifier tell the difference between a culled long list and a complete small list.

Kind regards

David


On 08/06/2021 13:01, Jeremy Townson wrote:
Could you give an example, David, I had thought the point of selective disclosure was that the verifier could make only a binary (not)valid decision about validity and was not able to infer other properties of the undisclosed data, such as properties of lists.

On Tue, 8 Jun 2021 at 12:10, David Chadwick <d.w.chadwick@verifiablecredentials.info<mailto:d.w.chadwick@verifiablecredentials.info>> wrote:

I dont know if anyone has discussed the selective disclosure of lists but here are at least some of the issues:

The user's VC has a property with a list of values (e.g. names of role holders). The user only wants to disclose n of m of this list to the verifier.

How can the verifier determine the difference between

i) a list with only n entries

ii) a list that has more than n entries but the user has withheld some of them.

Then we have the case where

iii) the list is genuinely empty because e.g. the role, has not been assigned to anyone yet, and

iv) the user does not want to tell the verifier any of the list values.

As far as I am aware the current data model does not have any way of differentiating between any of the above in a selectively disclosed VC.

Kind regards

David

Received on Tuesday, 8 June 2021 23:09:09 UTC