23:03:11 <RRSAgent> RRSAgent has joined #vcwg
23:03:11 <RRSAgent> logging to https://www.w3.org/2022/11/22-vcwg-irc
23:03:15 <Zakim> Zakim has joined #vcwg
23:03:26 <manu> present+
23:03:28 <DavidC> DavidC has joined #vcwg
23:03:35 <DavidC> present+
23:06:28 <kristina> kristina has joined #vcwg
23:07:22 <dmitriz> dmitriz has joined #vcwg
23:07:29 <dmitriz> present+
23:13:10 <TallTed> present+
23:13:25 <TallTed> scribe?
23:17:27 <TallTed> apparently, we're in #vcwg-special (for the first time, to my knowledge)
23:27:41 <JoeAndrieu> JoeAndrieu has joined #vcwg
23:42:36 <gkellogg> gkellogg has joined #vcwg
23:42:57 <SamSmith> SamSmith has joined #vcwg
23:43:04 <SamSmith> Q
23:44:43 <SamSmith> The schema itself is the type. Its more precise
23:44:49 <SamSmith> q
23:44:49 <JoeAndrieu> present+
23:45:07 <dmitriz> Joe, Sam, for whatever reason, this call is on a separate irc channel, #vcwg-special
23:46:43 <JoeAndrieu> thanks
23:47:44 <gkellogg> gkellogg has joined #vcwg
00:00:47 <TallTed> TallTed has changed the topic to: (if nobody's here, check #vcwg-special)
00:04:13 <gkellogg> gkellogg has joined #vcwg
00:05:59 <gkellogg> gkellogg has joined #vcwg
00:09:08 <gkellogg> gkellogg has joined #vcwg
00:30:14 <gkellogg> gkellogg has joined #vcwg
00:48:35 <gkellogg> gkellogg has joined #vcwg
01:11:21 <gkellogg> gkellogg has joined #vcwg
01:22:35 <gkellogg> gkellogg has joined #vcwg
01:42:52 <gkellogg> gkellogg has joined #vcwg
01:59:05 <gkellogg> gkellogg has joined #vcwg
02:17:45 <gkellogg> gkellogg has joined #vcwg
02:29:59 <gkellogg> gkellogg has joined #vcwg
02:49:16 <gkellogg> gkellogg has joined #vcwg
03:05:54 <gkellogg> gkellogg has joined #vcwg
03:23:41 <gkellogg> gkellogg has joined #vcwg
03:37:14 <gkellogg> gkellogg has joined #vcwg
03:53:28 <gkellogg> gkellogg has joined #vcwg
04:00:52 <gkellogg> gkellogg has joined #vcwg
04:13:06 <gkellogg> gkellogg has joined #vcwg
04:32:56 <gkellogg> gkellogg has joined #vcwg
04:49:59 <gkellogg> gkellogg has joined #vcwg
04:52:34 <gkellogg_> gkellogg_ has joined #vcwg
05:12:10 <gkellogg> gkellogg has joined #vcwg
05:28:59 <gkellogg> gkellogg has joined #vcwg
05:40:25 <gkellogg> gkellogg has joined #vcwg
05:52:49 <gkellogg> gkellogg has joined #vcwg
06:00:23 <gkellogg> gkellogg has joined #vcwg
06:01:31 <gkellogg> gkellogg has joined #vcwg
06:07:14 <gkellogg> gkellogg has joined #vcwg
06:19:45 <gkellogg> gkellogg has joined #vcwg
06:31:51 <gkellogg> gkellogg has joined #vcwg
06:34:51 <gkellogg> gkellogg has joined #vcwg
06:38:13 <gkellogg> gkellogg has joined #vcwg
06:54:25 <gkellogg> gkellogg has joined #vcwg
07:00:06 <gkellogg> gkellogg has joined #vcwg
07:01:25 <gkellogg> gkellogg has joined #vcwg
07:10:40 <gkellogg> gkellogg has joined #vcwg
07:21:33 <gkellogg> gkellogg has joined #vcwg
07:37:53 <gkellogg> gkellogg has joined #vcwg
07:55:11 <gkellogg> gkellogg has joined #vcwg
08:15:04 <gkellogg> gkellogg has joined #vcwg
08:18:44 <gkellogg> gkellogg has joined #vcwg
08:37:43 <gkellogg> gkellogg has joined #vcwg
08:39:00 <Zakim> Zakim has left #vcwg
08:57:16 <gkellogg> gkellogg has joined #vcwg
09:15:24 <gkellogg> gkellogg has joined #vcwg
09:31:26 <gkellogg> gkellogg has joined #vcwg
09:44:01 <gkellogg> gkellogg has joined #vcwg
10:13:55 <gkellogg> gkellogg has joined #vcwg
10:32:10 <gkellogg> gkellogg has joined #vcwg
10:49:57 <gkellogg> gkellogg has joined #vcwg
11:08:52 <gkellogg> gkellogg has joined #vcwg
11:12:44 <gkellogg_> gkellogg_ has joined #vcwg
11:28:38 <gkellogg> gkellogg has joined #vcwg
11:46:52 <gkellogg> gkellogg has joined #vcwg
11:54:21 <gkellogg> gkellogg has joined #vcwg
12:13:40 <gkellogg> gkellogg has joined #vcwg
12:30:45 <gkellogg> gkellogg has joined #vcwg
12:38:43 <gkellogg> gkellogg has joined #vcwg
12:57:48 <gkellogg> gkellogg has joined #vcwg
13:14:27 <gkellogg> gkellogg has joined #vcwg
13:19:39 <tzviya> tzviya has joined #vcwg
13:31:30 <gkellogg> gkellogg has joined #vcwg
13:48:56 <gkellogg> gkellogg has joined #vcwg
14:00:11 <TallTed> TallTed has joined #vcwg
14:16:28 <gkellogg> gkellogg has joined #vcwg
14:20:27 <gkellogg> gkellogg has joined #vcwg
14:30:23 <gkellogg> gkellogg has joined #vcwg
14:39:14 <ivan> ivan has joined #vcwg
14:58:14 <gkellogg> gkellogg has joined #vcwg
15:00:22 <gkellogg> gkellogg has joined #vcwg
15:00:27 <gkellogg_> gkellogg_ has joined #vcwg
16:07:41 <gkellogg> gkellogg has joined #vcwg
16:25:10 <gkellogg> gkellogg has joined #vcwg
16:41:49 <gkellogg> gkellogg has joined #vcwg
16:48:10 <gkellogg> gkellogg has joined #vcwg
16:59:24 <gkellogg> gkellogg has joined #vcwg
17:19:10 <gkellogg> gkellogg has joined #vcwg
17:23:05 <gkellogg_> gkellogg_ has joined #vcwg
19:07:45 <dmitriz> dmitriz has joined #vcwg
19:52:51 <brentz> brentz has joined #vcwg
19:55:06 <brentz> brentz has changed the topic to: VCWG Agenda 2022-11-23 https://www.w3.org/events/meetings/c5abcc63-337b-4ebb-97af-7cc2fb63de11/20220720T150000
19:55:18 <Zakim> Zakim has joined #vcwg
19:55:33 <brentz> zakim, start the meeting
19:55:33 <Zakim> RRSAgent, make logs Public
19:55:34 <Zakim> please title this meeting ("meeting: ..."), brentz
19:55:46 <brentz> Meeting: Verifiable Credentials Working Group Telco
19:55:53 <brentz> Chair: brentz
19:56:02 <brentz> Date: 2022-11-23
19:56:24 <brentz> present+
20:00:01 <dlongley> present+
20:00:36 <DavidC> DavidC has joined #vcwg
20:01:27 <mprorock> mprorock has joined #vcwg
20:01:50 <selfissued> selfissued has joined #vcwg
20:01:54 <selfissued> present+
20:02:13 <oliver> oliver has joined #vcwg
20:02:26 <stenr> present+
20:03:08 <mprorock> present+
20:03:27 <manu> present+
20:04:12 <Orie> Orie has joined #vcwg
20:04:14 <Orie> present+
20:04:19 <Orie> scribe+
20:04:47 <Orie> Brent: Agenda
20:05:03 <Orie> We are doing work items status updates and PRs
20:05:10 <Orie> ... agenda bash?
20:05:27 <Orie> Brent: Oliver is there anything holder binding related?
20:05:31 <Orie> Oliver: not for today
20:05:35 <kdeangs1> kdeangs1 has joined #vcwg
20:05:49 <Orie> Topic: Introductions
20:06:17 <Orie> Sven: Joining
20:06:50 <brentz> s/Sven/Sten/
20:07:01 <Orie> Sten: from verid in the netherlands, connecting wallet providers to platforms and using verifiable credentials
20:07:16 <Orie> Brent: Work Item Status Updates
20:07:19 <Orie> q+
20:07:29 <manu> scribe+
20:07:38 <tplooker> tplooker has joined #vcwg
20:07:43 <tplooker> present+
20:07:59 <brentz> zakim, who is here?
20:07:59 <Zakim> Present: brentz, dlongley, selfissued, stenr, mprorock, manu, Orie, tplooker
20:08:02 <Zakim> On IRC I see tplooker, kdeangs1, Orie, oliver, selfissued, mprorock, DavidC, Zakim, brentz, TallTed, tzviya, RRSAgent, w3c_modbot, npd, cel[h], bumblefudge, cel[m], stenr, dlehn1,
20:08:02 <Zakim> ... cel, shigeya, dlehn, dlongley, manu, stonematt, Dongwoo, bigbluehat, hadleybeeman, rhiaro
20:08:04 <manu> Orie: The main update is we did merge the FPWD on JSON Web Siganture 2020, Ivan has added some other updates which I'm approving and merging because they're editorial.
20:08:06 <Orie> https://github.com/w3c/vc-jws-2020/pull/28
20:08:09 <logan> logan has joined #vcwg
20:08:20 <logan> present+
20:08:36 <DavidC> present+
20:08:44 <manu> Orie: That's the link that was merged. We've done the things we needed for FPWD for JsonWebSignature2020 which uses detached JWS, this is the first data integrity proof suite to go to FPWD for the group.
20:08:47 <brentz> present+ nadalin
20:09:02 <manu> Orie: We have not yet done that for VC-JWT, we should do our best to get that document to the point where it's ready.
20:09:06 <manu> brentz: Any comments/questions about this work item?
20:09:14 <manu> brentz: What are the next steps for the FPWD?
20:09:18 <Orie> Brent: what are next steps for FPWD for VC-JWT?
20:09:20 <Orie> q+
20:09:24 <brentz> ack Orie
20:09:29 <Orie> q-
20:09:42 <manu> MikeJ: The Editors need to have a side call about that and decide what needs to be done. Orie?
20:09:47 <Orie> selfissued: Editors need a side call to discuss and report back to the WG
20:09:54 <manu> Orie: I agree with that, I'll ping you.
20:10:10 <manu> Brent: Other work items?
20:10:10 <Orie> Brent: other work items?
20:10:23 <manu> https://github.com/w3c/vc-data-model/pulls
20:10:40 <cel> regrets+
20:10:49 <Orie> Manu: VC Data Model pulls, oliver raised one on credential subject objects
20:10:59 <Orie> ... we also got JSON Schema for VCs
20:11:04 <manu> https://github.com/w3c/vc-data-model/pull/976
20:11:30 <Orie> ... In process, this is Ivan setting the range of credentialSubject to be IRI
20:11:36 <manu> https://github.com/w3c/vc-data-integrity/pulls
20:12:04 <Orie> ... VC Data Integrity has no active PRs, but the EdDSA crypto suite is being worked on outside the group
20:12:11 <manu> https://w3c.github.io/rdf-canon/spec/
20:12:45 <Orie> Manu: ^ this spec work continues, it blocks the data integrity specs... the group seems to be focusing on URDNA2015.
20:13:18 <brentz> q?
20:13:38 <Orie> Brent: when do you propose to the group to bring in EdDSA?
20:14:03 <mprorock> q+
20:14:12 <brentz> ack mprorock
20:14:14 <Orie> Manu: we already did an FCGS in july, we could do another?... should we propose to bring it in today?
20:14:44 <Orie> MikeP: Don't see the need to get a second inclusion, its a rubber stamp from the CCG as editorial.
20:14:45 <manu> q+
20:14:51 <Orie> ... either way I am good
20:15:04 <Orie> Manu: We could say that this group is going to pull that work in.
20:15:20 <mprorock> +1 manu
20:15:21 <Orie> ... the IPR would be on the final commitment today.
20:15:41 <Orie> q+
20:16:11 <mprorock> scribe+
20:16:25 <brentz> ack Orie
20:17:12 <shawnb> shawnb has joined #vcwg
20:17:17 <oliver> q+
20:17:39 <mprorock> Orie: Don't want to be hostile to incubation, however concerned that JWS(2020) covers this suite as well - do we want multiple ways of handling the same algorithms?
20:18:07 <shawnb> present+
20:18:11 <mprorock> ... want to ensure WG understands what this means
20:18:26 <manu> q+ to note it's in the charter and we have 5 implementations
20:18:26 <mprorock> q+
20:18:32 <brentz> ack manu
20:18:32 <Zakim> manu, you wanted to note it's in the charter and we have 5 implementations
20:18:46 <manu> 5 implementations: https://w3c-ccg.github.io/di-ed25519-test-suite/#Ed25519Signature2020%20(issuer)
20:18:59 <Orie> Manu: its a charter deliverable and we have 5 implementations
20:18:59 <brentz> ack oliver
20:19:32 <Orie> Oliver: I don't necessarily see the value of adding this suite... but I respect that there are 5 implementations and its a charter deliverable.
20:19:42 <Orie> ... I don't think its needed.
20:19:47 <brentz> ack mprorock
20:20:43 <Orie> MikeP: personal implementer hat only, we are going to now have 2 different ways of securing a credential, with the same cryptography, i'm worried implementers may get confused... and that we are setting a precendent.
20:20:50 <tplooker> +1 agree with mike, orie and oliver more options is bad for interop and security
20:20:59 <Orie> q+
20:21:05 <brentz> ack Orie
20:21:50 <mprorock> +1 Orie - some changes need to occur to match current data integrity FPWD
20:22:58 <dlongley> +1 to Orie on the design trade offs
20:23:14 <manu> +1 to Orie about that different design trade offs have been made.
20:24:23 <dlongley> +1 to Orie in short: i'd say that the differences exist on purpose (design trade offs)
20:24:54 <oliver> q+
20:24:56 <Orie> brent: would it be accurate to say that the EdDSA suite that is being brought in, that there are use cases that are specific to it?
20:25:03 <brentz> ack oliver
20:25:09 <manu> q+ to speak to the spec.
20:25:17 <Orie> oliver: its less about the signatures, and more about the encoding of the public key.
20:25:40 <Orie> ... the suites tend to use different publicKey types, publicKeyMultibase vs publicKeyJwk
20:25:54 <selfissued> q+
20:25:59 <Orie> ... it might be easier to use a single encoding for verification keys
20:26:10 <brentz> ack manu
20:26:10 <Zakim> manu, you wanted to speak to the spec.
20:26:28 <Orie> Manu: its not only that, there are a set of design tradeoffs... there 2 things are different, and they are not going to reconcile
20:27:05 <Orie> ... Ed25519Signatute2020 is already built into point of sale systems, and encoded in QR Codes... this helps us make the QR code small enough.
20:27:16 <Orie> ... this helped make the credential compact
20:27:28 <Orie> ... it has different goals, that JWS 2020
20:27:35 <brentz> ack selfissued
20:27:50 <mprorock> q+
20:27:51 <manu> q+ to speak to multibase.
20:27:52 <Orie> selfissued: multibase last I checked is not a standard, and not in a process for standards track
20:27:53 <Orie> q+
20:27:57 <brentz> ack mprorock
20:28:16 <selfissued> q+
20:28:16 <Orie> MikeP: are we allowed to point to multicodec / multibase?
20:28:22 <brentz> ack manu
20:28:22 <Zakim> manu, you wanted to speak to multibase.
20:28:33 <Orie> manu: multibase was sent to IETF secdispatch
20:29:00 <Orie> ... we only use multibase for key encoding, and we only us `z` (base58btc)... we don't need to refer to an IETF RFC.
20:29:05 <przemek> przemek has joined #vcwg
20:29:26 <Orie> ... the only multibase letter we use is z (base58btc)...
20:29:42 <Orie> ... if multibase moves along faster at IETF, we could refer to it
20:30:08 <Orie> ... we could define how to use multibase here in W3C VCWG, and then we can refer to it at IETF, if it lands there.
20:30:50 <Orie> Brent: a normative track spec, needs to point to a spec at the same level... an ED or FPWD can point to IETF, we will only encounter challenges to CR or PR if its not done at IETF
20:30:51 <brentz> ack Orie
20:31:24 <mprorock> https://mailarchive.ietf.org/arch/browse/dispatch/?gbt=1&index=Q9aUoF01Upbvl7STjJvjoU8hlHM
20:31:39 <manu> Orie: I know the question went to secdispatch, have we gotten a response on this issue? Clarifying question - Manu had offered an alternative, define base58btc in spec and no need to refer to IETF. Could make it clear to proceed through CR/PR if we go through that path?
20:32:12 <manu> Brent: Yes, that's the case, we can point to multibase I-D, starting off the process, just as this is starting off the process, can point ot that normatively, both specs can advance to normative status at that same pace. Failing that, there is another way to do it regardless.
20:32:16 <brentz> ack selfissued
20:32:38 <Orie> Brent: the text as is points to an I-D at IETF, so its still appropriate to point to IETF until it needs to point to something better, and then yes.
20:32:51 <Orie> selfissued: Can we get a link to the secdispatch minutes
20:33:03 <Orie> Brent: Lets run the proposal
20:33:07 <brentz> PROPOSAL: Pull in the EdDSA cryposuite https://w3c-ccg.github.io/di-eddsa-2020/ into the group after it has had a final FCGS publication in CCG and publish it as an Editor's Draft.
20:33:10 <manu> +1
20:33:15 <dlongley> +1
20:33:16 <Orie> +0
20:33:19 <oliver> +0
20:33:20 <shawnb> -1
20:33:24 <mprorock> -0
20:33:24 <selfissued> -1 due to the unnecessary duplication
20:33:26 <stenr> +0
20:33:29 <DavidC> 0
20:33:38 <cel> +1
20:33:55 <tplooker> ~0 worried about duplication of approaches here too, would like to see less optionality
20:33:59 <shawnb> q+
20:34:07 <selfissued> q+
20:34:11 <Orie> Brent: is there a way to reword the proposal?
20:34:11 <brentz> ack shawnb
20:35:23 <brentz> ack selfissued
20:35:23 <Orie> shawnb: Maybe I need to think about it more, but knee jerk reaction is I see potential problems, and feedback from security experts on practices that involve transformation prior to hash and then sign.... I also have a bad feeling about duplicity, and it feels like a mix of data model and sec, and its a bad practice
20:35:56 <Orie> selfissued: There is no record of multibase being considered by secdispatch, but there has been no presentation or resolution from the chairs
20:36:03 <manu> q+
20:36:05 <mprorock> q+
20:36:06 <Orie> ... I don't see IETF proposing a standards path
20:36:07 <brentz> ack manu
20:36:27 <Orie> Manu: we don't need a WG or standards track document to pull it in
20:36:38 <Orie> ... we also said we can define the encoding in the spec
20:37:17 <Orie> ... sounds like you are objecting to the data integrity work in general, which means you might also object to the JWS2020
20:37:34 <brentz> ack mprorock
20:37:35 <mprorock> https://datatracker.ietf.org/doc/html/draft-multiformats-multibase-06
20:37:54 <Orie> mprorock: is this the latest draft on data tracker ?
20:38:22 <Orie> ... not aware of of anything moving beyond the list, as far as I know, its not been assigned a home yet
20:38:24 <brentz> q?
20:38:26 <shawnb> q+
20:38:32 <Orie> ... and i don't think it should block the work
20:38:32 <brentz> ack shawnb
20:39:18 <Orie> shawnb: fair question manu, canonicalized forms that are in practice applied to JWS2020 detached proof... in my implementation, it does not conform to the data integrity proof spec
20:40:01 <dlongley> q+
20:40:03 <manu> q+
20:40:05 <Orie> Brent: we don't have consensus to pull the work item in
20:40:05 <brentz> ack dlongley
20:40:09 <manu> q-
20:40:25 <Orie> dlongley: there are different design considerations for the different crypto suites
20:40:28 <Orie> q+
20:40:29 <manu> q+
20:40:53 <Orie> ... are these other design considerations used not possible to achieve with JWS2020
20:41:02 <Orie> ... are we arguing to limit optionality?
20:41:08 <brentz> ack Orie
20:43:06 <manu> Orie: I agree with what Dave said, I'm pretty sure the intention at the time was to pull in cryposuites, not just one w/ a compact representation, but also ones for NIST curves and Ed25519 is prohibited, I agree with Dave. The way it was originally communicated was we'd pull multiple ones in. One comment I have is compaction in JSON, what I believe is that compaction was based on CBOR-LD codecs and it would be possible to compact detached JWS base64 URl
20:43:06 <manu> instead of base-58 btc and base64 might be more compatible, codec in base64 URL would result in more compact ones across the board instead of one particular key ... need to focus on compact representations. Being able to compact verification method or signature material is a valuable feature, shouldn't be limited only.
20:43:10 <brentz> ack manu
20:43:37 <Orie> Manu: I thought we would pull in multiple crypto suites, its the reason we were ok with JWS2020
20:44:11 <Orie> ... I thought we would allow people to choose cryptosuite, and I imagine that the vote would be different... and we are maybe creating a need for 1 single winning cryptosuite
20:44:23 <Orie> ... seems like we are creating conflict in the group
20:44:47 <Orie> ... we already have multple implementations of this, going into production
20:45:07 <Orie> ... regardless of if the group pulls it in, the group would not be documenting the reality in the commercial market
20:45:40 <Orie> ... now limiting the number of cryptosuites being pulled in, we're going to spend a lot of time arguing over crypto suites
20:45:42 <brentz> q?
20:45:52 <Orie> q+
20:46:10 <TallTed> present+
20:46:42 <Orie> brent: we have heard concerns from folks regarding bringing the work item in, I'm resolving this proposal, and we're going to take it and move forward
20:46:55 <Orie> sorry i scribbed that wrong
20:47:06 <Orie> selfissued: how will this be resolved?
20:47:12 <brentz> ack Orie
20:47:25 <dlongley> 3-2 = 1
20:47:27 <selfissued> q+
20:47:37 <mprorock> q+
20:47:39 <dlongley> the actual votes (unless i'm misreading it)
20:49:13 <shawnb> I'm okay with that dlongley, and FWIW I'm okay changing -1 --> 0 for the reasons Orie is outlining.
20:49:21 <brentz> ack selfissued
20:50:03 <brentz> ack mprorock
20:50:05 <Orie> selfissued: a charter provides boundaries on what we "may do" it does not decide what the wg "will do"... the charter allows for us to decide
20:50:42 <Orie> MikeP: I want to agree with selfissued and Orie, what are our actual goals as a WG? how does this work, help us achieve our goals?
20:51:01 <Orie> ... there are things like bbs and hpke and we may have to wait on...
20:51:29 <Orie> ... the WG should beware of the items, I am not saying not to take the work, I am just concerned on duplication
20:51:32 <manu> q+ to ask again for objections?
20:51:37 <Orie> ... there are use cases that are building on this path
20:51:42 <brentz> ack manu
20:51:42 <Zakim> manu, you wanted to ask again for objections?
20:51:52 <Orie> Manu: shawnb changed his vote to a 0
20:52:09 <selfissued> q+
20:52:10 <tplooker> +1 mike the only reason BBS cannot fit under the JWS umbrella is that it wont ever be registered as a JWA compatible with JWS because of future proposals like JWP covering it instead
20:52:15 <Orie> ... can we ask who will object?... I am hearing there is concern, but maybe not blocking the work?
20:52:21 <brentz> ack selfissued
20:52:23 <nadalin> nadalin has joined #vcwg
20:52:33 <mprorock> +1 tplooker - it is a nuanced thing that we need to account for
20:52:37 <nadalin> I would object
20:52:42 <nadalin> +1
20:52:55 <mprorock> i will object due to lack of consensus at this point
20:53:06 <brentz> q?
20:53:10 <dlongley> q+
20:53:12 <Orie> selfissued: I object to it being pulled in this way, there is a cost to pulling in work and committing to do work.... I object on the principle that it does not reflect consensus
20:53:18 <nadalin> q+
20:53:19 <brentz> ack dlongley
20:53:46 <Orie> dlongley: I think the health of the wg is determined by how we achieve consensus, and there are design tradeoffs
20:54:04 <Orie> ... JWS2020 was allowed in because of the promise of the other crypto suites coming it
20:54:21 <selfissued> q+
20:54:29 <Orie> ... I think the approach that is being taken here is a change after the fact to what we agreed to, and we should revote on the other items
20:54:39 <brentz> ack nadalin
20:54:41 <Orie> ... and we may not be able to resolve the design choices
20:55:05 <Orie> nadalin: I don't understand why this work is being brought here, and not somewhere else... if there is so much work for it, it can be done elsewhere
20:55:06 <brentz> ack selfissued
20:55:21 <Orie> selfissued: I disagree with dlongley's characterization
20:55:25 <Orie> q+
20:55:42 <Orie> ... we agreed to a charter, and now we are using it to decide what we want to work on
20:56:00 <Orie> ... just because its in a charter does not ensure that it will be done
20:56:27 <TallTed> q+
20:56:27 <nadalin> +1 to Mike
20:56:29 <Orie> ... I can see there is not consensus...
20:56:33 <brentz> ack Orie
20:57:27 <dlongley> +1 to Orie, this is not healthy for the WG and items we've pulled in so far
20:57:59 <dlongley> not acknowledging that those received support in the WG because other items were expected to receive support does not acknowledge what members in the WG are saying.
20:58:49 <brentz> ack TallTed
20:59:20 <Orie> TallTed: backseat chairing is not helpful... "if i were chairing..." etc... if you have an issue with the chairs, raise it to them... and follow the process
20:59:42 <Orie> ... does the charter control what the work can do? yes, it can declare out of scope and deliverables
20:59:56 <Orie> ... the group is supposed to complete deliverables
21:00:34 <Orie> ... there are aspects of the work we are doing here, and if there are some that better than others, perhaps the work can be improved here
21:00:51 <Orie> ... the people who want to do the work, should be allowed to work together
21:00:59 <Orie> +1 TallTed
21:01:09 <shawnb> Take care all
21:01:13 <mprorock> thanks all!
21:01:29 <brentz> zakim, end the meeting
21:01:29 <Zakim> As of this point the attendees have been brentz, dlongley, selfissued, stenr, mprorock, manu, Orie, tplooker, logan, DavidC, nadalin, shawnb, TallTed
21:01:31 <Zakim> RRSAgent, please draft minutes
21:01:31 <RRSAgent> I have made the request to generate https://www.w3.org/2022/11/22-vcwg-minutes.html Zakim
21:01:34 <Zakim> I am happy to have been of service, brentz; please remember to excuse RRSAgent.  Goodbye
21:01:38 <Zakim> Zakim has left #vcwg
21:01:40 <brentz> rrsagent, bye
21:01:40 <RRSAgent> I see no action items