18:44:18 RRSAgent has joined #vcwg 18:44:19 logging to https://www.w3.org/2022/08/31-vcwg-irc 18:44:48 zakim, this is vcwg 18:44:48 got it, brent 18:45:02 zakim, start meeting 18:45:02 RRSAgent, make logs Public 18:45:03 please title this meeting ("meeting: ..."), brent 18:45:18 meeting: Verifiable Credentials Working Group 18:45:42 chair:Brent Zundel 18:46:18 Date: 2022-08-31 18:46:36 rrsagent, draft minutes 18:46:36 I have made the request to generate https://www.w3.org/2022/08/31-vcwg-minutes.html brent 18:57:57 cabernet has joined #vcwg 19:01:55 Orie has joined #vcwg 19:01:57 present+ 19:02:12 present+ 19:02:16 present+ 19:02:21 dwaite has joined #vcwg 19:02:22 selfissued has joined #vcwg 19:02:23 kristina has joined #vcwg 19:02:25 present+ 19:02:26 present+ 19:02:27 kdeangs1 has joined #vcwg 19:02:28 present+ 19:02:31 present+ 19:02:42 present+ 19:02:43 bengo_ has joined #vcwg 19:02:48 present+ 19:03:02 present+ , at a conference 19:03:17 scribe+ 19:03:38 Topic: Agenda Review 19:03:51 brent: we will talk about TPAC, PRs and issues. 19:04:02 present+ 19:04:15 brent: introductions? 19:05:04 Topic: TPAC 19:05:04 DavidChadwick: I'm with crossword now, formally with university of kent. 19:05:20 https://docs.google.com/spreadsheets/d/1Du-3G4d08OWxW1fNtn_8BLNsAIT4GETvk7F7v_Mu_dA/edit#gid=0 19:05:32 brent: tpac is 2 weeks away.... see the draft agenda above 19:05:46 ... if you are presenting, please be prepared. 19:05:58 SamSmith has joined #vcwg 19:06:00 Kerri_Lemoie has joined #vcwg 19:06:04 present+ 19:06:10 ... for those who are remote, we will be using zoom, join as you can. 19:06:25 oliver has joined #vcwg 19:06:28 ... questions? 19:06:32 present+ oliver_terbu 19:06:36 q+ 19:06:43 ack manu 19:06:53 manu: do all the presenters know they are presenting? 19:07:14 brent: afaik, everyone knows. 19:07:40 ... we anticipate an excellent meeting... we have a few big topics we will be covering. 19:07:51 ... please attend if you can. 19:07:53 Logan_Porter has joined #vcwg 19:08:16 ... if you have not yet indicated that you are attending, please add yourself to the attendees tab... it helps us plan. 19:08:28 present+ 19:08:33 ... make sure to report any dietary concerns if you are in person 19:08:55 davidchadwick: do we need to register if we are remote? 19:09:05 brent: yes, you must register as a remote participant. 19:09:19 Topic: PRs 19:09:21 q+ 19:09:27 https://github.com/w3c/vc-data-model/pulls 19:09:32 ack manu 19:09:52 VC Data Model PRs: https://github.com/w3c/vc-data-model/pulls 19:09:54 manu: I will be running through the PRs. 19:10:25 DavidC has joined #vcwg 19:10:29 present+ 19:10:36 https://github.com/w3c/vc-data-integrity/pulls 19:10:39 ... see the the explicit holder binding, the vocabulary updates, and the editors list on vc data model. 19:11:03 Steve_C has joined #vcwg 19:11:21 ... regarding vc-data-integrity, need comment from mprorock... see also the PRs related to the baseline of the cryptography suites. 19:11:34 q+ 19:11:43 scribe+ 19:11:49 ack Orie 19:11:50 https://github.com/w3c/vc-jwt/pulls 19:11:58 Orie: These are new PRs, opened today 19:12:04 Orie: First one removes typ header requirement 19:12:34 Orie: Second one begins to attempt production rules to convert VC data model to VC-JWT verifiable credential. Second one documents "instead of" vs. "in addition to" paths. 19:13:16 Orie: My hope was that we could be clear about normative requirements for VC-JWT requirements according to v1, and be more explicit about producing VC-JWT means, once we have that in writing, we could discuss changes to it. But not comingle attempts to refine w/ attempts to redefine it completely. 19:13:45 Orie: It's meant to document more concretely the "instead of" and "in addition to" paths. The previous PRs changes a normative requirement by relaxing typ requirement. We welcome feedback on PRs directly. 19:13:56 https://github.com/w3c/vc-jws-2020/pulls 19:14:45 Orie: There is one PR open for vc-jws-2020, it uses the IANA registries to describe vocabulary terms on what a JWK is, it is pointing to IANA for vocabulary for JsonWebSIgnature20202, this is specific to Data Integrity Proof format, not VC-JWT format. 19:15:31 Orie: There is a Data Integrity proof suite that depends on detached JWS, it is a description of how to use detached JWS to create Data Integrity proofs for protecting VCs. It needs to be defined in same way as other Data Integrity suites define vocabularies. The VC-JWT work is a separate item, that is why these are separate repos. 19:15:56 Topic: Issue Discussion 19:16:03 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Adiscuss+sort%3Aupdated-asc 19:16:34 tony: curious why.... the comment on the vocabulary? 19:16:36 q+ 19:16:42 ack Orie 19:16:51 Orie: Yes, that's correct. We are now referring to a specific PR, I'll point to it. 19:16:52 https://github.com/w3c/vc-jws-2020/pull/24 19:17:08 nadalin: We're not changing the vocabulary of what JWS/JWT use today, correct? 19:17:53 Orie: No, we are not changing that, I don't think. There are certain terms that need to be defined to make a Data Integrity Proof valid, I'm intending those terms to be defined by IANA. If folks don't agree that IANA is the right one, for example citing the RFCs directly, we can have that conversation if folks want to do that. 19:18:12 subtopic: https://github.com/w3c/vc-data-model/issues/893 19:18:32 brent: kristina, can you walk us through this? 19:18:50 kristina: the question was... where to put the metadata about "claims"... 19:19:17 ... how do we know how to use "evidence"... can we keep this issue open until we can align with identity assurance 19:19:27 q+ 19:19:32 ack manu 19:19:48 manu: the confusing word is "what is meant by metadata". 19:20:04 ... in theory you can add any metadata that you want, at any level... 19:20:15 q+ 19:20:36 q+ 19:20:44 ... we should probably address this in a use case specific format... like the assurance example and evidence... in person, IAL... etc... we should be more specific 19:21:18 ... are "evidence" and "revocationStatus" metadata? 19:21:35 ack kristina 19:21:47 ... can't tell if this applies to other metadata properties not associated with assuancee 19:22:23 kristina: was thinking mostly about trust frameworks, government and finance use cases... passport was used to verify the claims, etc... 19:23:00 q+ 19:23:04 ... evidence seem like the correct place, but there is a vocabulary for assurance that the UK refers to... and the question is how to levegage / integrate the UK vocabulary with the W3C evidence vocabulary. 19:23:14 q+ nadalin 19:23:36 oliver: I was involved in some projects related to this... european ssi framework... they have their own context and schemas, and they use evidence. 19:23:46 ack oliver 19:23:57 ... they cover, what did the issuer verify prior to credential issuance. 19:24:12 ... I think folks would want to define their own evidence type and register it. 19:24:22 +1 to oliver 19:24:32 Yes, exactly what Oliver just said -- +1 19:24:36 ... people need to evidence type to understand the evidence and the vocabulary it relies on 19:24:39 ack Logan_Porter 19:24:42 @manu will update the issue to clarify what is meant by metadata in the issue 19:25:06 logan: I think we are talking about 2 different things... the current evidence property is more like where the claims came from. 19:25:17 ... like name came from passport or drivers license. 19:25:35 ... but we are also talking about assurance, which is about how that is checked, in person, remote, etc... 19:25:52 ... we might want to distinguish between these uses of the evidence property. 19:26:01 q+ to respond to Logan -- there are different types of evidence that can be included/provided. 19:26:03 ack nadalin 19:26:33 tony: I think I agree with Logan... there is evidence types and method types. 19:26:36 ack manu 19:26:36 manu, you wanted to respond to Logan -- there are different types of evidence that can be included/provided. 19:26:59 manu: the evidence property is currently any information that the issuer can include to help the verifier decide. 19:27:27 ... I see this as 2 entries in the evidence property, one speaking to IAL, the other speaking to trust framework. 19:27:43 q+ 19:27:44 ... authenticators are another type of evidence 19:27:51 ack oliver 19:28:12 oliver: I wanted to add that folks should define their own evidence types as needed by their trust framework 19:28:13 yep, +1 Oliver 19:28:20 +1 19:28:33 subtopic: https://github.com/w3c/vc-data-model/issues/887 19:29:02 selfissued_ has joined #vcwg 19:29:12 brent: what is the action taken to produce a verifiable presentation 19:29:18 manu: there are options... 19:29:37 how about: you create a presentation and then you present it :) 19:29:39 ... we could use the word "create", "issue", "prepare", "present", "assemble", "prove" 19:29:41 q+ 19:29:56 ... I don't like issuing a presentation, or signing... 19:30:03 -1 to issuing a presentation 19:30:10 -1 to issuing a presentation 19:30:10 ... preparing / assembling ... 19:30:12 ... maybe 19:30:20 collate 19:30:22 ack Orie 19:30:29 Orie: I don't like "prepare", because that's the step before protecting. 19:30:41 "consenting a verifiable presentation" 19:30:48 Orie: I think what we're trying to define here is the verb to define the act of "protecting", not "getting ready to protect". 19:31:28 q+ 19:31:29 Orie: For some presentation formats, I like the word "prove", if you're talking about something like a Zero Knowledge Proof... so kinda like proving. also don't like presenting... agree with -1 on issuing, also -1 to signing 19:31:35 Orie: That's all I can say at present. :) 19:31:40 ack oliver 19:31:53 oliver: i agree, but maybe also generating... 19:32:04 yeah, I think I'm -0.5 to "proving" 19:32:06 ... I disagree with proving... because a presentation does not require a proof. 19:32:17 ... proof is not implied when presenting. 19:32:19 I do like "generate" 19:32:20 +1 oliver 19:32:24 -1 to proving ... it's a great word for when it happens, but it doesn't always happen :) 19:32:47 Ted: compose and then optionally sign, deliver, present, submit 19:32:51 i like generate because the product is unique 19:32:53 q+ 19:32:57 ack manu 19:33:28 q+ 19:33:31 manu: generate? 19:33:33 ack Orie 19:33:36 create, generate, and compose seem ok to me 19:34:00 Orie: I would want to be able to tell if the thing produced by the verb is secured or not, I don't think we should use the same word for both of them. 19:34:41 Orie: I think the definition of a verifiable presentation is broken, it's not clear if it's secured or not, I could live with "prepare" or "assemble" for unsecured version, but I don't want to use the same term for the unsecured vs. secured version. 19:34:59 brent: thats 5 minutes of bikeshedding 19:35:07 subtopic: https://github.com/w3c/vc-data-model/issues/890 19:35:22 brent: david can you walk us through this? 19:35:56 davidchadwick: thanks for reminding me... there are various ways in which selective disclosure can be done... 19:36:08 ... there are new ways being invented with for example, sd-jwt. 19:36:18 zakim, who is here? 19:36:18 Present: Orie, brent, cabernet, kristina, dwaite, selfissued, kdeangs, dlongley, manu, at, conference, TallTed, Kerri_Lemoie, oliver_terbu, Logan_Porter, DavidC 19:36:21 ... dynamic credentials or atomic credentials. 19:36:22 On IRC I see selfissued_, Steve_C, DavidC, Logan_Porter, oliver, Kerri_Lemoie, SamSmith, kdeangs1, kristina, dwaite, Orie, cabernet, RRSAgent, Zakim, brent, TallTed, dlehn1, dlehn, 19:36:22 ... bigbluehat, hadleybeeman, stonematt, dlongley, manu, Mike5Matrix, Github, shigeya, cel[m], rhiaro, cel, juancaballero 19:36:37 present+ butters 19:36:37 ... that the verifier gets, might not be a complete verifiable credential 19:37:00 ... you might not get the full details of the credential... and the schema may have mandatory or optional attributes 19:37:14 q+ 19:37:14 present+ dmitryz 19:37:23 ... this createsa conflict for the RP, they can't match to the schema... if the required properties are not disclosed. 19:37:39 ... one solution would be to say all attributes are optional. 19:37:46 q+ 19:37:52 q- later 19:37:59 regrets+ 19:38:03 ack Logan_Porter 19:38:08 ... I would like for us to clarify this issue with schemas and required attributes vs selective disclosure 19:38:11 Claims (attributes, etc.) that are required by the verifier must be in the presentation. Selective disclosure that leaves out what the verifier requires will be refused or denied or whatever verb. 19:38:31 present+ Nadalin 19:38:39 logan: you want to validate as much as you can... I don't think there should be any requirement to check the schema. 19:38:49 ... sounds like an imp guide thing. 19:38:52 present+ SamSmith 19:39:29 davidchadwick: example, I want to see bank account details from a university degree credential... assuming I got an answer... what should the RP do? 19:39:43 logan: seems the credential would be contradicting the schema 19:40:02 ack manu 19:40:03 ... what is requested, vs what is observed... 19:40:07 q+ 19:40:14 q+ 19:40:25 manu: several layers... first one is when the issuer issues the credential, are they stating mandatory and optional... 19:40:35 ... with bbs, that can happen at 2 layers. 19:41:04 present+ juancaballero 19:41:07 ... the issuer can demand required reveleations either at the credential schema layer... or in the lower cryptography layer. 19:41:15 q? 19:41:25 ... it is possible that this constraint might be enforced by both 19:41:39 ... I think we need to look at a concrete example to speak more directly on this. 19:42:01 ... the issuer must understand requirements... and then they get to decide how they want to signal this to RPs 19:42:09 q+ 19:42:10 ... we need an example of a concrete problem. 19:42:17 ack TallTed 19:42:34 Ted: I think that those mandatory fields are mandatory for issuance, not presentations. 19:42:43 ... consider the use of a passport for proof of age 19:42:59 ... the holder needs to prove age over minimum, not visa stamps or country of origin. 19:43:15 ... they only need your picture and date of birth 19:43:41 ... the verifier / rp may have requirements... and they may reject a presentation that does not include a mandatory field, such as picture 19:43:49 ack SamSmith 19:44:14 Verifiers can also chose NOT to use the credentialSchema. 19:44:29 sam: we solve this in ACDC with composable schema... the issuer can create a schema in such a way that the holder can present valid combinations... using anyOf and oneOf 19:44:50 ... this allows the issuer to lock down the schema at presentation level. 19:45:08 ... this avoids some of the complexity, where the presentation can be anything you want. 19:45:23 ... we use composable schemas to solve this 19:45:30 ack DavidC 19:45:56 davidchadick: what I understand is that maybe we need a seperate field for presentationSchema... instead of credentialSchema. 19:46:18 ... maybe the presentation schema, is more useful than the "issuance schema"... 19:46:19 q+ 19:46:20 q+ 19:46:26 ack manu 19:46:47 https://trustoverip.github.io/tswg-acdc-specification/draft-ssmith-acdc.html 19:47:00 q- 19:47:08 manu: I am concerned that we know of a few selective disclosure schemes, that define that schema at the cryptographic layer... and thats were it belongs, because you want to enforce 19:47:10 Does the verifier specify what they want to see in the presentation? 19:47:15 https://github.com/trustoverip/tswg-acdc-specification 19:47:26 q+ 19:47:33 ... it looks like folks are putting these in the crypto layer, and that we don't need presentationSchema then. 19:47:36 ack DavidC 19:47:40 q+ brent 19:48:05 q+ 19:48:07 q+ 19:48:11 davidchadwick: if we have advanced crypto, maybe that works, but it we are using vanilla crypto, it might be more valuable 19:48:32 ... today, we say that it can be the description of the content or it could have to do with the ZKP. 19:48:45 ack brent 19:48:47 ... we seem to need a way to distinguish if the schema is for the content, or the crypto used. 19:49:01 +1 19:49:20 brent: this seems like the verifier presentation defintion... which is the schema the verifier is requring. 19:49:22 q+ to note that you can't remove fields if you're using conventional cryptography, by design. 19:49:36 davidchadwick: this would be set by the issuer, not the verifier 19:50:10 ack Logan_Porter 19:50:22 ... this would allow the issuer to require the presentation of points, and a verifer who know the holder was attempting to hide info from the verifier. 19:50:31 or "constrain" the presentation 19:50:42 logan: I think there is a danger of having the issuer control the presentation 19:50:45 +1 to the danger in allowing the Issuer to constrain the presentation 19:51:07 ... I think its dangerous to have the issuer mandate presented fields. 19:51:17 Holder: "I want in. What do you need to know about me in order to let me in?" Verifier: "Present proof of age." or "Present proof of membership." or "Present proof of security clearance." Holder: composes Presentation with relevant attributes from relevant VCs; signs the composed Presentation; Submits Presentation. 19:51:26 ... the verifier can always ignore content they are not interested in 19:51:31 q+ 19:51:37 devil's advocate: verifiers opt in to listening to/carrying what the issuer wants, i suppose? 19:51:47 ack oliver 19:51:49 q- 19:51:56 https://github.com/w3c/vc-data-model/issues/839 19:51:59 oliver: question, is this issue related? 19:52:02 q+ to overrun closing time with comment posted to chat 19:52:18 oliver: can we close or label duplicates? 19:53:15 davidchadwick: I don't think they are exactly the same... The verifier is in control of verification... and then applying business rules 19:53:16 ack DavidC 19:53:32 @Logan This is why we use composable Schema in ACDC. The Isuer can constrain the schema used in presentation but still allowing approapriate levels of flexibility to the presenter to pick from the allowed compositions what it wants to present. Typically its the degree of desiclosure that is relevant so its clear what to compose. 19:53:36 ... the verifier can ignore the verification if it wants to. 19:53:49 ... my proposal is for the verifier to see the rules... 19:54:02 @DavidChadwick Composable schema precisely solve the probleml you describe 19:54:05 ... if the verifier cannot see the issuer's rules, it can't know how to decide to ignore things 19:54:06 ack TallTed 19:54:06 TallTed, you wanted to overrun closing time with comment posted to chat 19:54:14 TallTed: I don't understand 19:54:50 ... the holder says: I want in, what do you need?... the verifier says: present proof of age / attributes or full VCs, signs them, or presents it... 19:54:58 ... then the verifier decides if its enough or not. 19:55:06 ... they either let you if or they don't 19:55:23 ... I don't see that this needs more schema 19:55:24 this sounds like a use case where the verifier *also* "wants to know" if the presenter is complying with some terms of use that the issuer demands 19:55:34 ^^ 19:55:37 (regardless of what those terms of use are) 19:55:38 well-put, dave! 19:55:54 we need to separate verification from validation. This conversation is about the former 19:56:42 zakim, end meeting 19:56:42 As of this point the attendees have been Orie, brent, cabernet, kristina, dwaite, selfissued, kdeangs, dlongley, manu, at, conference, TallTed, Kerri_Lemoie, oliver_terbu, 19:56:45 ... Logan_Porter, DavidC, butters, dmitryz, Nadalin, SamSmith, juancaballero 19:56:45 RRSAgent, please draft minutes 19:56:45 I have made the request to generate https://www.w3.org/2022/08/31-vcwg-minutes.html Zakim 19:56:47 I am happy to have been of service, brent; please remember to excuse RRSAgent. Goodbye 19:56:51 Zakim has left #vcwg 19:56:57 rrsagent, bye 19:56:57 I see no action items