14:43:07 RRSAgent has joined #vcwg 14:43:07 logging to https://www.w3.org/2022/11/01-vcwg-irc 14:43:10 RRSAgent, make logs Public 14:43:11 please title this meeting ("meeting: ..."), ivan 14:45:52 Meeting: Verifiable Credentials Working Group Topic Call 14:45:52 Date: 2022-11-01 14:45:52 chair: brent 14:55:05 Meeting: Verifiable Credentials Working Group SpecialTopic Call 14:55:13 Meeting: Verifiable Credentials Working Group Special Topic Call 14:55:34 present+ 14:59:05 TallTed has joined #vcwg 15:00:33 selfissued has joined #vcwg 15:00:37 mprorock has joined #vcwg 15:00:43 present+ 15:01:00 present+ tony 15:01:00 present+ markus 15:01:00 present kristina 15:01:04 present+ 15:01:06 present+ drummond 15:01:20 David_Waite has joined #vcwg 15:01:47 drummond has joined #vcwg 15:01:49 brentz has joined #vcwg 15:01:57 Chair: kristina 15:01:57 present+ 15:02:02 markus_sabadello has joined #vcwg 15:02:05 present+ 15:02:10 present+ dwaite 15:02:16 present+ manu 15:02:18 present+ 15:02:32 kristina has joined #vcwg 15:02:51 nadalin has joined #vcwg 15:03:01 present+ mahmoud 15:03:07 Will has joined #vcwg 15:03:26 present+ 15:03:31 present+ dlongley 15:04:08 present+ dmitri 15:04:30 Mkhraisha has joined #vcwg 15:04:31 present+ jeremie 15:05:01 present+ will 15:05:02 q+ 15:05:02 scribe+ markus_sabadello 15:05:13 Jeremie has joined #vcwg 15:05:14 kristina: First administrativia.. Tomorrow's usual call 15:05:19 cabernet has joined #vcwg 15:05:24 present+ 15:05:29 kristina: Special topic call will be in 3 weeks (after IIW and IETF) 15:05:31 shawnb has joined #vcwg 15:05:33 present+ shawn 15:05:36 dmitriz has joined #vcwg 15:05:40 present+ 15:05:45 present+ 15:05:48 kristina: We're only canceling one call during IIW week, the calendar should already be updated 15:05:51 q? 15:05:55 TallTed has changed the topic to: VCWG Special Topic Call — 2022-11-01 Agenda: https://www.w3.org/events/meetings/6ed1154e-b772-42cc-ba01-f05600580b2b/20221101T110000 15:05:57 ack ivan 15:06:20 smccown has joined #vcwg 15:06:32 ivan: Not everyone has been on topic calls before. Any decisions taken on this call are not binding. The only place where binding resolutions can be made are official WG calls. This is not an official call in terms of W3C process 15:06:37 kristina: Thanks for the reminder ivan 15:06:41 q? 15:06:42 kristina: Any other questions about process? 15:06:59 Topic: https://github.com/w3c/vc-data-model/issues/947 15:07:03 present+ 15:07:21 kristina: This is about making @context optional. Thanks everyone for contributing and commenting on the issue. 15:07:27 present+ smccown 15:07:32 kristina: It's nice to see how many people care 15:07:50 q+ to provide background on issue. 15:07:50 kristina: There are a lot of different arguments, probably some people worry about implications for interoperability 15:08:00 present+ 15:08:05 kristina: There has been big tent and small tent terminology 15:08:32 kristina: How does the group think about semantic interoperability and extensibility. What are the different thoughts around that? 15:08:43 kristina: Maybe we can find points to reach agreement on 15:09:06 q? 15:09:10 kristina: I suggest let's start there, then we can focus on certain aspects at any time 15:09:12 ack manu 15:09:12 manu, you wanted to provide background on issue. 15:09:17 q+ 15:09:28 manu: A bit of background.. A lot has happened in 15:09:47 manu: Currently @context is required across representations. There has been some confusion about this. This is definitely what the spec makes. 15:09:57 manu: We're talking about introducing a breaking change to the VC data model 15:10:08 manu: There seem to be different lines of thinking on whether this is a good or bad thing 15:10:13 przemek has joined #vcwg 15:10:16 s/@context/`@context`/ 15:10:41 present+ cabernet 15:10:57 manu: One train of thought is JSON-LD is difficult to use, and we should allow different types of extensibility models. Because of that we should make @context optional and open up the aperture. This is the "pro-remove-context" argument. 15:11:23 manu: Extensbility could use an IANA registry, let's follow more traditional JSON-based approaches, similar to JWT. 15:11:48 present+ przemek 15:12:04 Mkhraisha has joined #vcwg 15:12:21 manu: We want to make this as easy as possible for developers. This is a common area. The "pro-lets-keep-things-the-way-they-are" (requiring @context) arguments are: We want decentralized extensiblity. We don't want to create centralized registries, and create a common data model 15:12:41 present+ dmitriz 15:12:44 manu: In 1.0, there was an agreement about using a graph-based data model, JSON-LD ticked the boxes. 15:13:10 manu: This "pro-keep-@context" camp is concerned about making a breaking change that will further complicate how people have to process VCs. 15:13:15 q? 15:13:23 manu: These seem to be the two main lines of thought. 15:13:58 ack selfissued 15:14:13 selfissued: We're at a better point for VCs now than we were several years ago, because we have seen what people have actually built and deployed 15:14:37 selfissued: Some people do want semantic knowledge graphs with JSON-LD, and some people don't feel they need it and have deployed things that don't use it. 15:14:53 selfissued: Smart Health credentials, Microsoft's implementations, are examples 15:14:56 mkhraisha_ has joined #vcwg 15:15:06 selfissued: Some people can't get JSON-LD right without expert help 15:15:36 ISO mDL/mDOC and ToIP ACDC are not Microsoft-lead initiatives 15:15:39 selfissued: There was XML-SOAP web service stack which worked really well, but developers hated it, they thought a lot of the complexity was unnecessary. 15:15:51 JoeAndrieu has joined #vcwg 15:15:57 selfissued: Developers vote with their feet. They want VCs with the three party model, but they don't care about JSON-LD features for the most part 15:16:18 selfissued: I read the whole thread. No part of our charter talks about semantic knowledge graphs. It's not core of our mission. 15:16:19 q+ 15:16:34 selfissued: It would be wise to create a standard based on what developers are actually using. 15:16:59 present+ JoeAndrieu 15:17:01 selfissued: One argument in the thread was you're not required to do JSON-LD processing even though there is a JSON-LD @context. 15:17:09 present+ cel 15:17:15 selfissued: There's evidence that a divide is harming interoperability. 15:17:30 q? 15:17:34 selfissued: It would be better to say if there's @context it's JSON-LD, and if it's not there, then it's not JSON-LD. 15:17:36 +1 to a "bright line" as to whether a particular instance does or does not use JSON-LD 15:17:38 @manu please don't make company comments they are not appropriate 15:17:41 ack dlongley 15:18:09 q+ 15:18:17 dlongley: From my perspective. Regarding decentralized extensibility, we have a technology that has been around for over a decade called JWTs. It expresses claims and uses a centralized IANA registry. 15:18:37 q+ 15:18:41 dlongley: Use cases have come up over that decade where people felt that the JWT model doesn't solve their problems. That's where VCs came from. 15:19:01 dlongley: JWT doesn't allow decentralized semantics, and merging of different data. 15:19:21 dlongley: A centralized registry couldn't scale to the many terms, and people didn't want to ask for permission when using terms. 15:19:49 dlongley: @context is a way to express which registries are in play. Instead of having one registry you can do it in a decentralized way. 15:20:19 dlongley: We specify registries in the @context field, this will disambiguate which terms are being used. This allows anybody to make and share common vocabularies. 15:20:41 q+ to note "the data is not in" -- "mistakes in implementations" shouldn't be confused with "desire" -- what we do have are test suites where people are properly using @context -- JFF being the latest example. 15:21:10 dlongley: With this concept we got a graph model where we can merge data about different entities. Credentials from different parties can be used to learn about the same entity. This is very valuable for supply chains, etc. There are a lot of use cases that VCs solve, not just personal credentials. 15:21:29 The issue with the "@context" property is that it requires using one particular solution to decentralized semantic interoperability. It is not the only solution. By making "@context", required, we exclude those other solutions. 15:21:35 dlongley: We have an existing technology, where people voted with their feet, and said this doesn't solve use cases. And VCs came up 15:21:45 dlongley: And I don't see how JWTs can't be used in a three party model. 15:22:19 drummond, not true -- you can list a jsonSchema and use that if you want (not that that's a fully formed technical solution) -- you need to propose a fully formed alternative. We can't handwave over the details here. 15:22:39 +1 to dlongley 15:22:41 dlongley: If you're happy to use a centralized registry, there's already a technology that solves this problem. There would be no point in making VCs that same technology 15:22:46 ack selfissued 15:22:54 selfissued: Thank you dlongley for sharing thoughts on JWTs. 15:23:27 selfissued: One extensibility mechanism for JWTs you haven't mentioned is the ability to use collision-resistant claim names, often prefixed by URLs that are in control of the party defining the claims. 15:23:56 selfissued: Just like @context relies on URIs for permissionless global extensibility, I can also create claim names under a domain name I control, to set up my own claim names. 15:24:04 "Collision-resistant claim names" are things like this: "https://foo.example/my-vocab/my-properties" <--- people aren't widely using these in JWTs -- we need to ask the question "why?" What's different between VCs and JWTs? 15:24:05 q- 15:24:15 URIs as property names, for JSON objects. If only there was a way to like.. extract / DRY those URLs into an object, so developers could continue to use URLs as property names, but also have them be human-readable and idiomatic :) 15:24:32 q+ to note that creating non-idiomatic, non-colliding JSON is not the same as idiomatic, non-colliding JSON 15:24:34 selfissued: So it's in fact the same extensibility model. We can also use an IANA registry, that's open to all. That's just as permissionless, you just have to send a permission request. I have helped several people on the call do that, it's very easy. 15:24:45 selfissued: JWT is also permissionless and globally extensibility. 15:25:06 One of the other fully decentralized solutions for decentralized semantic interoperability is labeled-property graphs (https://neo4j.com/blog/rdf-triple-store-vs-labeled-property-graph-difference/), which is the solution used by ACDC credentials. It would be ideal if ACDC credentials could be included under the W3C VC tent. 15:25:09 selfissued: The VC specs did define JWT claim extensions "vc" and "vp" to use the three party model 15:25:54 drummond, if you want the VCWG to use Labeled Property Graphs (LPGs), you should propose that as a technical solution. 15:25:58 selfissued: As Daniel Hardman said in this comments, there are times for strictness and times for laxness. The web flourished because HTML was lax. Structure was added to it, but structure was optional. 15:26:03 q? 15:26:14 q+ 15:26:25 selfissued: We should let developers use it as they see fit. A failure would be if this WG decides that only JSON-LD VCs would be VCs. 15:26:36 selfissued: Again, the charter doesn't talk about the graph model. 15:26:45 selfissued: People should use it if they want, and not use it if they don't want. 15:26:56 selfissued: Let us use VCs with as much or little structure as we want. 15:26:56 ack manu 15:26:56 manu, you wanted to note "the data is not in" -- "mistakes in implementations" shouldn't be confused with "desire" -- what we do have are test suites where people are properly 15:27:00 ... using @context -- JFF being the latest example. 15:27:21 manu: I want to push back hard against the rhetoric about "the data is in and developers have spoken" 15:27:22 +1 manu 15:27:54 manu: The reality is that we have had multiple plugfest, currently JFF involves close to 40 implementers. None of them seem to have any problems with having @context into their VCs. 15:28:08 manu: The assertion that developers out there desire it, if that's happening, they should engage. 15:28:11 +1 15:28:33 manu: Anybody can engage on Github and the mailing list. I don't buy that there is a ground swell 15:28:54 manu: Finding one developer who makes a mistake doesn't imply "desire". It doesn't mean they don't want to put it in there. 15:29:01 manu: You've got to back it up with citations and data. 15:29:27 q+ 15:29:31 manu: We can absolutely back up that people are using @context in JFF plugfest. They use both JWT backed VCs and Data Integrity backed VCs 15:29:43 The data is in the issue - see the number of people who are speaking against @context 15:29:54 manu: I do believe that there are some developers who don't want to use it, but they have to bring forward a concrete technical solution. 15:30:02 manu: This has not been done to date. 15:30:21 not everyone can participate in these interopts 15:30:38 kristina: We have some implementers on this call; there are also other implementers who are not on this call. 15:30:55 q? 15:31:00 ivan: Is Gerard a member/guest? 15:31:04 qq+ to remind folks of IRC ettiquette 15:31:16 shawnb: Here is a guest. 15:31:20 ack brentz 15:31:20 brentz, you wanted to react to manu to remind folks of IRC ettiquette 15:31:20 q+ 15:31:40 q+ 15:32:16 brentz: If you have a comment to make, please add yourself to the queue. If you have a comment that is pertinent to the current conversation, then write in IRC. Otherwise write your comment with /me. IRC notes are cleaned up after the call. 15:32:17 ack dlongley 15:32:17 dlongley, you wanted to note that creating non-idiomatic, non-colliding JSON is not the same as idiomatic, non-colliding JSON 15:32:40 dlongley: Want to respond to selfissued about JWT's decentralized extensibility mechanism using fully qualified terms. 15:33:24 dlongley: It's true, you can do that with JWTs. The problem is that you wind up with non-idiomatic JSON that doesn't look like JSON to developers. That is important not jus aesthetically, but developers also have to implement this in their code. 15:33:25 q+ 15:33:28 @context irks and bothers developers 15:33:29 present+ oliver 15:33:36 dlongley: @context was designed for this, to make it possible to continue to use idiomatic JSON. 15:33:41 present+ davidc 15:34:06 dlongley: It was really important to have term conflict resolution on a global scale, while still having idiomatic JSON. 15:34:08 jeremie has joined #vcwg 15:34:21 DavidC has joined #vcwg 15:34:30 dlongley: Regarding the graph model, it's not in the charter, but it's in the spec today. So it doesn't have to be in the charter. 15:34:33 present+ 15:34:54 dlongley: JSON is a format, not a data model. VC introduces a data model. 15:34:56 +1 Dave Longley 15:35:05 +1 dlongley 15:35:20 dlongley: I don't understand why a new spec is needed to use JWTs in a three party model. I don't know why JWTs can't be used. 15:35:53 It irked the SmartHealth pass developers. It irked the Microsoft decentralized identity developers. It irks the many people who showed up to speak on the issue against @context, like Daniel Hardman. Look at the data. 15:36:03 dlongley: I don't know why JWTs are not only used to secure VCs, but also seem to change the VC data model. 15:36:09 Microsoft led the SmartHealth pass work, right? 15:36:15 dlongley: If you want to do whatever modeling you want with JSON, just use JWTs. 15:36:32 ack drummond 15:36:35 q? 15:36:43 Microsoft participated in the SmartHealthPass work, just like it's participating in the VCWG 15:37:19 drummond: First point.. My understanding from people who implement JWTs is that JWT technology does not define a three party model. So if you want to use JWTs, the JWT community has come to this community to define a three party model. 15:37:36 it seems that you could just define a three party model via claims descriptions that you submit to the IANA registry for JWT. 15:37:54 drummond: They want to be interoperable with this community here. Having a common way to describe this model, so that it can be implemented in JSON-LD, JWT, etc. is the reason why the thread so long. This explains why some want to use @context and others don't. 15:38:28 q+ 15:38:45 drummond: I don't understand.. The benefits of JSON-LD are all still there for everyone who uses the JSON-LD model if @context is still there. All we're saying is that other models can also be used. I don't see the harm of opening it up to other models. 15:38:56 drummond: JSON-LD will always be JSON-LD if @context is there. 15:39:06 ack David_Waite 15:39:48 David_Waite: Talking about the plugfest.. If those implementations try to process JSON-LD they will fail unless they provide mapping files. 15:40:11 David_Waite: You're misunderstanding the spec and "JSON-LD processing".. 15:40:15 David_Waite: Some people want to use JSON-LD tools for a domain such as health care records. 15:40:17 q+ to speak about "JSON-LD processing" 15:40:44 s/David_Waite: You're/David_Waite, You're/ 15:40:49 David_Waite: I'm imaging that the plugfest was created around messages with @context that were fully resolved. The definition of how to map those were published. Without this the plugfest may not have been successful. 15:41:02 that's a misunderstanding, @vocab does not break the extensibility model 15:41:09 David_Waite: If I see property "foo" I will just make up a name, it's not being managed. 15:41:35 David_Waite: I want an avenue where I know the data is proper graph data, whereas someone wanted a different extensibility model, and here it is. 15:41:46 Yes, David Waite seems to be misunderstanding a variety of things here... about how the interop fest was set up being one of them. 15:41:55 David_Waite: Telling people to map to JSON-LD and write @context, when the spec itself doesn't say that, will create a lot of interoperability problems. 15:42:05 ack dmitriz 15:42:40 q+ 15:42:55 dmitriz: On one of the thread, I argued it's okay to make @context be optional, because instead we can require a default @context for VCs. If a developer encounters a VC and it doesn't have a @context, you can always inject a default base @context plus a @vocab. 15:42:55 q+ to note "making @context optional" harms interoperability because it's not replaced with anything -- there is no plan there other than "other solutions exist" 15:43:01 guest+ Gerard_Iervolino 15:43:04 guest+ dhardman 15:43:17 dmitriz: It became clear to me that this isn't a viable option. It's not really possible what is a VC and what is not, enough to be able to inject this default @context. 15:43:34 dmitriz: So what if we don't have the default @context. 15:43:57 +1 on the friction point 15:44:10 dmitriz: About making it optional: With the introduction of @vocab, there is zero friction for developers. Developers just have to copy&paste a single string, they don't have to create their own @context. 15:44:30 dmitriz: This is about the extensibility model. 15:45:02 dmitriz: Plain JSON extensibility hasn't worked out well. One group rejected @context initially and then ran into collision problems. 15:45:08 q+ 15:45:24 dmitriz: Another example in my mind shows that the registry and laissez-faire doesn't work is use profiles. 15:45:30 daniel_hardman has joined #vcwg 15:45:37 dmitriz: OIDC registers some standard claims for use profiles, such as name, picture, email 15:45:41 q+ 15:45:56 present+ bengo 15:46:16 dmitriz: This is really simple, really constrained. We have seen that even with the IANA registry, we've seen that in practice a bunch of implementers have implemented the use profile differently. 15:46:43 dmitriz: Auth providers have this in their documentation: They have to normalize certain fields that they have in common. 15:47:04 dmitriz: The point is they have only been able to agree on a small set of common fields. 15:47:14 I don't think the queue is going to get to me before our time is up, so I'm going to leave my comments here. 15:47:21 q+ 15:47:34 dmitriz: The registry and JSON extensibility model only work within a single company or community. Once you cross communities, this extensibility model breaks down. 15:47:39 ack nadalin 15:47:45 q+ to speak to breaking changes and consensus 15:48:04 zakim, close the queue 15:48:04 ok, brentz, the speaker queue is closed 15:48:05 nadalin: Wanted to comment back to manu. I don't have time to participate in plugfests. I brought up the issue of @context in the first release, I think the answer wasn't appropriate. 15:48:16 completely incorrect, regarding parsers 15:48:17 you don't need a parser for it 15:48:19 those are not necessary 15:48:21 we've said this many times :) 15:48:22 nope 15:48:39 nadalin: It's not needed for JWTs. I need a parser that has to deal with @context, so I have to change some core parts of my implementation. It feels awkward to have to change my parser if I just want to use JWTs. 15:48:45 s/nope// 15:49:03 I don't care about developer friction; I think this has never been a very important consideration. My reasons for wanting to make @context optional have to do with the wisdom of putting human data into the semantic web, not with the bother of implementing. 15:49:08 nadalin: @context is not applicable in a JWT environment. I have lots of use cases with an implementation that doesn't use it. I want to be compliant with the spec but I can't right now. 15:49:17 ack shawnb 15:49:47 shawnb: I don't have the same legacay as others in the WG. I feel there's a lot of ideology and schisms about the intentions. 15:49:48 I posted a long comment about this at the end of issue #947 with much more detail about that perspective. 15:50:00 shawnb: We owe it to each other to understand where the different camps are coming from. 15:50:17 shawnb: The details really matter here. The declaration to keep @context required matters. 15:50:39 shawnb: The W3C definition of VCs really matters. I believe this is what people feel passionately about. 15:50:53 shawnb: There are other formats because our customers have often not decided yet what they want. They want optionality. 15:51:23 Piling on top of @shawnb's comments: it's the semantic implications of @context, NOT the processing implications, that motivate me to ask for @context to be made optional. 15:51:26 shawnb: I get where the camp is coming from that wants openness and ambiguity. I think it's important to not just dismiss that. 15:51:44 shawnb: I don't think any one data model should attempt to claim superiority, it should be up to our customers. 15:51:54 shawnb: We're going to see a proliferation of VCs, it's already happening. 15:52:10 q? 15:52:12 q 15:52:34 shawnb: What's most important to me is security and trust. The data model can be circumstantial, but the security model needs to be very very clear. 15:53:06 ack mprorock 15:53:48 mprorock: This is a good discussion. There is a lot of nuance on both sides. I have a lot of frustration with JSON-LD. In this context however the inclusion of @context (even if you're not processing it), there is a side benefit to it. 15:54:05 +1 to Markus's comment about the primacy of security. 15:54:13 mprorock: I'm pretty strongly of keeping @context in and easing developer onboarding. This keeps the semantic meaning of how we structure claims. 15:54:26 mprorock: This isn't a hard thing to ask to include it, which is already in the spec. 15:54:44 mprorock: I don't see a good argument to drop it. I see valid arguments to make it easier for developers, to add guidance about caching etc. 15:54:53 Helping developers isn't the reason @context should be made optional. See my final comment in #947. 15:54:58 mprorock: I don't see any significant reason for dropping it. 15:55:10 ack DavidC 15:55:36 DavidC: As a JWT developer we have absolutely no problem with @context. It doesn't cause interop problems for us. 15:55:48 2+ 15:55:50 q+ 15:55:57 DavidC: I don't see why e.g. the health care use case can't just include an @context. 15:56:06 ack daniel_hardman 15:56:34 daniel_hardman: I feel like developer onboarding and friction is a red herring. It's not about onboarding, it's about semantic implementations. I left a long comment in the Github issue. 15:56:35 ack jeremie 15:57:47 +1 to Daniel's point. What the JSON-LD folks do not seem to appreciate is the level of confusion that it causes in the market if all W3C VCs must have an JSON-LD @context statement when some of them do not use JSON-LD. Avast implements both and we feel strongly that @context should ONLY be used for VCs that use JSON-LD. 15:57:49 jeremie: Regarding developers voting with their feet. Ping is involved in a lot of pilots in the VC space with our customers. Those are customers who are silent, they are not on Github or involved in the standards process. Our team is getting pressure to use VCs. We're here because we want to find a common solution. 15:58:16 ack JoeAndrieu 15:58:16 JoeAndrieu, you wanted to speak to breaking changes and consensus 15:58:18 jeremie: We're getting pressure from people who can't absorb a new JSON-LD tech stack, and they want to use JWT. We want to meet requirements. 15:58:35 +1 Joe Andrieu 15:58:46 -1 to closing this issue 15:58:49 q- 15:58:51 -1 to closing issue 15:58:52 @drummond - hey, you're absolutely right, confusion is bad. with this v2.0 spec, we have a chance to fix a lot of that confusion, to clarify. without making breaking change & removing @context requirement 15:58:55 JoeAndrieu: I think this is a breaking change. I don't think there is consensus. My proposal is to close the issue. There doesn't seem to be consensus and we should stick to the current spec. 15:58:56 ack dlongley 15:58:56 dlongley, you wanted to speak about "JSON-LD processing" 15:59:00 -1 to joe 15:59:03 On the last WG call Manu said that it's not a breaking change because the V1 context doesn't change 15:59:19 dlongley: The term "JSON-LD processing" is problematic. If you want to write an implementation of VCs, you don't need to use a JSON-LD library. 15:59:23 ack selfissued 15:59:26 @tony without consensus there will not be a change in the spec 15:59:37 To be clear, this is a breaking change to how the spec works. 15:59:40 issue should no way be closed as no consensus 15:59:57 issue will never have consensus. that's why we should close 16:00:02 selfissued: I appreciate everyone who spoke up. We all passionately care about this. It's really important that the WG produces a spec that everybody wants to use. I wanted to run some strawpolls, but we're out of time. We need another special topic call. 16:00:11 -1 to closing 16:00:15 nothing in charter about no breaking change allowed 16:00:25 kristina: We need direction on how to proceed before we close the issue. 16:00:54 no we don't "need direciton". Changes require consensus. Full stop. 16:01:09 Looking forward to the next call. Thanks Markus for scribing! 16:01:15 kristina: Thanks everyone for joining. We will continue the discussion on the next special topic call in 3 weeks. Let's then try to make some resolutions on the main call. 16:01:22 kristina: See you tomorrow. 16:01:34 zakim, end meeting 16:01:34 As of this point the attendees have been ivan, selfissued, tony, markus, mprorock, drummond, markus_sabadello, dwaite, manu, brentz, mahmoud, kristina, dlongley, dmitri, jeremie, 16:01:37 ... will, cabernet, shawn, shawnb, TallTed, smccown, dmitriz, przemek, JoeAndrieu, cel, oliver, davidc, bengo 16:01:37 RRSAgent, please draft minutes 16:01:37 I have made the request to generate https://www.w3.org/2022/11/01-vcwg-minutes.html Zakim 16:01:39 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 16:01:44 Zakim has left #vcwg 16:02:23 rrsagent, bye 16:02:23 I see no action items