15:02:31 <RRSAgent> RRSAgent has joined #vcwg
15:02:35 <RRSAgent> logging to https://www.w3.org/2024/07/31-vcwg-irc
15:02:35 <Zakim> Zakim has joined #vcwg
15:02:45 <TallTed> present+
15:02:52 <manu> present+ hsano
15:02:58 <manu> present+
15:03:42 <brent> brent has joined #VCWG
15:03:47 <DavidC> DavidC has joined #vcwg
15:03:53 <TallTed> TallTed has changed the topic to: VCWG Meeting -- Agenda 2024-07-31: https://www.w3.org/events/meetings/9bfb4063-230b-4f59-b14c-fbf670b8a51b/20240731T110000/
15:03:53 <DavidC> present+
15:03:56 <wes-smith> scribe+
15:03:57 <decentralgabe> decentralgabe has joined #vcwg
15:04:01 <decentralgabe> present+
15:04:01 <Wip> Wip has joined #vcwg
15:04:14 <bigbluehat> bigbluehat has joined #vcwg
15:04:22 <bigbluehat> present+
15:04:44 <wes-smith> brent: agenda for today: wrap up VCDM, discuss issues in Data Integrity
15:05:40 <PL-ASU> PL-ASU has joined #vcwg
15:05:46 <brent> Topic: VCDM Wrap Up
15:05:48 <PL-ASU> present+
15:05:50 <wes-smith> ... first topic: VC Data Model wrap-up
15:05:54 <brent> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc
15:06:00 <seabass> seabass has joined #vcwg
15:06:08 <wes-smith> ... last few issues open on VCDM so we get all on same page as far as what needs to be done
15:06:15 <manu> q+
15:06:24 <seabass> present+
15:06:33 <brent> ack manu
15:06:33 <wes-smith> ... 3 open issues that need to be finished that are not marked future
15:06:33 <JennieM> JennieM has joined #vcwg
15:06:33 <DavidC> I cannot hear anything. Is anyone else having problems with Zoom?
15:06:33 <KevinDean> KevinDean has joined #vcwg
15:06:33 <JennieM> present+
15:06:34 <KevinDean> present+
15:06:40 <JoeAndrieu> JoeAndrieu has joined #vcwg
15:06:40 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1437
15:06:49 <wes-smith> manu: to speak to some of these, don't need to go into depth, 1437 remove at risk issue markers: waiting on EBSI to give us concrete examples
15:07:12 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1479
15:07:19 <wes-smith> ... for next item, 1479, we need a language map example, Mahmoud raised a PR but the PR didn't have a language map
15:07:43 <wes-smith> is Dmitri in IRC?
15:08:07 <przemek> przemek has joined #vcwg
15:08:49 <wes-smith> manu: Dmitri's contribution will take care of 1479, for next item Ivan has raised a PR
15:09:00 <wes-smith> ... once those three are done, no more issues on VCDM
15:09:00 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1534
15:09:20 <wes-smith> ... only thing waiting on then is for test suites to demonstrate multiple independent implementations for every feature in specification
15:09:26 <wes-smith> ... when we hit that, ready for CR2 for VCDM
15:09:32 <brent> q+ to talk timing
15:09:36 <wes-smith> ... maybe wait until TPAC, maybe go to CR2 ASAP
15:09:48 <wes-smith> ... going to make full pass through spec to cleanup editorial issues
15:09:55 <brent> ack brent
15:09:55 <Zakim> brent, you wanted to talk timing
15:10:36 <wes-smith> brent: if we get controller document in a state to go to CR by end of month, can finish updating Data Integrity and VC-jose-cose so when we get to TPAC the rest of the documents are in a state to be ready for second CR
15:10:55 <wes-smith> ... strictly speaking, don't need test suite to be done to go into second CR for VCDM
15:10:55 <bigbluehat> q+ to give a quick test suite update
15:11:06 <brent> ack bigbluehat
15:11:06 <Zakim> bigbluehat, you wanted to give a quick test suite update
15:11:27 <wes-smith> bigbluehat: we have been running test suite office hours right before this call, running weekly until TPAC, come if you have implementations that you need help integrating with test suites
15:11:37 <wes-smith> ... all but small handful of tests written for VCDM, those should be done by end of week
15:11:59 <wes-smith> ... each MUST statement already has 2 implementations, one or two left or coming that don't have green check marks
15:12:19 <wes-smith> ... if you have an implementation and are interested in participating, next Wed at 10AM, please reach out with questions
15:12:41 <wes-smith> brent: is there a link to results page?
15:12:53 <bigbluehat> https://w3c.github.io/vc-data-model-2.0-test-suite/
15:12:53 <wes-smith> bigbluehat: yes, these run every Sunday morning, up to date as of Sunday
15:13:27 <wes-smith> ... only a handful of things not passing, just skimming there is one verifiable presentation test with only one check mark, everything else >1
15:14:03 <manu> q+
15:14:08 <wes-smith> decentralgabe: I have a template repo for the josecose test suite, have not gone through exercise of test vectors/normative statement tests
15:14:10 <brent> ack manu
15:14:49 <wes-smith> manu: we are dependent on SD-JWT being done to go to rec, based on cryptography review in EU digital wallet stuff, it raises questions on path forward for EUDI/SD-JWT, now discussion around modifying SD-JWT to support unlinkable ECDSA work
15:14:52 <decentralgabe> test suite template I mentinoed https://github.com/decentralgabe/vc-test-suite-template
15:14:54 <brent> q+ to talk sd-jwt timing
15:15:05 <wes-smith> ... that has undetermined timeline, what is our plan w.r.t SD-JWT and VC Jose cose
15:15:19 <wes-smith> ... JWT stuff safe, COSE stuff safe, SD-JWT not on predictable path
15:15:22 <brent> ack manu
15:15:25 <brent> ack brent
15:15:25 <Zakim> brent, you wanted to talk sd-jwt timing
15:15:27 <DavidC> DavidC has joined #vcwg
15:15:36 <DavidC> present+
15:15:57 <wes-smith> brent: had conversations at IETF with SD-JWT folks about this, their plan was to address the extensions to SD-JWT in a separate spec, SD-JWT going to working group last call before Nov
15:16:07 <wes-smith> ... working group last call IETF equivalent of candidate rec
15:16:17 <wes-smith> ... folks I talked to confident that SD-JWT itself pretty much done, working group agreed
15:16:45 <wes-smith> ... that said, should we get to the point where we need to go to proposed rec with VC-jose-cose and SD-JWT not yet at working group last call, don't know that we can keep it in the spec at that point
15:16:58 <wes-smith> ... should still be possible to keep SD-JWT in VC-jose-cose if timing continues to work out
15:17:00 <manu> Thanks for the update, Brent, that makes sense to me.
15:17:29 <brent> Tipic: VC Data Integrity
15:17:39 <manu> s/Tipic/Topic/
15:17:43 <manu> q+
15:17:46 <brent> https://github.com/w3c/vc-data-integrity/issues/272
15:17:54 <wes-smith> Brent: Data Integrity: we have one aspect of one key issue left
15:18:15 <wes-smith> Brent: an issue raised citing possible vulnerabilities, a solution has been presented, all aspects except one of that solution have been agreed upon
15:18:31 <wes-smith> ... the folks that raised the concerns believe that it would be most appropriate to add a mechanism for demonstrating context integrity
15:18:41 <wes-smith> ... other folks are concerned about the overhead of that and that it may not solve the problems
15:18:56 <wes-smith> ... that is the essence of what we want to talk about right now - how would folks feel about this? what should we do/not do?
15:19:01 <brent> ack manu
15:19:19 <manu> https://github.com/w3c/vc-data-integrity/issues/272#issuecomment-2230883816
15:19:46 <wes-smith> manu: 272 has 143 comments now, been discussed extensively, Gabe made a proposal many weeks ago that had broad support for a number of the items, can follow your nose to what Gabe suggested and how those things went into PRs
15:20:09 <wes-smith> ... made adjustments to @vocab mechanism, took it out of core context, put in warnings about using it and how it might work in your benefit or against you
15:20:24 <wes-smith> ... proposal 0 that Gabe did, fully implemented
15:20:33 <wes-smith> ... the other thing that we ended up implementing was enhancing context validation
15:20:40 <wes-smith> ... didn't spell out how to do it before
15:20:59 <wes-smith> ... arguably the main issue with the security issue raise, that they weren't checking their context values
15:21:12 <wes-smith> ... we now have a normative context validation algorithm in the Data Integrity specification
15:21:21 <wes-smith> ... eventually that algorithm should be pushed to the JSON-LD spec
15:21:32 <wes-smith> ... and the VCDM says that you should understand context values before doing any business logic
15:21:55 <wes-smith> ... we can write tests for this algorithm in the test suite to test against implementations
15:22:16 <wes-smith> ... that was the second proposal, the other thing was clarifying the processing model (what's the order of steps etc.), that is in as a PR
15:22:41 <brent> q+
15:22:43 <wes-smith> ... the only thing that we now need to focus on is: do we need to put mandatory context integrity protection into the digital signature in Data Integrity
15:23:07 <wes-smith> ... I don't think it addresses the issue at hand, the problem with the security disclosure is that an important check was not being done
15:23:20 <wes-smith> ... we have a mechanism to do context integrity protection w/ related resource
15:23:38 <wes-smith> ... tying this any deeper into the crypto layer is problematic as it prevents certain use cases
15:23:42 <DavidC> q+
15:23:58 <wes-smith> ... not possible to go to CBOR-LD in certain cases, not possible for entities receiving a message to use their own context
15:24:10 <wes-smith> ... in RDFC use case it doesn't make sense b.c. you are already signing the quads
15:24:22 <wes-smith> ... there is an argument in JCS case, but could use resource integrity there
15:24:40 <decentralgabe> q+ to ask about resource integrity
15:24:46 <dlongley> +1 to allowing issuers (if they desire) to use related resource, +1 to never forcing a particular context on holders and verifiers, they should be free to translate/recompact. +1 that the forcing wouldn't fix the issue anyway.
15:24:46 <wes-smith> ... all doing this tells you is that you are using the same content hash that the issuer used when they created it, this is insufficient to protect against the kind of attack in 272
15:25:07 <brent> ack brent
15:25:10 <wes-smith> ... what's being proposed 1. doesn't address the core issue 2. prevents important use cases 3. is redundant w.r.t an existing feature
15:25:28 <dlongley> -1 to a recommendation that would preference it
15:25:33 <dlongley> q+
15:25:36 <wes-smith> Brent: would it be possible to add a recommendation that folks do resource integrity? would that be a means of satisfying the folks who have raised this issue?
15:25:42 <wes-smith> ... curious what the drawbacks of that would be
15:25:59 <brent> ack DavidC
15:26:00 <wes-smith> ... it's something that we have defined, is straightforward, and maybe would do no harm
15:26:14 <dlongley> +1 to DavidC
15:26:21 <wes-smith> DavidC: my suggestion would be weaker, just to add a note saying that if the issuer wishes they can integrity protect the context with related resource
15:26:21 <dlongley> q-
15:26:22 <manu> +1 to DavidC's proposal
15:26:22 <brent> ack decentralgabe
15:26:23 <Zakim> decentralgabe, you wanted to ask about resource integrity
15:26:30 <wes-smith> decentralgabe: +1 to DavidC's proposal
15:27:05 <wes-smith> brent: would anyone be opposed to adding this note? anyone want to argue that the context integrity stuff absolutely must happen?
15:27:10 <manu> q+
15:27:22 <brent> ack manu
15:27:24 <wes-smith> brent: we have a path forward, do we have a volunteer to raise this PR
15:27:27 <wes-smith> manu: I can raise this PR
15:27:44 <manu> q+
15:27:53 <brent> ack manu
15:27:58 <wes-smith> brent: we raise the PR, we go into the issue and list the PRs that have been raised, we as a working group believe this addresses the issue, then close the issue - is that right?
15:28:40 <wes-smith> manu: sounds good, one thing we can always do is strengthen requirements, if you are working in an ecosystem that needs this, in their spec they can mandate that verifiers must check this, at the base layer we are saying that you can use this feature, but in another spec using this you can make it a must
15:29:01 <dlongley> +1 to profiles being allowed that can require this or anything else (not encouraging anyone to profile in any particular way though)
15:29:03 <wes-smith> ... it'
15:29:20 <wes-smith> ... it's mostly at application layer, in a particular ecosystem verifiers must check this etc
15:29:33 <brent> Topic: Controller Document
15:29:36 <manu> q+
15:29:43 <wes-smith> brent: that topic done, next topic is Controller Document
15:30:06 <brent> ack manu
15:30:28 <wes-smith> manu: just to report where we are on Data Integrity and existing crypto suites, if we can close 272, we are out of issues for Data Integrity as well, same place as VCDM: need an editorial sweep and to make sure implementations are coming in, but not required for second CR
15:30:38 <wes-smith> ... we can do that for ECDSA and EDDSA as well as Data Integrity
15:30:59 <wes-smith> ... not able to do that for BBS, will be out of issues for that soon, but gated by IETF doing their review of BBS which is taking a long time
15:31:15 <brent> https://github.com/w3c/controller-document/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
15:31:19 <wes-smith> ... trying to get other cryptographers to do a separate review, but still won't be able to transition BBS cryptosuite at same speed as others
15:31:36 <wes-smith> brent: 14 Controller Document issues, going to do some issue processing
15:32:06 <wes-smith> ... the question to the group for each issue is: what needs to be done/changed to address it (if anything), and if something must be done, who will do it
15:32:16 <wes-smith> ... if folks stay silent, likely the issue will just be closed
15:32:22 <brent> subtopic: https://github.com/w3c/controller-document/issues/33
15:32:34 <wes-smith> ... first issue: 33. What is the role of the subject when the controller property is present
15:32:37 <manu> q+
15:32:53 <dmitriz> dmitriz has joined #vcwg
15:33:03 <wes-smith> ... first question: DavidC, was dlongley's suggestion adequate, would this suggestion resolve your concern?
15:33:08 <brent> ack manu
15:33:15 <wes-smith> DavidC: Yes, this knowledge needs to be explicit in the spec
15:33:20 <wes-smith> manu: I can write this PR
15:33:33 <brent> subtopic: https://github.com/w3c/controller-document/issues/5
15:33:43 <wes-smith> brent: next #5. Mike not able to join us today
15:34:00 <wes-smith> ... most examples using public key multibase not public key jwk, need both in examples
15:34:07 <wes-smith> ... is anyone opposed to doing this?
15:34:18 <wes-smith> ... will anyone take on the task of doing this?
15:34:31 <wes-smith> manu: I can get to it eventually but not immediately.
15:34:49 <wes-smith> brent: decentralgabe you are another person well suited to address this.
15:35:00 <wes-smith> decentralgabe: yes you can assign me.
15:35:17 <wes-smith> brent: if you want to interact with Mike and get him assigned as well that is fine.
15:35:20 <brent> subtopic: https://github.com/w3c/controller-document/issues/34
15:35:24 <wes-smith> ... next up: issue 34
15:35:32 <wes-smith> manu: I assigned myself, will do this one and 25
15:35:46 <wes-smith> s/25/35
15:36:00 <brent> subtopic: https://github.com/w3c/controller-document/issues/10
15:36:00 <wes-smith> manu: don't need group feedback for these editorial PRs
15:36:15 <wes-smith> brent: next issue #10, currently assigned to ivan
15:36:32 <wes-smith> ... Ivan presented a plan, just implementing the plan that was proposed last time we talked
15:36:39 <JoeAndrieu> q+ to talk about the prior issue (#33) if/when appropriate
15:36:46 <wes-smith> ... Ivan has said he will do it, it will get done.
15:36:50 <brent> ack JoeAndrieu
15:36:50 <Zakim> JoeAndrieu, you wanted to talk about the prior issue (#33) if/when appropriate
15:37:21 <wes-smith> JoeAndrieu: I had to review the issue to try and understand if my interpretation was right or not, I'm concerned people might be imagining that subject has some power, there might be a mismatch between David's actual concern and that other issue
15:37:35 <wes-smith> brent: Please indicate that in the comments, we can keep going and loop back if there is time
15:37:45 <brent> subtopic: https://github.com/w3c/controller-document/issues/7
15:37:46 <manu> q+
15:37:48 <wes-smith> brent: next up #7, make conformance classes a top level section
15:37:56 <brent> ack manu
15:37:58 <wes-smith> ... manu this is assigned to you - conversation needed for the group?
15:38:42 <wes-smith> manu: on 6/30 I reported that the group has discussed this twice, no support to make this change, following same approach as in other specs, I marked this issue pending close, Mike disagreed and removed the label, I don't think anything has changed and we are not expecting to make this change, group should make decision so we can close the issue.
15:38:56 <TallTed> q+
15:38:57 <wes-smith> ... proposal: do not make conformance classes a top level section to conform with other specs
15:39:06 <brent> ack TallTed
15:39:31 <wes-smith> TallTed: +1 manu, perhaps we should push back on Mike to change Jose-cose to conform with the rest of the specs created by this WG
15:39:36 <manu> +1 to TallTed's suggestion that VC-JOSE-COSE should follow what all the other specs do.
15:39:46 <wes-smith> brent: not hearing any pushback on Manu's proposal, going to marked this issue closed
15:39:55 <PL-ASU> +1 to Manu's request to close issue #7
15:40:13 <brent> subtopic: https://github.com/w3c/controller-document/issues/12
15:40:29 <wes-smith> brent: moving on to #12, proof purpose seems unnecessary in controller document spec
15:40:41 <wes-smith> ... there seems to be a mismatch, what do folks think about this
15:40:49 <wes-smith> manu: I took this, it's ready for PR, I just need to raise the PR
15:40:56 <decentralgabe> opened https://github.com/w3c/vc-jose-cose/issues/284
15:41:09 <brent> subtopic: https://github.com/w3c/controller-document/issues/21
15:41:16 <wes-smith> brent: next up #21 raised by Ivan
15:41:40 <wes-smith> ... we have an informative reference to VCDM, copy-paste artifact, proposal is to remove that
15:42:02 <wes-smith> ... hopefully Ivan will act on that and move forward
15:43:03 <wes-smith> manu: I was going through the spec, we can remove most of the references, but we have a section on binding to a physical identity that references VCDM, in content integrity we say that if you want to do content integrity read about it in VCDM, we could point to data integrity, this feels like if someone blanket removes these statements it's an
15:43:03 <wes-smith> issue, probably can remove most of them
15:43:22 <brent> subtopic: https://github.com/w3c/controller-document/issues/20
15:43:24 <wes-smith> brent: that comment will get into the issue and hopefully be reflected in Ivan's PR
15:43:40 <manu> q+
15:43:49 <brent> ack manu
15:43:54 <wes-smith> ... next, #20, add the SRI datatype?
15:44:04 <wes-smith> manu: I prefer not to move it since we don't use SRI in Controller Document
15:44:34 <wes-smith> ... the most pure thing to do is put it in Data Integrity spec but there were objections to that before so we decided to move it to where digestSRI and digestMultibase used, that was VCDM
15:44:47 <wes-smith> ... we don't use related resource or digestMultibase in Controller Document specification
15:45:17 <wes-smith> ... Controller Document does define Multibase and Multihash, but does not have relatedResource, which is the only place the SRI datatype is used.
15:45:22 <wes-smith> ... I think they're in the right places.
15:45:46 <wes-smith> ... If we move the SRI datatype into Controller Document, we don't talk about it anywhere else in that spec.
15:45:55 <wes-smith> brent: proposal is to close this issue with no action?
15:45:57 <wes-smith> manu: Correct.
15:46:05 <wes-smith> brent: Any opposition to marking this issue closed?
15:46:13 <wes-smith> ... hearing none, marked pending closed.
15:46:23 <wes-smith> ... next up, horizontal review tracking issues.
15:46:24 <brent> subtopic: https://github.com/w3c/controller-document/issues/22
15:46:40 <wes-smith> ... This is an opportunity for folks to report what they know about what is happening.
15:46:59 <manu> q+
15:47:00 <wes-smith> ... We have filled out this security/privacy review questionnaire in advance of review being done on Controller Document spec.
15:47:17 <wes-smith> ... I don't know how this is going elsewhere, we have requests in place but no indication that these requests are being acted on.
15:47:33 <wes-smith> ... A couple days ago, pending tag removed from a request, maybe a clue that it is being worked on.
15:47:38 <brent> ack manu
15:47:40 <wes-smith> ... Security request still marked pending.
15:47:45 <manu> https://github.com/w3c/controller-document/issues/25
15:47:58 <wes-smith> manu: I have a tracking issue set up for all of them, #25, it looks like internationalization is done, but the others need a friendly nudge.
15:48:16 <wes-smith> brent: I need to ping, security, privacy, accessibility.
15:48:30 <wes-smith> ... with that, we have reached the end, meaning we can talk about #33 again.
15:48:31 <brent> subtopic: https://github.com/w3c/controller-document/issues/33
15:49:15 <wes-smith> JoeAndrieu: David had mentioned that if we don't have controller, does the subject get control back? But the subject doesn't have control, no mechanism for that, may have answered that incorrectly.
15:49:32 <wes-smith> DavidC: controller property is optional, if it's missing does the subject have control over setting Controller Document.
15:49:34 <decentralgabe> q+
15:49:42 <wes-smith> JoeAndrieu: subject may not be controller.
15:49:43 <manu> q+
15:49:47 <manu> q-
15:49:51 <brent> ack decentralgabe
15:49:52 <wes-smith> DavidC: Something needs to be said, if no controller property who has control?
15:50:04 <manu> q+
15:50:10 <brent> q+
15:50:20 <wes-smith> decentralgabe: It should be explicit who the controller is, might not be subject even if no controller present, would like more detail on "depends on VDR", would like to always see controller present
15:50:53 <wes-smith> manu: agree with Joe that it depends on VDR, don't think that saying that controller must always exist is a good idea, some use cases where that doesn't make sense e.g. write only things
15:51:25 <wes-smith> ... language we could add is to say that if controller not set, controller is determined by policy of the VDR
15:51:32 <JoeAndrieu> q+ to suggest a SHOULD
15:51:37 <brent> ack brent
15:52:05 <wes-smith> brent: my view is that if there is a controller that is explicit then that entity is the controller, in absence of that, the controller by default would be the holder of the credential.
15:52:13 <wes-smith> ... if the holder is the subject or not is moot.
15:52:29 <brent> ack JoeAndrieu
15:52:29 <Zakim> JoeAndrieu, you wanted to suggest a SHOULD
15:52:30 <manu> q+ to note that it's ok for the controller to be "unknown"
15:53:34 <brent> ack manu
15:53:34 <Zakim> manu, you wanted to note that it's ok for the controller to be "unknown"
15:54:04 <wes-smith> manu: ok for controller to be unknown, for use cases there it's up to the VDR.
15:54:16 <dlongley> q+ to say we should make sure that what we do continues to work with layering DID docs on top of the controller doc spec
15:54:21 <wes-smith> ... -1 for saying you must specify controller in every controller document
15:54:27 <wes-smith> ... saying you SHOULD is a weaker form of that mistake
15:54:49 <wes-smith> ... trying to figure out when it matters to know who the controller is, typically only for updating, if not specified, the answer is "I don't know".
15:55:03 <wes-smith> ... It's been suggested that the subject is in control of it but that's not always true either.
15:55:31 <wes-smith> ... Brent, you mixed VCs in with it, and I think that's fine in a VC interpretation, but the controller document is not really playing a part in that question in that way.
15:55:39 <wes-smith> ... all that to say that it's OK for the controller to be unknown.
15:55:47 <wes-smith> ... SHOULD is a little dicey here.
15:55:51 <brent> ack dlongley
15:55:51 <Zakim> dlongley, you wanted to say we should make sure that what we do continues to work with layering DID docs on top of the controller doc spec
15:56:08 <wes-smith> dlongley: my main point is that whatever we do here should continue to allow layering DID documents on top of controller document spec.
15:56:27 <manu> q+
15:56:30 <wes-smith> brent: no longer have agreement on path forward on #33 - any suggestions? what action if any should be taken?
15:56:33 <brent> ack manu
15:56:53 <decentralgabe> +1 to that we need to know who's flying the plane
15:56:54 <wes-smith> manu: the only thing I can think of to reach consensus is to say it's up to the VDR to say who the controller is if it's not specified in the document.
15:57:12 <DavidC> q+
15:57:15 <wes-smith> brent: that's the path we have, we will say as much as we can, ok that sometimes you might not know who is flying the plane.
15:57:23 <wes-smith> ... We talked about everything we wanted to talk about.
15:57:27 <brent> ack DavidC
15:57:53 <wes-smith> DavidC: re: manu, if we say the VDR says who is in control if the controller document doesn't say that's fine, but we need to say that if controller is present it overrides VDR
15:58:03 <wes-smith> JoeAndrieu: We can't override VDR
15:58:05 <dlongley> the VDR allowed that controller property to exist
15:58:10 <manu> q+
15:58:11 <dlongley> it's not an "override"
15:58:16 <wes-smith> DavidC: this yields a contradiction when VDR and document say different things
15:58:25 <wes-smith> manu: controller document establishes what all VDRs must do
15:58:47 <wes-smith> ... the rules for VDRs. I agree, we put ourselves in weird position if we say the controller field is entirely dependent on VDR.
15:58:59 <JoeAndrieu> q+ to say what controller property is, is not VDR specific
15:59:12 <wes-smith> ... I don't know if it's an override, as dlongley says
15:59:16 <brent> ack manu
15:59:19 <brent> ack JoeAndrieu
15:59:19 <Zakim> JoeAndrieu, you wanted to say what controller property is, is not VDR specific
15:59:27 <wes-smith> JoeAndrieu: we need more time kicking this around, there are subtleties that need discussion.
15:59:35 <wes-smith> brent: thanks all, looking forward to seeing PRs.
16:00:21 <brent> zakim, end the meeting
16:00:21 <Zakim> As of this point the attendees have been TallTed, hsano, manu, DavidC, decentralgabe, bigbluehat, PL-ASU, seabass, JennieM, KevinDean
16:00:22 <Zakim> RRSAgent, please draft minutes
16:00:23 <RRSAgent> I have made the request to generate https://www.w3.org/2024/07/31-vcwg-minutes.html Zakim
16:00:26 <Zakim> I am happy to have been of service, brent; please remember to excuse RRSAgent.  Goodbye
16:00:30 <Zakim> Zakim has left #vcwg
16:00:36 <brent> rrsagent, bye
16:01:10 <brent> rrsagent, make logs public
16:01:18 <brent> rrsagent, bye
16:01:18 <RRSAgent> I see no action items