- From: Greg Bernstein <gregb@grotto-networking.com>
- Date: Mon, 19 Jun 2023 13:49:58 -0700
- To: public-credentials@w3.org
- Message-ID: <3ef7edec-fade-c84f-fb2a-77d6197bcf55@grotto-networking.com>
Here is another more subtle example that seems to require some bundling. At the bottom I include a greatly simplified JSON-LD example based on a “real” CLR (comprehensive learner record) example from Tracy Korsmo. As part of the CLR we can get a listing of all the courses a learner has taken. However just because they took the course doesn’t mean they passed or completed the course. As you can see below the |creditsEarned| field seems to indicate this desirable information along with the |creditsAvailable| information without it the course information doesn’t see to mean much. Note that the |result| field (letter grade) could be selectively disclosed. In the example below the student did not complete two of their courses in their senior year in high school, but did great in a couple other courses. Note: not a real student! Note that I’m pointing out these potentially more complex cases so that we can potentially handle them in the future. The CLR spec doesn’t mention selective disclosure (i.e., my quick search didn’t find it) so it is not a requirement for them yet. I don’t think we should delay rolling out selective disclosure features in some very widespread privacy enhancing cases when it is not yet a requirement but I think with some reasonable processing we can deal with some of these “bundling”/“atomicity” issues. Hence the importance of collecting real world examples and then simplifying them for general understanding. Cheers Greg *Simplified JSON-LD Example* (CLR 1.0 like course listing): |{ "@context": { "@vocab": "https://windsurf.grotto-networking.com/selective#" }, "assertions": [ { "achievement": { "name": "Ag Processing", "issuer": { "name": "Great Plains High School" }, "achievementType": "Course", "creditsAvailable": 0.500, "fieldOfStudy": "AGRICULTURAL EDUCATION", "level": "12", "resultDescriptions": [ { "name": "Term Grade", "resultType": "LetterGrade" } ] }, "recipient": { "type": "id", "identity": "urn:uuid:c110ee6b-938c-dc58-1a35-eff2e11587d8", "hashed": false }, "creditsEarned": 0.000, "term": "S2", "results": [ { "value": "IP" } ], "verification": { "type": "Signed" } }, { "achievement": { "name": "Horticulture", "issuer": { "name": "Great Plains High School" }, "achievementType": "Course", "creditsAvailable": 0.500, "fieldOfStudy": "AGRICULTURAL EDUCATION", "level": "12", "resultDescriptions": [ { "name": "Term Grade", "resultType": "LetterGrade" } ] }, "recipient": { "type": "id", "identity": "urn:uuid:c110ee6b-938c-dc58-1a35-eff2e11587d8" }, "creditsEarned": 0.000, "term": "S2", "results": [ { "resultDescription": "urn:uuid:c988fea4-a5ef-4ce9-bc46-cd96147ffc7f", "value": "IP" } ] }, { "achievement": { "name": "Welding and Fab", "issuer": { "name": "Great Plains High School" }, "achievementType": "Course", "creditsAvailable": 0.500, "fieldOfStudy": "AGRICULTURAL EDUCATION", "level": "11", "resultDescriptions": [ { "name": "Term Grade", "resultType": "LetterGrade" } ] }, "recipient": { "type": "id", "identity": "urn:uuid:c110ee6b-938c-dc58-1a35-eff2e11587d8" }, "creditsEarned": 0.500, "term": "S1", "issuedOn": "0001-01-01T00:00:00", "results": [ { "resultDescription": "urn:uuid:78408f07-a90e-4433-bdad-ce65c3d480a7", "value": "A" } ] }, { "id": "urn:uuid:2cad07bc-ca64-44dc-bb81-ffcdaa44aaba", "achievement": { "id": "urn:uuid:99711d8c-8c60-493b-9d4e-76e0ceaa3ebd", "name": "Agriculture III", "issuer": { "name": "Great Plains High School" }, "achievementType": "Course", "creditsAvailable": 0.500, "fieldOfStudy": "AGRICULTURAL EDUCATION", "level": "11", "resultDescriptions": [ { "name": "Term Grade", "resultType": "LetterGrade" } ] }, "recipient": { "type": "id", "identity": "urn:uuid:c110ee6b-938c-dc58-1a35-eff2e11587d8" }, "creditsEarned": 0.500, "term": "S2", "results": [ { "value": "A" } ] }, { "achievement": { "name": "English 11", "issuer": { "name": "Great Plains High School" }, "achievementType": "Course", "creditsAvailable": 0.500, "fieldOfStudy": "ENGLISH/LANGUAGE ARTS", "level": "11", "resultDescriptions": [ { "name": "Term Grade", "resultType": "LetterGrade" } ] }, "recipient": { "type": "id", "identity": "urn:uuid:c110ee6b-938c-dc58-1a35-eff2e11587d8" }, "creditsEarned": 0.500, "term": "S1", "results": [ { "value": "B" } ] } ] } | On 6/16/2023 3:55 PM, Steve Capell wrote: > 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> 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. >> >> >> >> >>
Attachments
- application/pgp-keys attachment: OpenPGP public key
Received on Monday, 19 June 2023 20:50:12 UTC