19:49:10 RRSAgent has joined #vcwg 19:49:15 logging to https://www.w3.org/2024/01/17-vcwg-irc 19:49:38 brent has changed the topic to: Meeting Agenda 2024-01-17: https://www.w3.org/events/meetings/36ecd2da-2ec3-4012-b74a-72546ab352f4/20240117T150000/ 19:59:52 zakim, start the meeting 19:59:52 RRSAgent, make logs Public 19:59:54 please title this meeting ("meeting: ..."), brent 20:00:19 meeting: Verifiable Credentials Working Group weekly teleconference 20:00:25 chair: Brent Zundel 20:00:46 present+ 20:01:21 steele has joined #vcwg 20:01:27 Wes-smith has joined #vcwg 20:01:33 present+ 20:02:03 present+ Wes-smith 20:03:04 present+ 20:04:07 decentralgabe has joined #vcwg 20:04:11 present+ 20:04:16 scribe+ 20:04:46 present+ 20:05:11 brent: Welcome to the VCWG meeting, agenda is work item status updates and PRs that Editor's want us to look at. We'll jump into issue post-CR issue processing next. 20:05:22 brent: We'll do some triage as well. Any changes to agenda? 20:06:03 Topic: Work Item status updates/PRs 20:06:05 brent: Let's do work item status updates. 20:06:07 q+ 20:06:09 q+ 20:06:10 scribe+ 20:06:17 ack manu 20:06:36 manu: Real quick run down. VCDM has no PRs open... 20:06:39 https://github.com/w3c/vc-data-model/pulls 20:07:08 manu: No PRs open, the request to CR went in early this week. PLH / team will process probably on Friday, we'll look at that on Monday for any possible changes. 20:07:19 https://github.com/w3c/vc-specs-dir 20:07:33 qq+ to clarify VCDM PRs 20:07:39 manu: The vc-specs-dir will be published as a NOTE that can be updated continuously and the VCDM will be published as CR. 20:07:58 https://github.com/w3c/vc-data-integrity/pulls 20:08:01 manu: The other items are the DI specs ... those are in CR now. There are no real big PRs open. There are two to look at. 20:08:17 manu: One big change we have to make to VC-DI around the interface Jeffrey Yaskin wanted us to spec out. 20:08:20 https://github.com/w3c/vc-di-ecdsa/pulls 20:08:36 https://github.com/w3c/vc-di-eddsa/pulls 20:08:39 manu: There continue to be ... looking at the other cryptosuites. ECDSA has two PRs that Greg has raised, nothing major, take a look. 20:08:46 `EDDSA` doesn't have anything. 20:08:51 https://github.com/w3c/vc-di-bbs/pulls 20:08:54 s/`EDDSA`/manu: `EDDSA` 20:09:08 manu: There are PRs to look at, 11, on VC-DI-BBS as we do implementations on it. 20:09:18 manu: Digital Bazaar has an implementation independent from Greg's that we're working on. 20:09:30 manu: For ECDSA we have 5 implementations there. 20:10:05 manu: We're trying to get the test suites aligned, getting all the statements in, etc. There's a bit of change between the VCDM and VC-DI that is requiring us to update the test suites. We have new implementers incoming, finding out about new ones every week or so, that's good. 20:10:10 present+ 20:10:12 https://github.com/w3c/vc-bitstring-status-list/pulls 20:10:46 manu: Finally BitstringStatusList ... we were going to be done with it and go into CR, but we found out that unfortunately the horizontal reviews weren't filed for security and others, we only filed for TAG, we thought we filed back in June. 20:10:54 manu: Unless we're missing something here, we need to file those. 20:11:08 manu: It could take 3 months to get those reviews back, we'll ask nicely to try and get them sooner. 20:11:27 manu: If not, BitstringStatusList will be in limbo until then. We will probably ask implementers to implement anyway as it seems feature complete and we're done. 20:11:39 manu: Hopefully when we get into CR we'll have multiple independent implementations already. 20:11:46 brent: Thank you Manu. 20:11:47 ack brent 20:11:47 brent, you wanted to react to manu to clarify VCDM PRs 20:11:49 present+ 20:11:51 scribe- 20:11:56 pdl-ASU has joined #vcwg 20:12:08 present+ 20:12:11 brent: There are a couple of PRs open on core data model, they have yet to find consensus and are really out of date, I marked both of them pending close today. If those PRs are things you'd like to engage with, please do. 20:12:17 ack decentralgabe 20:12:43 https://github.com/w3c/vc-jose-cose/pulls 20:12:57 decentralgabe: An update on vc-jose-cose, meeting at end of last week to process all issues opened with thanks to Ivan and Manu for detailed review. Mike's out this week in Japan for a conference. There are some PRs opened, more PRs in next week, we'll keep going through those issues. Hoping to get them wrapped up before the end of the month. 20:13:25 brent: Great, thanks for that update. Anything else on updates? 20:13:26 q+ 20:13:34 scribe+ 20:13:35 ack manu 20:13:50 manu: I think everyone ... there was an email that went out about this and there's a Privacy WG charter up for vote that will presumably cover quite a bit. 20:14:25 manu: The Privacy group has an interest in the work we're doing here and would like to engage with and have commentary on the stuff we do here in a deeper capacity. I think it's a great idea for W3C to have an official Privacy WG. I suggest W3C members go and vote and provide input on that charter. 20:14:26 scribe- 20:14:36 Topic: VCDM Issue Processing 20:14:37 brent: Yes, check it out if you haven't yet. 20:14:53 subtopic: https://github.com/w3c/vc-data-model/issues/1410 20:14:56 brent: We're going to start with a non-triaged issue. 20:15:14 brent: Is this something we feel is an issue that needs to be addressed, if so, who is going to work on it? 20:15:33 q+ 20:15:48 scribe+ 20:15:48 ack manu 20:16:00 manu: Yes, I can provide insight but Jeffrey is here too. 20:16:28 manu: We're trying to provide guidance on things that ... people who extend the data model and write specifications about credentials, like specific types of credentials like driver's licenses, passports, coupons, whatever. 20:16:31 zakim, who is here? 20:16:31 Present: brent, steele, Wes-smith, manu, decentralgabe, dlongley, dlehn, jyasskin, pdl-ASU 20:16:35 On IRC I see pdl-ASU, decentralgabe, Wes-smith, steele, RRSAgent, Zakim, brent, Jem, csarven, KamirKami, shigeya, dlehn, matrix638, enick_708, cel, AnthonySpencer, jyasskin, manu, 20:16:35 ... Github, npd, bumblefudge1, seabass, MojGraph, saysaywhat, bumblefudge, ounfacdo, cel[m], joraboi445, SintayewGashaw, cel[h], w3c_modbot, ivan, rbyers, dlongley, hadleybeeman, 20:16:35 ... stenr, bigbluehat, rhiaro 20:16:46 q+ 20:17:29 present+ dmitriz 20:17:34 manu: I think Jeffrey's concern was that there are times when it's ok using credential type-specific processing and there may times when that's not ok. I think Jeffrey you wanted us to give clearer guidance on that -- on things you should and shouldn't be doing. Like avoid these features / throw errors on this stuff, you should be producing a JSON schema that should be doing xyz and whether the VCDM gives guidance to people writing credential 20:17:34 specs and what they should say about type-specific processing. 20:17:43 s/specs and what/manu: specs and what 20:18:23 ack jyasskin 20:18:24 manu: We give guidance on securing specs and this would give guidance for credential spec writers that say things like "provide a JSON schema for type-specific processors, provide a semantically immutable context, etc." 20:19:06 jyasskin: Yeah, that does basically capture what I'm worried about. My core worry was broader. If you secure something w/ JSON-LD and process it w/ JSON there are footguns, or vice versa, I didn't find attacks but doesn't mean there aren't any. So guidance so people don't write vulnerabilities. 20:19:28 scribe- 20:19:29 brent: It seems like this is something important to work on, is this something that could be handled editorially, or does it require normatie changes? 20:19:30 q+ 20:19:34 ack manu 20:19:35 scribe+ 20:19:54 manu: I'm pretty sure we need normative text. This is normative text for credential specifications. 20:20:27 +1 20:20:32 manu: I think you should argue that the text you could write would not affect software implementations, but it would affect credential spec writers / specs. I think it's arguable. I think we need to write normative text about it, but I don't know how CR is handled with respect to normative text that only applies to specs and not implementations. 20:20:36 manu: That's it. 20:20:41 scribe- 20:21:37 q+ 20:21:47 brent: Yes, I also don't have a good answer there. This is something that shouldn't implement the implementations of the core data model, that's main concern during CR, but would affect implementations for credential type specifications. 20:21:52 ack pdl-ASU 20:21:53 scribe+ 20:22:07 manu: It wouldn't affect securing specs. It would affect credential type specs. 20:22:17 manu: Like IMS global, etc. 20:22:18 scribe- 20:22:37 pdl-ASU: The HR Open standards organization is in the process of trying to move their schema for HR standards, and orgs that use them, into form to issue Verifiable Credentials. This would apply directly to 21 or more JSON objects that are a part of their resume WG's scope. It would be valuable to them. 20:22:39 q+ 20:22:54 ack jyasskin 20:23:17 jyasskin: With respect to HR Open standards specs, I would hope that any requirements in this document either don't affect them, or will point out security concerns that they would like to have pointed out. 20:23:20 +1 Jeffrey 20:23:46 scribe+ 20:24:06 manu: Not opposed, we might want CR-2, CR-3, CR-4 tags to better track this. They might go back and check and we are supposed to highlight in our revision history. 20:24:20 scribe- 20:24:23 brent: Let's create a "CR2" label for this, then. 20:24:26 q? 20:24:30 https://www.w3.org/2023/Process-20231103/#revising-cr 20:24:55 brent: who's willing to take a shot at this issue? 20:25:15 manu: I can take the issue if Jeffrey can help me. 20:25:23 jyasskin: ok, happy to help. 20:25:32 s/to help/to help review./ 20:25:41 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc 20:26:16 brent: The question here -- is this something we need to do? Who will work on it? 20:26:16 subtopic: https://github.com/w3c/vc-data-model/issues/981 20:26:37 brent: This is assigned to you, manu, is this still an issue? 20:26:37 scribe+ 20:26:48 q+ 20:27:00 ack manu 20:27:17 manu: No, unfortunately, it's still in the spec. We do have a CCG credential refresh spec that we can point to. 20:27:29 TallTed has joined #vcwg 20:27:32 manu: I know there are two implementations of the CCG credential refresh mechanism in production around the TruAge program. 20:27:55 manu: The proposal here would be to use that value because that value is in production, would that be enough to address this issue? 20:28:17 brent: Refresh service is a reserved term, not defined? 20:28:19 https://w3c.github.io/vc-data-model/#refreshing 20:28:25 manu: We have a section for it, it's marked at-risk. 20:28:30 manu: it's marked as at-risk. 20:28:39 brent: Unless we can get an equivalent set of specs, then we're going to remove it? 20:28:40 q+ 20:28:44 ack manu 20:29:24 manu: I'm reading the at-risk marker. This feature is at-risk and removed from the spec if at least two independent implementations don't exist by the end of CR. We do have those right now for the extension point and the feature. 20:29:33 manu: So it shouldn't be at-risk anymore, unless I'm misunderstanding something. 20:29:33 present+ 20:29:43 brent: And those are based on the community group thing and what's the status of that? 20:29:53 manu: They might be based on the Conexxus retail standard for TruAge. 20:29:59 manu: Which reuses the CCG spec. 20:30:03 manu: Uses parts of it. 20:30:19 q+ to talk normative pointers 20:30:26 manu: I don't know what we want to do here, the CCG spec continues to exist. I don't know what we want to do here. We haven't been very clear here about what the state needs to be. 20:30:30 ack brent 20:30:30 brent, you wanted to talk normative pointers 20:30:33 scribe- 20:30:39 RRSAgent, draft minutes 20:30:40 I have made the request to generate https://www.w3.org/2024/01/17-vcwg-minutes.html TallTed 20:31:09 brent: It's my understanding that in order to point normatively to another spec, that spec needs to be recognized as relatively mature, but does need to be stable, needs to have link that isn't going to change, etc. 20:31:10 q+ 20:31:14 scribe+ 20:31:23 https://www.w3.org/Guide/process/tilt/normative-references.html 20:32:47 brent: Bar we set as a group, is we have a number of extension points that we wrote into previous versions of the spec, and it was recognized that those extension points were valuable while things were being incubated, and those difficult to test because there are not normative specs to test extension points are one of the things we're hoping to correct in v2. We've done that w/ securing specs, done w/ JSON schema, done w/ other extension points, whether 20:32:47 or not we can claim this appropriate level of interop w/ refresh property is unclear to me. 20:33:10 brent: Getting a bit far afield -- this is editorial -- broader issue about refresh service, open issue, we'll get there. 20:33:10 q+ 20:33:41 ack manu 20:33:51 manu: I don't disagree with any of that. I thought this issue was about the example. 20:34:53 q+ to talk about extension points 20:35:04 manu: +1 to what you said, it feels like we need get clarity ... totally agree that `credentialRefresh`, the CCG spec itself, I don't think you could say it's stable, but the usage is. We would not be able to make any normative reference to the CCG spec at this time. But did we say we had to be able to do that to keep the extension point around in the spec or did we have to just say people are using it in a significant capacity? 20:35:37 manu: I don't remember what we said the minimum bar was, but having a normative spec is certainly at / above that bar. I don't know if that's required vs. a clear signal it's good enough. 20:35:48 manu: This is a bit far afield, maybe there's another issue for this. 20:35:55 scribe- 20:36:24 brent: For this particular issue, I think the plan is to modify the example to something other than ManualRefresh2018, Manu's assigned to make that change. If we're ok w/ that course of action, we can move forward. 20:36:29 ack jyasskin 20:36:29 jyasskin, you wanted to talk about extension points 20:37:31 jyasskin: I think it would be a shame to lose the list of reserved extension points w/o having a link to it. IETF deals w/ this w/ "provisional" registrations. The W3C now has enough processes to have reserved extension points a registry for stuff that's not standardized. 20:37:57 brent: I like that suggestion, so let us keep that in mind as we continue having this discussion. We have a number of "at risk" statements that are tracking this for us. 20:38:18 subtopic: https://github.com/w3c/vc-data-model/issues/1098 20:38:29 s/w/o having a link to it/just because you can't normatively refer to specifications for each one/ 20:39:24 q+ 20:39:26 scribe+ 20:39:41 ack manu 20:39:55 manu: I think what we meant with this text -- this was before we marked things at-risk and had the table of reserved properties... 20:40:31 manu: I think we get rid of the statement "might be more formally defined in future versions" if we remove things from the spec. Either we formally define and have a concrete thing to point to or not -- and not say it might be more formally defined in the future. 20:40:38 q+ to promote registries again :) 20:40:59 manu: Orie said that once we make the vocab normative and so on it might be easier to achieve but that didn't end up happening, we have a normative vocab and context, it doesn't change the fact that we probably shouldn't be saying... 20:41:20 manu: Now that I'm reading this ... in the reserved properties section we say that the properties might be more formally defined in the future. I think we need David. 20:41:22 ack jyasskin 20:41:22 jyasskin, you wanted to promote registries again :) 20:41:25 scribe- 20:42:00 jyasskin: Another case where making this a registry would help you. If this is a registry with some expert review and status column that is provisional/standardized, that by itself implies that they're expected to get more formally defined. Then things can move between different specifications, but registry deals with that for you. 20:42:16 brent: Chair hat off, registries would be a sensible methodology for this WG to engage with. 20:42:17 q+ 20:42:22 ack manu 20:42:46 scribe+ 20:43:10 manu: We have vc-specs-dir and could have extensions put there. We do have a core vocab, but the question is whether anyone can just come along and register in that core vocab and we have to add it to the vocab officially and so on. 20:43:32 manu: Maybe that's ok -- I don't know. A registry would be easy to deal with, I agree, but the other challenge for people who are new, we did define these extension points in 1.1. 20:43:51 https://www.w3.org/2023/Process-20231103/#reg-pub has "Registries can be published either as a stand-alone technical report on the Registry Track called a registry report, or incorporated as part of a Recommendation as a registry section.", so you don't even need to move it to the extensions report. 20:43:54 manu: Some are clearly being used. There's a question around "at what point does it become a part of the core spec". I think we need that other issue to talk about. 20:44:06 manu: +1 to having a registry generally that would be one way of dealing with some of these properties. 20:44:29 scribe- 20:44:31 brent: We could have a "registries" section of the spec, based on what Jeffrey said above. 20:44:39 subtopic: https://github.com/w3c/vc-data-model/issues/887 20:44:52 q+ 20:44:56 scribe+ 20:44:58 ack manu 20:45:12 brent: I would love to close this. 20:45:22 manu: We ran a poll and everything! It's fine though :). We gathered data from this group. 20:45:32 manu: We previously had said ... that you just "create" a presentation and be done with it. 20:45:41 manu: I think both Orie and Oliver were ok with "create" to refer to the action. 20:45:44 +1 for create and move on. 20:45:56 manu: Concrete suggestion is "go with 'create'" define and be done with it. 20:46:30 brent: Chair hat firmly on, if someone wants to come up with a strong opinion about not using "create" right now -- we can go the official route if needed so they can object. 20:46:35 brent: Otherwise, let's just go with "create". 20:46:43 brent: You comfortable with next steps, Manu? 20:46:44 brent: Chair hat on, if you DO NOT want to create, let it be known. 20:46:46 manu: Yes. 20:46:47 scribe- 20:46:55 subtopic: https://github.com/w3c/vc-data-model/issues/942 20:47:21 brent: Is there still clarification around the role of holder that is necessary? 20:47:29 brent: I feel pretty confident about what a "holder" is... 20:47:30 q+ 20:47:33 scribe+ 20:47:40 ack manu 20:47:46 brent: Do we need to do anything or close it? 20:47:49 manu: +1 to close it, don't need more. 20:47:55 scribe- 20:47:59 brent: Anyone on call opposed to pending close? 20:48:25 brent: Hearing no opposition, I'll mark it "pending close". 20:48:32 subtopic: https://github.com/w3c/vc-data-model/issues/1197 20:48:58 brent: I believe everywhere we're saying "public keys" use "verification material"? 20:49:32 brent: There are four instances of "public key" to "verification material" in the spec. 20:50:00 be sure to match all plurals/singulars! 20:50:02 nicksteele: I'll take it. 20:50:19 q+ 20:50:26 ack TallTed 20:50:51 TallTed: Verification Material (singular) everywhere is probably ok. 20:51:05 q+ 20:51:11 scribe+ 20:51:18 ack manu 20:51:40 manu: All this is fine. A couple of suggestions, Nick. We use the word "cryptographic material" for public/private/secret key. 20:52:11 manu: We say "verification material" if it's a public key or some mechanism that verifying some other proof of X (work, time) etc. 20:52:52 manu: For some people it might be weird so we could pull the definition from the VC-DI spec and put it in the VCDM. So we say "when we say verification material, it's anything to verify a proof" that includes public keys, inputs to an algorithm, anything like that. 20:53:01 manu: It doesn't make it that much more difficult and I can help with the PR on how to do that. 20:53:06 scribe- 20:53:12 subtopic: https://github.com/w3c/vc-data-model/issues/926 20:54:00 brent: This was raised by Orie, it is assigned to MikeP, the issue recommends where possible, that we should align w/ NIST definition (and link to it). 20:54:27 q+ 20:54:32 q+ 20:54:34 scribe+ 20:54:34 ack manu 20:54:38 https://csrc.nist.gov/glossary/term/evidence 20:55:03 manu: NIST has a glossary where they define "evidence" and I think it aligns with our usage of it. I don't know if we even ... NIST also has entries in their glossary where they have multiple different definitions. 20:55:34 manu: NIST understands that when they use a word even they are not consistent in how it's used across every document they have. They have all of the definitions cross reference. Luckily with "evidence" there is just one definition and it seems to align. 20:55:42 manu: We could point to the NIST definition but I don't know what that would accomplish. 20:55:50 scribe- 20:55:51 ack jyasskin 20:56:14 jyasskin: Just a suggestion, it seems like one of the "at risk" things that doesn't have a firm spec behind it, could put it in registry entry, don't have to worry about it for this document. 20:56:15 q+ 20:56:22 ack manu 20:56:22 scribe+ 20:56:46 manu: I think this issue is just about our use of the word "evidence", not the extension point. I agree with you Jeffrey for the extension point, but I think this is just about how we use the word. 20:57:13 brent: Of the 30-odd uses of the term, only two are related to the extension point. 20:57:23 jyasskin: One is in the introduction / non-normative. 20:57:26 scribe- 20:58:00 brent: It is my opinion, that we're not using "evidence" in a way that's outside the standard english definition. While it would be simple to link to NIST, I don't think there's anyone to do here. 20:58:14 brent: Anyone opposed to marking this "pending close"? 20:58:15 just for fun... https://csrc.nist.gov/glossary/term/public_key ... https://csrc.nist.gov/glossary/term/secret_key ... https://csrc.nist.gov/glossary/term/cryptographic_material ... 20:58:26 +1 to pending close 20:58:37 manu: +1 to pending close 20:59:09 zakim, who is here? 20:59:09 Present: brent, steele, Wes-smith, manu, decentralgabe, dlongley, dlehn, jyasskin, pdl-ASU, dmitriz, TallTed 20:59:09 brent: thanks everyone for your time today! 20:59:12 On IRC I see TallTed, pdl-ASU, Wes-smith, RRSAgent, Zakim, brent, csarven, KamirKami, shigeya, dlehn, matrix638, enick_708, cel, AnthonySpencer, jyasskin, manu, Github, npd, 20:59:12 ... bumblefudge1, seabass, MojGraph, saysaywhat, bumblefudge, ounfacdo, cel[m], joraboi445, SintayewGashaw, cel[h], w3c_modbot, ivan, rbyers, dlongley, hadleybeeman, stenr, 20:59:12 ... bigbluehat, rhiaro 20:59:44 zakim, end the meeting 20:59:45 As of this point the attendees have been brent, steele, Wes-smith, manu, decentralgabe, dlongley, dlehn, jyasskin, pdl-ASU, dmitriz, TallTed 20:59:46 RRSAgent, please draft minutes 20:59:47 I have made the request to generate https://www.w3.org/2024/01/17-vcwg-minutes.html Zakim 20:59:53 I am happy to have been of service, brent; please remember to excuse RRSAgent. Goodbye 20:59:54 Zakim has left #vcwg 20:59:59 rrsagent, bye 20:59:59 I see no action items