Re: Selective Disclosure for W3C Data Integrity

Hi Steve, I miss the point: in Greg’s message I read

We see from the above that each property, and in particular the year property is tied to a “node id” (those _:c14nX things) and hence cannot be swapped amongst the different equipment listed.
And, in fact, under that canonicalization binding properties to nodes makes swapping impossible...
Am I misunderstanding something?
Best,
--luca



From: Steve Capell <steve.capell@gmail.com>
Date: Saturday, 17 June 2023 at 00:56
To: Luca Boldrin <luca.boldrin@infocert.it>
Cc: Orie Steele <orie@transmute.industries>, Greg Bernstein <gregb@grotto-networking.com>, W3C Credentials CG (Public List) <public-credentials@w3.org>
Subject: Re: Selective Disclosure for W3C Data Integrity
This email is from an unusual correspondent. Make sure this is someone you trust.
But Greg’s example is intended to describe a case where a claim like year of manufacture cannot be presented out of context because the verifier might incorrectly infer that the age of the board is the age of the sail

Lots of other real world cases (eg commercial invoices, transport waybills, etc , etc) where claims must be bundled or else a presenter could lie about values of invoices or packing list of consignments

In most of our supply chain use cases, the need is better described as “selective redaction” than “selective disclosure” and it is quite critical that the various bits of a trade document cannot be arbitrarily recomposed by a presenter.  So the Merkel tree proof method (one signature over a hash tree) works nicely for these kind of use cases.

I’m not saying that there aren’t lots of good use cases for atomic signed claims that can be composed by presenters.  Just saying that I don’t think it’s a general answer to all selective disclosure/redaction needs.

Steven Capell
Mob: 0410 437854


On 16 Jun 2023, at 6:47 pm, Luca Boldrin <luca.boldrin@infocert.it> wrote:

Dear all,
Greg’s example adds to my feeling that the RDF “atomic claim” approach is a clean way of dealing with selective disclosure requirements, when each claim is individually signed (i.e., single-claim credentials). Each credential would then attest a link in the graph.

<image001.png>

Conceptually, I see no reason to group claims and then sign, only to be able to produce selectively disclosed claims later. It appears much more logical to sign and then group (e.g., in a presentation). I don’t even see the necessity to bundle claims, since each one is individually true. The necessity of bundling attributes only appears when all attributes are (improperly) propagated to the root.

Practically, this approach may introduce some issues which I am interested to understand. I can think of:

  1.  The mechanism for requesting specific claims from a verifier may be more complex (e.g., assume a verifier wants to know: “prove to me that your inventory includes a board from 2022”: how should this query be asked?). Later, the verifier needs to carefully compose different claims in order to retrieve the desired information
  2.  There is the need to deal with a much larger set of credential schemas, revocation registries...
  3.  There is the necessity to have universally unique identifiers also for intermediate nodes in the graph.

I’m sure that the VC and LD communities already elaborated on these points. I would really appreciate any pointer.
Thanks and best,

--luca





From: Orie Steele <orie@transmute.industries>
Date: Friday, 16 June 2023 at 02:36
To: Greg Bernstein <gregb@grotto-networking.com>
Cc: W3C Credentials CG (Public List) <public-credentials@w3.org>
Subject: Re: FW: Selective Disclosure for W3C Data Integrity
mDoc seems to have accomplished the same functionality without using RDF or JSON-LD.

There are a lot of trade offs in terms of credential design if the credential can only be legally expressed in a single serialization.

I think vc-di-sd over hmac application/n-quads is interesting, as is disclosing streaming JSON pointers, with or without hmac.

But what happens when you don't have JSON-LD or JSON?

Selective disclosure schemes that are tied to a single serialization seem like a stepping stone to something better.

OS



On Thu, Jun 15, 2023, 6:59 PM Greg Bernstein <gregb@grotto-networking.com<mailto:gregb@grotto-networking.com>> wrote:

Here is a crude JSON-LD example showing the canonicalization algorithm that we currently use. Consider an inventory of windsurfing (sailing gear) where the date/age of the gear is important (the gear has a hard life) in JSON-LD:

{

  "@context": {

    "@vocab": "https://windsurf.grotto-networking.com/selective#"<https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwindsurf.grotto-networking.com%2Fselective%23&e=fe314e73&h=5f7c243b&f=y&p=n>

  },

  "sails": [

    { "size": 6.1,

      "year": 2023},

    { "size": 7.0,

      "year": 2020}  ],

  "boards": [

    { "name": "CompFoil170",

      "year": 2022},

    { "name": "Tillo Custom",

      "year": 2019}  ]

}

If we canonicalize this (see JSON-LD playground) we get

_:c14n0 <https://windsurf.grotto-networking.com/selective#name><https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwindsurf.grotto-networking.com%2Fselective%23name&e=fe314e73&h=7b60e49d&f=y&p=n> "CompFoil170" .

_:c14n0 <https://windsurf.grotto-networking.com/selective#year><https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwindsurf.grotto-networking.com%2Fselective%23year&e=fe314e73&h=803b8b4e&f=y&p=n> "2022"^^<http://www.w3.org/2001/XMLSchema#integer><https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23integer&e=fe314e73&h=65557473&f=y&p=n> .

_:c14n1 <https://windsurf.grotto-networking.com/selective#name><https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwindsurf.grotto-networking.com%2Fselective%23name&e=fe314e73&h=7b60e49d&f=y&p=n> "Tillo Custom" .

_:c14n1 <https://windsurf.grotto-networking.com/selective#year><https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwindsurf.grotto-networking.com%2Fselective%23year&e=fe314e73&h=803b8b4e&f=y&p=n> "2019"^^<http://www.w3.org/2001/XMLSchema#integer><https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23integer&e=fe314e73&h=65557473&f=y&p=n> .

_:c14n2 <https://windsurf.grotto-networking.com/selective#size><https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwindsurf.grotto-networking.com%2Fselective%23size&e=fe314e73&h=71cb6ad2&f=y&p=n> "7"^^<http://www.w3.org/2001/XMLSchema#integer><https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23integer&e=fe314e73&h=65557473&f=y&p=n> .

_:c14n2 <https://windsurf.grotto-networking.com/selective#year><https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwindsurf.grotto-networking.com%2Fselective%23year&e=fe314e73&h=803b8b4e&f=y&p=n> "2020"^^<http://www.w3.org/2001/XMLSchema#integer><https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23integer&e=fe314e73&h=65557473&f=y&p=n> .

_:c14n3 <https://windsurf.grotto-networking.com/selective#size><https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwindsurf.grotto-networking.com%2Fselective%23size&e=fe314e73&h=71cb6ad2&f=y&p=n> "6.1E0"^^<http://www.w3.org/2001/XMLSchema#double><https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23double&e=fe314e73&h=687baafe&f=y&p=n> .

_:c14n3 <https://windsurf.grotto-networking.com/selective#year><https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwindsurf.grotto-networking.com%2Fselective%23year&e=fe314e73&h=803b8b4e&f=y&p=n> "2023"^^<http://www.w3.org/2001/XMLSchema#integer><https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23integer&e=fe314e73&h=65557473&f=y&p=n> .

_:c14n4 <https://windsurf.grotto-networking.com/selective#boards><https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwindsurf.grotto-networking.com%2Fselective%23boards&e=fe314e73&h=6d220d62&f=y&p=n> _:c14n0 .

_:c14n4 <https://windsurf.grotto-networking.com/selective#boards><https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwindsurf.grotto-networking.com%2Fselective%23boards&e=fe314e73&h=6d220d62&f=y&p=n> _:c14n1 .

_:c14n4 <https://windsurf.grotto-networking.com/selective#sails><https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwindsurf.grotto-networking.com%2Fselective%23sails&e=fe314e73&h=e8608e3e&f=y&p=n> _:c14n2 .

_:c14n4 <https://windsurf.grotto-networking.com/selective#sails><https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwindsurf.grotto-networking.com%2Fselective%23sails&e=fe314e73&h=e8608e3e&f=y&p=n> _:c14n3 .

We see from the above that each property, and in particular the year property is tied to a “node id” (those _:c14nX things) and hence cannot be swapped amongst the different equipment listed.

What Luca and I have been discussing is ways to control the “atomicity” or “bundling” of attributes, i.e., things that must be revealed together or not at all.

Cheers Greg B.
On 6/10/2023 10:51 AM, Dave Longley wrote:

On Fri, Jun 9, 2023 at 3:25 PM Markus Sabadello <markus@danubetech.com><mailto:markus@danubetech.com> wrote:

Maybe Manu or Dave can clarify, but my understanding is that DB's "Selective Disclosure Data Integrity Cryptosuite" has bindings between all the claims and the credential, and would therefore NOT allow the re-composition of claims from different credentials as described in Luca's car mileage example.

Yes, that's right, Markus. Also of relevance is that claims in the VC

data model are "subject property value" statements (or "triples") that

therefore bind properties and values to particular subjects. The

selective disclosure scheme we described signs these statements

directly (i.e., it does not break these statements up into their

constituent parts), so you cannot erroneously recombine

property-values with different subjects.


​
​