18:44:07 RRSAgent has joined #vcwg 18:44:12 logging to https://www.w3.org/2023/10/11-vcwg-irc 18:44:16 Zakim has joined #vcwg 18:49:45 brent has changed the topic to: VCWG Agenda 2023-10-11: https://www.w3.org/events/meetings/36ecd2da-2ec3-4012-b74a-72546ab352f4/20231011T150000/ 18:49:55 zakim, start the meeting 18:49:55 RRSAgent, make logs Public 18:49:57 please title this meeting ("meeting: ..."), brent 18:50:12 meeting: Verifiable Credentials Working Group teleconference 18:50:20 chair: Brent Zundel 18:53:23 present+ 19:00:50 DavidC has joined #vcwg 19:00:56 present+ 19:01:27 present+ 19:03:05 andres has joined #vcwg 19:03:16 present+ 19:03:33 GregB has joined #vcwg 19:03:39 present+ 19:06:31 present+ 19:08:26 dmitriz has joined #vcwg 19:09:19 manu_ has joined #vcwg 19:09:27 present+ 19:09:48 kristina has joined #vcwg 19:10:00 Present+ 19:10:04 scribe+ 19:10:07 present+ 19:12:15 brent: Our agenda is pretty straightforward. 19:12:21 brent: We will begin with a CR resolution update. 19:12:55 brent: We did a resolution to go into CR for Data Integrity, DI + eddsa, DI + ecdsa, VC JSON schema, and we passed a resolution to do that and process has been satisfied but the date needs to change. 19:13:44 +1 19:13:48 +1 19:14:13 PROPOSAL: We set the publishing date for CR for VC Data Integrity, VC DI EDDSA, VC DI EDDSA, and VC JSON Schema to November 7, 2023 19:14:17 dlongley: +1 19:14:21 +1 19:14:22 +1 19:14:24 +1 19:14:24 +1 19:14:27 +1 19:14:28 +1 19:14:52 RESOLVED: We set the publishing date for CR for VC Data Integrity, VC DI EDDSA, VC DI EDDSA, and VC JSON Schema to November 7, 2023 19:15:03 Topic: PRs 19:15:09 q+ to cover outstanding PRs... 19:15:46 https://github.com/w3c/vc-data-model/pulls 19:16:01 manu: Just wanted to cover some of the DI PRs. To give an update. 19:16:04 brent: That is fine with me. 19:16:06 https://github.com/w3c/vc-data-integrity/pull/196 19:16:37 subtopic: https://github.com/w3c/vc-data-integrity/pull/196 19:16:42 manu: Mike Jones had requested that we normatively define a number of things in multibase/multihash. The changes have been to define how base encoding works and provide algorithms for base encoding and decoding and specifically provide the alphabets for the bases used. 19:16:52 manu: Those are the updates and changes and that has gone into PR #196. 19:17:27 manu: I believe I have addressed every single one of Mike Jone's requests and questions and AFAICT everything is normatively defined. The hope is to get his review in and get this PR in before Nov 7. 19:17:56 brent: Merge it. 19:18:02 brent: Mike has approved. 19:18:08 subtopic: https://github.com/w3c/vc-di-eddsa/pull/63 19:18:11 manu: That is the basis for the other two PRs. 19:18:24 https://github.com/w3c/vc-data-integrity/pull/196 19:18:37 manu: PR #63 builds on PR #196. My presumption there is if Mike is good with 196, he's good with the others that refer to it. 19:18:45 manu: He has +1'd that as well. 19:18:49 subtopic: https://github.com/w3c/vc-di-ecdsa/pull/42 19:18:53 manu: I see he's approved the last remaining well as well. 19:19:03 manu: That is great, that unblocks us across the board for all DI and cryptosuite specs. 19:19:10 manu: That's that item, we can shift back to VCDM. 19:19:26 brent: There are a lot of VCDM PRs. 19:19:26 q+ 19:19:35 q- 19:19:55 subtopic: https://github.com/w3c/vc-data-model/pull/1308 19:20:38 manu: Orie raised this to remove the Data Integrity proofs from the initial examples. It has multiple positive reviews, I will probably +1 this as well. There is an open question here, which is, we have examples in the specifications that show how later examples are secured using both DI and, in theory, VC-JOSE-COSE. 19:20:55 manu: The general question to the group is: Do we want to continue to do that. One of the complaints that we had early on is that we want complete examples. 19:21:14 manu: Agree that example 1 is probably the wrong place to put that, but do we want examples throughout the spec to show how to secure in at least two different ways. 19:21:43 brent: It makes sense to me, to remove the `proof` property in earlier examples and adding it later to show using it with DI. Particularly because those later examples can be done along side showing VC-JOSE-COSE securing mechanisms as well. 19:21:43 I think examples will be very good for future readers 19:21:48 dlongley: +1 to brent 19:21:58 q? 19:22:00 dlongley: +1 for having full examples in the spec eventually 19:22:05 +1 to having at least /some/ examples in the spec of fully verifiable VCs.. 19:22:11 dlongley: but not having them be the very first one. 19:22:20 brent: Anything more to discuss on that PR? 19:22:29 brent: As long as there remain from DI examples we're good? 19:22:30 as long as we clearly label it as "Unsigned/unsecured input document" or something similar 19:22:34 brent: I'll keep going. 19:22:40 subtopics: https://github.com/w3c/vc-data-model/pull/1305 19:22:56 brent: This PR removes the CL signature example, which though this makes me sad, it makes sense. I will probably +1 this one myself. 19:23:08 brent: Urge folks to review as well. 19:23:08 q+ 19:23:31 ack manu_ 19:23:53 manu: Yeah, this PR will probably go in because we don't have examples of CL signatures today. I will note that Greg Bernstein has raised PRs on the VC-DI-BBS specification to define it using the new format. 19:24:13 manu: My expectation is that if we do get BBS in decent enough shape we can reinject an unlinkable signature into this part of the specification. That's my expectation. 19:24:17 dlongley: +1 to that expectation 19:24:27 q+ 19:24:38 brent: That's my understanding as well. We're hoping that folks can step up and serve as the example as the way to do this with ZKP. 19:24:41 ack GregB 19:24:49 GregB: That's looking in pretty good shape. 19:25:06 GregB: I raised some issues using the ECDSA-SD primitives -- I was able to reuse the ones from that spec. 19:25:18 GregB: I tried it on VC-DI-BBS and it looked good. 19:25:33 GregB: Along with using JSON pointers to specify mandatory and selective fields. 19:25:57 GregB: I went through the whole exercise of putting BBS together with the SD primitives (core functions) and adding a bit to ensure unlinkability. 19:26:07 dmitriz has joined #vcwg 19:26:11 GregB: The editors are kind of changing, so there are no reviewers on that PR but I'd like to get people to look at things. 19:26:15 q- 19:26:25 q? 19:26:32 brent: Thank you Greg, my hope is that as we move on from the other items as they go into CR we can spend more time on BBS (VC-DI-BBS). 19:26:49 subtopic: https://github.com/w3c/vc-data-model/pull/1304 19:27:09 brent: This is some editorial clean up submitted by Orie, a number of approvals already, fixing references. 19:27:20 brent: I expect this to just be merged relatively quickly, happy to take comments if any. 19:27:21 q+ 19:27:30 q- 19:27:47 subtopic: https://github.com/w3c/vc-data-model/pull/1302 19:28:12 brent: A proposal for better JSON-LD processing text. It has an approval and a bunch of comments. There's been quite a bit of conversation here. 19:28:21 q+ 19:28:21 q+ 19:28:29 ack manu_ 19:29:28 manu: Yeah, so I think around 80% of the text is good. These are good modifications to make. It's clear that people don't like the "JSON processing" terminology so we're trying to say you don't have to do "full blown JSON-LD processing" and still be ok. The 20% of the text is being debated in the PR. 80% is good clarifications to make, we need to get to consensus on the 20%. 19:29:37 scribe+ 19:29:38 manu: All kinds of concrete suggestions I made there. 19:29:42 ack dlongley 19:30:04 dlongley: I feel similarly, there are some good improvements here, good suggestions made by others, would like to see others changes pulled in. 19:30:42 dlongley: One of the big things out of this PR is that talking about "JSON Procesisng" and "JSON-LD Procesisng" is problematic, beecause those terms mean different things to different people. If we can avoid using that terminology, and just talk about specifics on consuming data, that would be best. 19:30:51 dlongley: Some text suggested in this PR would help us get there. 19:30:55 scribe- 19:31:16 brent: Not seeing anyone else on the queue, next steps would be Orie jumping in and accepting suggested changes or continuing the conversation there. 19:31:22 brent: This PR looks to be in a decent spot. 19:31:35 subtopic: https://github.com/w3c/vc-data-model/pull/1298 19:31:52 brent: This PR removes the "JSON processing" section. There's been some conversation. There has been request for changes. 19:31:53 q+ 19:32:03 brent: Looking for conversation here to see it move forward. 19:32:04 scribe+ 19:32:06 ack dl 19:32:09 ack dlongley 19:32:42 dlongley: This PR is an alternative to the one we discussed, I don't expect this PR to go in, if we get good consensus text on the other PR we just discussed. The other PR would be better for understanding what people would need to do. 19:33:02 brent: If the other PR goes in, this one gets closed? 19:33:06 dlongley: That's my expecation. 19:33:19 subtopic: https://github.com/w3c/vc-data-model/pull/1297 19:33:21 brent: Joe has a response to an open issue. 19:33:28 brent: This updates the language in the spec around validation. 19:33:37 brent: There has been conversation, suggested changes that aren't in yet. 19:33:52 brent: There's at least one person that has approved it, we perhaps need more review. 19:34:13 q+ 19:34:14 q+ 19:34:22 ack dlongley 19:35:09 q+ 19:35:15 dlongley: I haven't had enough time to look at this one, initial scan seems to add normative requirements around statements that are not testable... Verifiers must validate claims, that's usually done via business rules... validate using included business rules... we'll need to adjust that language in some way... not something an implementation can do... you might need to use your own business rules. 19:35:24 dlongley: Need to get clarity on verification vs. validation. 19:35:27 ack manu_ 19:35:36 s/Need to/Appreciate the effort to/ 19:36:05 manu: The only concerning bits of the PR are around normative statements around validation. I know Jeffrey Yaskin wanted us to specify verification algorithms, but validation is a bridge too far. 19:36:24 manu: There are multiple statements in this PR that say things like "verifiers MUST validate claims in VCs" which, again, is not testable. We don't want to get into validation rules. 19:36:29 ack manu_ 19:37:07 q+ 19:37:14 brent: I agree with that. I wanted to ask if the normative text here might be ... one of the suggestions made was that we more clearly define conformance rules. We could say "a conformant consumer of a VC... ought to do", whether and how that language would be normative around that is a another discussion. 19:37:40 ack brent 19:37:44 brent: Perhaps putting this into conformant producers and consumers of the document is a step we could take. "Here's this data model and if you want to do something with it, here are some rules around that". It might be helpful if we went there. 19:37:46 ack manu_ 19:38:25 manu: One approach we could take there is the approach we took in the DID spec for DID method spec authors. We had normative statements around what DID specs must do -- I think Jeffrey Yaskin's review also covered that there are conformance classes in the spec that we don't define like conforming issuer/verifier. 19:38:40 +1 that's what I was getting at 19:39:02 manu: I think that's what you were getting at Brent, so we could have sections in the spec about what a conforming verifier must or should do and hand wave over that and say -- while those statements are normative, we're just saying what's expected from the conformance class, now how to do it but that one must do it. 19:39:17 manu: That might allow us to write normative statements and that we don't have entries for that in the test suite because it's general guidance. 19:39:31 dlongley: it's "business rules", not something a generic implementation would do 19:39:45 manu: Saying it outloud sounds problematic ... that's somewhere to try and go though. 19:40:21 brent: For this PR advice would be to get rid of normative language, recognizing that moving forward with conformance on issuer/verifier roles we might need some "more normative" language and that might not be testable, but separate PR for that. 19:40:22 +1 to approach brentz suggested. 19:40:35 subtopic: https://github.com/w3c/vc-data-model/pull/1296 19:40:50 brent: One approval, a bit of explanation from Ivan. 19:41:02 brent: This feels like a PR that just should be merged ... to me, but happy to hear otherwise. 19:41:26 brent: I'm not hearing otherwise, encourage folks to jump on, review and approve to get it in. 19:41:26 +1 to this PR 19:41:41 subtopic: https://github.com/w3c/vc-data-model/pull/1295 19:41:45 q+ 19:42:03 brent: Raised by David Chadwick to add examples of terms of use. A number of suggested changes that folks have made, not clear if those changes have been addressed. 19:42:14 brent: A number of reviewers requested changes. Let's talk about this PR a bit. 19:42:22 q+ 19:42:32 ack DavidC 19:42:39 DavidC: So I have made all the changes that people have requested and I have re-requested reviews. 19:42:45 DavidC: There is one issue that I couldn't resolve. 19:43:24 DavidC: Previously I had a reference that I changed to an informative reference, I couldn't figure out where the informative references are held ... I can actually add it properly. 19:43:31 ack manu_ 19:43:36 DavidC: If someone tells me what to do. 19:43:57 manu: There's something at the top of the document or in a file called biblio.js -- look there. 19:44:04 DavidC: Ah, I didn't look there. 19:44:11 DavidC: It's just JavaScript? 19:44:13 manu: Let me check. 19:44:25 manu: It's in a file called "common.js". 19:44:35 manu: If you add your link there, it will show up in the spec. 19:44:38 DavidC: Ok, got it. 19:44:43 DavidC: Thanks, I can sort it now. 19:44:51 DavidC: I'll push that in another PR today or tomorrow. 19:45:40 manu: I think Kristina is concerned that this PR doesn't address -- the issue associated with this PR, there are two parts. One is to use a more accurate example, and that is done. We also wanted to demonstrate that this is broadly used and deployed and said so in the comments but Kristina's concern was that we're still not very clear when you use terms of use or how to use it. 19:45:47 q+ 19:45:55 manu: I'm wondering if we can deal with that in another PR or if you can address that here, David. 19:46:11 ack DavidC 19:47:07 DavidC: So I have altered the text. The original text was generic, and just before the CR or after ... we put more text in around mandatory requirements. That then, throughout the whole of the text ... the text before that was put in was very generic. What I'd done is I've now created a couple of examples in generic examples to say "it may be either of the following", it doesn't pin down that terms of use must have these three prohibitions or 19:47:07 whatever. 19:47:17 DavidC: It wasn't an example before and now it's an example. 19:48:13 DavidC: It still has that in the second example now. The whole shift in version 1 and version 1.1 was skewed ... from the original terms of use to now go back to the original text to become more generic, so the prohibition stuff is now in an examples. We have an example where the issuer has to conform to terms of use and another example for a holder with prohibitions. 19:48:34 DavidC: If Kristina can come back and say what else to change if more is needed that would be good. 19:48:41 brent: I see last week Kristina put herself to re-review. 19:49:02 brent: Next step is review from Kristina and other folks, particularly those that have requested changes to see if their requests have been addressed or not. 19:49:09 brent: Kristina, Orie, Manu are some names here. 19:49:13 brent: Any other comments? 19:49:30 brent: We will skip 1294 because if 1295 gets merged then 1294 will be closed. 19:49:44 subtopic: https://github.com/w3c/vc-data-model/pull/1286 19:50:09 brent: Privacy considerations around issuer location. Raised by Gabe to address an issue -- specifically calls out for review from TallTed. 19:50:14 brent: I think we got that. 19:50:26 brent: Any comments folks want to make -- seems to be a straightforward PR to review and merge. 19:51:01 subtopic: https://github.com/w3c/vc-data-model/pull/1279 19:51:08 q+ 19:51:11 brent: Raised by Manu. 19:51:16 ack manu_ 19:51:21 manu: I don't know what to do with this PR just yet. 19:51:58 manu: It felt like Kristina, Orie, and Ivan were asking for some irreconcilable things, I imagine we need the three of them on the call to figure out what to do here. I think Kristina and Ivan might be agreeing to remove the schema.org stuff -- I can't tell if Orie would be ok. 19:52:11 manu: I think that's where we are ... some concrete text from Orie could resolve this or time on a call to discuss. 19:52:16 brent: Thank you, Manu. 19:52:51 brent: We're at the point of trying to get to CR, with a PR like this, it's been raised, people have come back and say "I don't like it, I want changes" ... we're running out of time for back and forth. We don't have time for requests for changes, review of that, responses to that, responses to those responses, etc. 19:53:20 brent: This group will need to decide soon on a shifting of our work mode to move through these things. If a PR doesn't gain consensus quickly we will have to look at just closing it if we don't have the capacity to address it. 19:53:31 brent: Having soapboxed for a moment there, let's jump into 1276. 19:53:38 subtopic: https://github.com/w3c/vc-data-model/pull/1276 19:54:02 brent: Guidance for the use of compact terms and types rather than full URLs. I know this is related to the light processing PRs. 19:55:07 manu: There's an issue raised to provide clear guidance on using compact terms vs. full URLs. I think Orie is saying that this PR doesn't address this issue and it might be better address in the value of JSON-LD PR. I don't know what is needed to make it so that Orie is ok with it. It is a PR that would be closed because we couldn't get to consensus. 19:55:26 brent: Thank you, Manu. We're at time for the meeting. Appreciate folks joining, kinda crazy with people at IIW, etc. 19:55:35 brent: Thank you for scribing, Dave, thanks for all the work people have done, see you later! 19:55:45 zakim, end the meeting 19:55:45 As of this point the attendees have been brent, DavidC, dlongley, andres, GregB, dlehn, manu_, kristina, dmitriz 19:55:47 RRSAgent, please draft minutes 19:55:49 I have made the request to generate https://www.w3.org/2023/10/11-vcwg-minutes.html Zakim 19:55:56 I am happy to have been of service, brent; please remember to excuse RRSAgent. Goodbye 19:55:56 Zakim has left #vcwg 19:56:03 rrsagent, bye 19:56:03 I see no action items