14:55:42 <RRSAgent> RRSAgent has joined #vcwg-special
14:55:46 <RRSAgent> logging to https://www.w3.org/2023/06/27-vcwg-special-irc
14:56:21 <brent> zakim, start the meeting
14:56:21 <Zakim> RRSAgent, make logs Public
14:56:22 <Zakim> please title this meeting ("meeting: ..."), brent
14:56:22 <brent> meeting: VCWG Special Topic Call
14:56:22 <brent> chair: Kristina Yasuda
14:56:35 <brent> brent has changed the topic to: Meeting Agenda 2023-06-27: https://www.w3.org/events/meetings/f6342df0-f7b5-4fc9-babd-61e55dc5fc2f/20230627T110000/
14:56:44 <brent> present+
14:58:30 <Paul_Dietrich_GS1> Paul_Dietrich_GS1 has joined #vcwg-special
15:01:28 <mprorock> mprorock has joined #vcwg-special
15:01:30 <manu> present+
15:01:32 <mprorock> present+
15:01:46 <oliver> oliver has joined #vcwg-special
15:01:48 <oliver> present+
15:02:29 <hsano> hsano has joined #vcwg-special
15:02:35 <decentralgabe> decentralgabe has joined #vcwg-special
15:02:40 <decentralgabe> present+
15:02:54 <Paul_Dietrich_GS1> present+
15:03:07 <DavidC> DavidC has joined #vcwg-special
15:03:13 <DavidC> present+
15:04:03 <hsano> present+
15:04:08 <kristina> kristina has joined #vcwg-special
15:04:11 <kristina> present+
15:04:18 <dlehn> dlehn has joined #vcwg-special
15:04:33 <TallTed> present+
15:04:43 <cabernet> cabernet has joined #vcwg-special
15:05:01 <cabernet> present+
15:05:09 <JoeAndrieu> JoeAndrieu has joined #vcwg-special
15:05:19 <pl-asu> pl-asu has joined #vcwg-special
15:05:26 <pl-asu> present+
15:05:28 <Paul_Dietrich_GS1> scribe+
15:06:42 <Will> Will has joined #vcwg-special
15:06:42 <Will> present+
15:06:46 <brent> zakim, who is here?
15:06:46 <Zakim> Present: brent, manu, mprorock, oliver, decentralgabe, Paul_Dietrich_GS, DavidC, hsano, kristina, TallTed, cabernet, pl-asu, Will
15:06:48 <Zakim> On IRC I see Will, pl-asu, JoeAndrieu, cabernet, dlehn, kristina, DavidC, decentralgabe, hsano, oliver, mprorock, Paul_Dietrich_GS1, RRSAgent, Zakim, brent, TallTed, manu,
15:06:48 <Zakim> ... dlongley, shigeya, stenr, csarven
15:07:04 <JoeAndrieu> present+
15:07:04 <kristina> topic: https://github.com/w3c/vc-data-model/pull/1140
15:07:18 <Paul_Dietrich_GS1> kristina discussing agenda.  First topic 1140.
15:07:24 <brent> present+ dlongley
15:07:30 <dmitriz> dmitriz has joined #vcwg-special
15:07:38 <dmitriz> present+
15:07:42 <andres> andres has joined #vcwg-special
15:07:45 <andres> present+
15:07:59 <Paul_Dietrich_GS1> kristina goal of the goall of the call today is to seek approval for the PR
15:08:25 <kristina> 164 PR comments is telling
15:08:42 <Paul_Dietrich_GS1> brent this tend to work best if PRs are always associated with issues. This PR came from an issue from another repo.  Strongly encourage folks to raise and issue
15:08:48 <Paul_Dietrich_GS1> . . . even if the PR is simple.
15:09:17 <pl-asu> q+
15:09:33 <kristina> q?
15:09:37 <Paul_Dietrich_GS1> kristina 164 PR comments is not ok.  We are close to merging so we will move forward, but going forward be careful [use issues]
15:09:42 <kristina> ack pl-asu
15:09:48 <mprorock> q+
15:10:29 <Paul_Dietrich_GS1> pl-asu issue 831 may be considered the antecedent to this issue This one was closed by the WG and this PR opens it. Should we reconsider
15:10:31 <Orie> Orie has joined #vcwg-special
15:10:34 <Orie> present+
15:10:56 <kristina> ack mprorock
15:11:04 <manu> s/pl-asu issue/pl-asu: issue/
15:11:34 <brent> present+ andres
15:12:11 <Paul_Dietrich_GS1> mprorock: Opened on VC JWT originally for a good reason.  There is a JSON LD data model that implies use of a context.  If you are using the context to transform data its important that the context
15:12:29 <selfissued> selfissued has joined #vcwg-special
15:12:36 <Paul_Dietrich_GS1> ... is the same on both side.  Other conversation going on around context and things like MIM and other modifications that can lead to a bad processor
15:12:42 <Orie> Context integrity mostly matters for the RDF representation, this mostly impacting data integrity proofs at the sign and verify interface, see https://github.com/w3c/vc-data-model/issues/1151#issuecomment-1608368735
15:12:46 <selfissued> present+
15:13:16 <Paul_Dietrich_GS1> ... This PR was open specifically to deal with a way to encode a hash for the context so you know on both sides (issuer and verifier) that its the same.
15:13:17 <Orie> if also applies to JSON only representations, if you care to get the *same* graph out on different verifiers.
15:13:37 <Orie> s/if also/it also/
15:14:43 <Paul_Dietrich_GS1> ... The implication is that this PR was not intended to be a reopening of 831.  There is a relation to things described in 831.  When this became PR 1140,
15:14:44 <Paul_Dietrich_GS1> ...
15:14:58 <kristina> q?
15:15:28 <kristina> 831 jfyi: https://github.com/w3c/vc-data-model/issues/831
15:15:31 <Paul_Dietrich_GS1> ... it expanded out to become a little broader but its not the intention to expand to a PR like 831.
15:15:36 <manu> The suggestion that context integrity mostly matters for RDF is just not true, but we don't have to go there to process this PR.
15:15:38 <manu> q+
15:16:49 <Paul_Dietrich_GS1> ... from a capability standpoint I welcome feedback but I i think everyone thinks this is a good capability.
15:17:16 <kristina> ack manu
15:17:52 <Paul_Dietrich_GS1> manu: speak in favor of the PR.  A number of significant changes from last week. This can be used as a general mechanism to refer to a URL within a verifiable credential
15:18:36 <Paul_Dietrich_GS1> ... its really useful to link to external resources like pdf, images, audio etc.   It also now matches the naming of the hash expression is the digest SRI
15:19:00 <dmitriz> q+
15:19:03 <dlongley> +1 to manu and comments on different digest formats and features in the community.
15:19:11 <Paul_Dietrich_GS1> ... which allows for other digest mechanisms from other communities.  A number of issue markers have been added.
15:19:44 <Paul_Dietrich_GS1> ... an issue marker to make it clear that its an ongoing discussion on whether this can be used throughout the group.
15:19:55 <kristina> ack dmitriz
15:19:59 <dlehn> q+
15:20:35 <Paul_Dietrich_GS1> dimitriz: Thanks Mike for the hard work on this. Really helpful and necessary +1.  In my ideal dimitri world I would love to see an optional canonicalization mechanism.
15:20:46 <mprorock> q+
15:20:49 <manu> q+
15:20:53 <kristina> ack dlehn
15:21:07 <Orie> -1 to JCS, +1 to hash agility based on an existing hash algorithm registry.
15:21:15 <Paul_Dietrich_GS1> dlehn: Has anyone implemented this yet? Is that part of the PR or coming in the future?
15:21:34 <dmitriz> @Orie - -1 to /any/ canonicalization, or just JCS?
15:21:37 <Paul_Dietrich_GS1> kristina: has anyone else implemented
15:21:39 <kristina> ack mprorock
15:21:40 <Orie> I have proved that you can break things, when you don't do this... does that count?
15:22:13 <Paul_Dietrich_GS1> mprorock:  as far as implementation David, we have a test implementation in go and python.  python will be released as open source.  go implementation will push to aries frameork go.
15:22:15 <dmitriz> @Orie - which this?
15:22:41 <Orie> In general, using different contexts breaks data integrity proofs in confusing ways for most developers.
15:23:20 <Orie> (because you get different n-quads for the verifier, than what the issuer intended to be produced)
15:23:34 <Paul_Dietrich_GS1> ... One comment back to dmitriz. The has method was defined originally as a separate property.  I went with this approach after feedback that a separate term could cause graph problems
15:23:43 <dmitriz> @Mike - ohhh I see, makes sense
15:23:51 <Orie> dmitriz see this issue for an example: https://github.com/w3c/vc-data-model/issues/1151#issuecomment-1608368735
15:23:58 <kristina> ack manu
15:24:33 <Paul_Dietrich_GS1> manu: 2 things.  other issues marker is a statement that says that if related resources exists, you must include all context in the document in the related resource array.
15:24:41 <Orie> +1 to that language not being clear enough.
15:24:49 <mprorock> +1 needs improvement
15:24:55 <Paul_Dietrich_GS1> ... Digital bazaar would reject this language as is, but expect further conversation on the issue marker.
15:25:23 <Paul_Dietrich_GS1> ... The topic mike just mentioned "why specific algorithm and value in the same string'.  If you break it out,  you could have multiple hashes listed
15:25:32 <mprorock> q+ to note benefit of multiple hashes
15:25:36 <Orie> is this a feature or a bug?
15:25:47 <dlongley> each hash algorithm becomes a "property and value" of the resource, which is bizarre -- it also makes schema processing more complicated vs. layering separation.
15:25:54 <Paul_Dietrich_GS1> ... and then if you have separate hashes you would have to match each hash with the value.  So just using SRI or mutibase/multihash because when you read it
15:25:55 <dlongley> if it is broken out as a separate property.
15:26:11 <Paul_Dietrich_GS1> ... you know what resource you are dealing with.
15:26:26 <Orie> I think its pretty common to provide multiple hashes for resources, see https://github.com/microsoft/sbom-tool/blob/main/samples/manifest.spdx.json
15:26:33 <dlongley> it's absolutely a feature to have consistent data modeling vs. free for all (something the VCDM introduces over "anything goes JSON")
15:26:51 <Paul_Dietrich_GS1> kristina: There is still language to be fleshes out. are we merging it.
15:27:01 <Orie> Seems the design comments here, don't match software supply chain security work I an aware of.
15:27:30 <Paul_Dietrich_GS1> mprorock: manu made a comment about multiple hashes.  By pointing to SRI we permit that.  Specifically for constrained environments.
15:28:09 <Paul_Dietrich_GS1> ... There are cases like ARMV7 or v8 where you might only have SHA256 available.  There are reason to permit multiple has values.  We would up in a better place with this PR.
15:28:11 <Orie> +1 mprorock, providing multiple hashes supports constrained environments, that don't ship a kitchen sync of hash algorithms.
15:28:19 <dmitriz> +1
15:28:29 <Paul_Dietrich_GS1> manu: Can I merge after the call?
15:28:59 <Paul_Dietrich_GS1> kristina: Thinking about moving to the next agenda. Does the group want to keep discussing the details?
15:29:11 <manu> I will merge this PR after the call.
15:29:15 <Paul_Dietrich_GS1> kristina: manu, please merge after the call.
15:29:27 <mprorock> q+
15:29:50 <Paul_Dietrich_GS1> kristina: Any objects to move to 1101 and 1100? It was not on the agenda.
15:29:51 <kristina> ack mprorock
15:29:51 <Zakim> mprorock, you wanted to note benefit of multiple hashes and to
15:29:58 <mprorock> https://github.com/w3c/vc-data-model/pull/1158
15:30:29 <Paul_Dietrich_GS1> mprorock: Suggest a quick diversion to 1158 since its related to 1140.  There are a couple change I suggested to bring the language into alignment.  If we are talking about hasing
15:30:39 <Paul_Dietrich_GS1> ... we should use the same mechanism with the core data model.
15:31:07 <manu> q+
15:31:15 <Paul_Dietrich_GS1> ... 1158 as is is inconsistent with 1140. I provided text to make those two consistent.
15:31:42 <Paul_Dietrich_GS1> kristina: lets talk about 1158
15:31:45 <kristina> ack manu
15:32:12 <Paul_Dietrich_GS1> manu: fine with these changes. Concern that it sounds like an argument is constructed based on these changes that puts us on a slippery slope.
15:32:39 <mprorock> q+
15:32:40 <Orie> q+ to disagree
15:33:11 <Paul_Dietrich_GS1> ... This changes argues over how we express the hash as base64 or hexidecimal.  We can make this change. +1, but I have a feeling its not the last we will hear about this.
15:33:32 <Paul_Dietrich_GS1> ...Is this part of a larger suggest to change the way we represent hashes and other values across our specifications.
15:33:42 <kristina> q?
15:33:43 <Paul_Dietrich_GS1> kristina: How is this a slippery slope
15:33:58 <Paul_Dietrich_GS1> manu: The next argument could make that all DI specification need to follow the SRI encoding format.
15:33:58 <Orie> CEPC lets assume positive intent.
15:34:08 <dlongley> -1 to doing anything that would prohibit or malign the use of digestMultibase
15:34:14 <kristina> ack mprorock
15:34:19 <Paul_Dietrich_GS1> kristina: clarify that the scope is only the VC DM.  Would not apply to data integrity
15:35:02 <dlongley> +1 to Orie, let's assume positive intent, there's no goal here to prohibit or malign digestMultibase through this action.
15:35:23 <Paul_Dietrich_GS1> mprorock: This PR is solely to bring it up to 384 and encode the digest according to the SRI spec. this is focused just on the core data model.
15:35:32 <manu> As long as what MikeP is saying holds, we're all good here. :)
15:35:48 <kristina> thanks Orie and dave re positive intent comments
15:35:49 <Orie> I am still unsure if we can normatively depend on multiformats / multibase in a W3C TR... but that is not what resource integrity or securing the core context is about.
15:36:16 <kristina> ack Orie
15:36:16 <Zakim> Orie, you wanted to disagree
15:36:26 <dlongley> Orie: we can, and it's already been done in the past (e.g., DID core).
15:36:46 <Paul_Dietrich_GS1> orie: agree with mike prorock. When we look at resource integrity for context, context is a resource.  we found a way to make the context values normative
15:37:50 <Paul_Dietrich_GS1> ... by specifying a cryptographic hash function.  many ways to represent hashes. Data integrity proof relies on multiformat.  totally separate from describing how to secure resource securely
15:37:55 <Paul_Dietrich_GS1> ... in the core data model.
15:38:00 <manu> Good, I'm glad we have confirmation from both Orie and MikeP on those points.
15:38:03 <manu> We're good to merge.
15:38:08 <manu> (afaict)
15:38:33 <dlongley> What Orie said is why this was so related to #831 -- and does some of what it was trying to do.
15:38:35 <Orie> I suspect we may see formal objections in the "hash" is used to make "down refs" normative, but we will see.
15:38:48 <Paul_Dietrich_GS1> kristina: PR 1158 we have agreement to align with 1140.
15:39:03 <Paul_Dietrich_GS1> kristina: we have 15 minutes left. Any other PRs related to this topic?
15:39:25 <manu> q+
15:40:01 <manu> q-
15:40:02 <Orie> Can we close the PRs that are not getting consensus?
15:40:17 <Paul_Dietrich_GS1> kristina: are we OK to bring up 1100 and 1101?
15:40:45 <manu> q+
15:40:48 <manu> q-
15:40:59 <Paul_Dietrich_GS1> brent: Can we get a sense of where each of the PRs are? we have 15 open PRs.  Can we go through each of the PRs briefly?
15:41:01 <manu> q+
15:41:07 <manu> q+ to go through some PRs.
15:41:40 <Paul_Dietrich_GS1> kristina: WIll take up PRs where we have authors on the call. Start with 1101.
15:41:51 <kristina> subtopic: https://github.com/w3c/vc-data-model/pull/1101
15:42:25 <Orie> q+
15:42:29 <Paul_Dietrich_GS1> kristina: 1142.
15:42:34 <Orie> https://github.com/w3c/vc-data-model/pull/1142
15:42:37 <kristina> subtopic: https://github.com/w3c/vc-data-model/pull/1142
15:42:50 <Paul_Dietrich_GS1> brent: 1142 updates the reservation table with confirmation method and render method.  Render method's URLs work. confirmation URL dont work yet.
15:42:53 <Orie> It is blocked pending adoption of the work item, which was JUST proposed to the CCG.
15:43:00 <Orie> q-
15:43:10 <Paul_Dietrich_GS1> ... as soon as that is officially adopted in the CCG the URLs will work and I will approve.
15:43:14 <Paul_Dietrich_GS1> kristina: Is there a timeline for that?
15:43:16 <kristina> q?
15:43:21 <manu> q-
15:43:36 <Orie> CCG already has 2 companies supporting it, it is waiting for acknowledgement by chairs, it cannot be blocked
15:43:50 <Paul_Dietrich_GS1> oliver: We just created the new work item proposal today.  others can give more details on timeline.
15:44:02 <Orie> Nobody can stop a CCG work item from being worked on when multiple companies support it.
15:44:23 <oliver> q+
15:44:36 <Paul_Dietrich_GS1> mprorock:  Harrison is chairing the meeting today and will note. Send a message to the chairs and we can expedite it. If you have multiple parties and there are no objectsions, it will go through
15:44:47 <oliver> q-
15:45:09 <Paul_Dietrich_GS1> kristina: If you want to follow the confidence method work, pay attention to the CCG.
15:45:22 <Paul_Dietrich_GS1> oliver: We are still looking for owners of the work item.
15:45:36 <Orie> q+
15:45:51 <kristina> ack Orie
15:45:56 <Paul_Dietrich_GS1> kristina: if you are interested in moving this forward,contact the CCG or reach out to oliver.
15:46:01 <manu> q+
15:46:26 <Paul_Dietrich_GS1> orie: Confused.  I though spruce and digital bazaar are sponsoring this work?
15:46:37 <Paul_Dietrich_GS1> oliver: We don't have the bandwidth to own the work. Didnt say we would not implement.
15:46:43 <manu> q-
15:46:51 <Paul_Dietrich_GS1> kristina: lets take these questions offline
15:47:31 <mprorock> +1
15:47:33 <Paul_Dietrich_GS1> manu: Digital bazaar is supportive of the work, but currently we don't have the bandwidh to be an owner of the work. We see value in it. cant work on it for 6 mo or so.
15:47:43 <Paul_Dietrich_GS1> kristina: Any coordinate needed with CCG?
15:47:57 <Orie> +1 to dropping it, given that nobody wants to work on it in ccg.
15:48:14 <Paul_Dietrich_GS1> mprorock: If there is no one working on it, can we drop it from the VCWG side?  On the CCG side we need two owners from different orgs to approve.
15:48:20 <Paul_Dietrich_GS1> kristina: Lets wait and see.
15:48:27 <kristina> subtopic: https://github.com/w3c/vc-data-model/pull/1149
15:48:35 <kristina> q
15:48:36 <kristina> q?
15:48:48 <selfissued> q+
15:49:11 <Paul_Dietrich_GS1> kristina: PR 1149.  what do we need to resolve?
15:49:24 <mprorock> q+
15:49:35 <kristina> ack mprorock
15:50:29 <dlongley> q+
15:50:39 <Paul_Dietrich_GS1> mprorock: find it weird that we are up to 22 comments when all this PR does it point over to the actual definition in the RFC.
15:50:52 <kristina> ack dlongley
15:51:16 <Paul_Dietrich_GS1> dlongley: there has been discussion in the PR around exactly as what the PR is doing. Don't think its as simple as what Mike is saying.
15:51:30 <mprorock> q+ this appears the same as including proof or other things
15:51:44 <mprorock> q+ to note this appears the same as including proof or other things
15:51:47 <Paul_Dietrich_GS1> ... would this cause people to use 1.1 or cause confusing with 2.0. There is a number of comments here and another case of
15:52:02 <Paul_Dietrich_GS1> ... a PR that was intended to be a simple thing, but need discussion to figure out what we need to do.
15:52:25 <TallTed> q+
15:52:32 <Paul_Dietrich_GS1> kristina: hopefully we get a bit more clarity.  we will not resolve it here.
15:52:39 <kristina> ack mprorock
15:52:39 <Zakim> mprorock, you wanted to note this appears the same as including proof or other things
15:53:06 <Paul_Dietrich_GS1> mprorock: note that based on previous comments, this PR (1149) is effectively doing the same as including the proof in the context.
15:53:17 <dlongley> mprorock, please read the comments in the PR, this was discussed
15:53:21 <dlongley> q+
15:53:25 <Paul_Dietrich_GS1> ... to me this is an either or. It only has core data model items, or has additional helpers. We can't have it both ways.
15:53:26 <Orie> +1 mprorock
15:53:30 <manu> It's not doing the same thing as proof in the context, that's the core of the disagreement -- you don't use iss/kid/etc like you use proof.
15:53:33 <kristina> ack TallTed
15:53:33 <dlongley> q-
15:53:54 <manu> Specifically, we have discussed this in the PR: https://github.com/w3c/vc-data-model/pull/1149#issuecomment-1605659418
15:53:57 <dlongley> mprorock: some of the things you're saying in the call here were discussed in the PR, please read the PR.
15:54:17 <Orie> https://w3id.org hosts this html file.
15:54:18 <Paul_Dietrich_GS1> TallTed: Lots of comments and they have substance to them.  Good to review them.  w3.org is a redirect service. Its not hosted. You can point a finger here.
15:54:36 <Orie> it also redirects to https://w3id.org/citizenship
15:54:46 <Paul_Dietrich_GS1> ... this PR has a title that is not reflective of what is happening in the PR.  Please update.
15:54:47 <manu> Agree that the PR is not titled appropriately.
15:55:03 <Orie> which defines https://w3id.org/citizenship#PermanentResidentCard
15:55:34 <Paul_Dietrich_GS1> TallTed: I cant provide an alternative because I'm not writing this.   If orie cannot rephrase it...
15:55:42 <kristina> ack selfissued
15:56:00 <TallTed> s/can point a finger/cannot point a finger/
15:56:06 <kristina> subtopic: https://github.com/w3c/vc-data-model/pull/1101
15:56:11 <Paul_Dietrich_GS1> selfissued: I rereviewed the status of 1101 and the related PR 1100 and I feel like we are at an impass.  It was intended to be a short summary of
15:56:30 <Orie> w3id.org also defines our normative concept of https://w3id.org/security#proof
15:56:53 <Paul_Dietrich_GS1> ... what we decided in Miami.  Some people were in favor.  I don't know how to unblock this because people are thinking that
15:56:56 <Paul_Dietrich_GS1> ... we mean different things.
15:57:15 <TallTed> https://w3id.org/security#proof redirects to https://w3c.github.io/vc-data-integrity/vocab/security/vocabulary.html#proof
15:57:15 <TallTed> w3id.org is NOT defining anything
15:57:15 <Paul_Dietrich_GS1> ... one suggestion to unblock it would be to quote the resolution as is and put that note in the spec.
15:57:24 <Paul_Dietrich_GS1> .. is that a path that I could pursue?
15:57:32 <manu> q+
15:57:38 <kristina> ack manu
15:58:12 <brent> q+ to ask about just closing both PRs
15:58:20 <Paul_Dietrich_GS1> manu:  mike, that might work. I think you are right. we are at an impass with the proposal. You did your best to captures something. One approach
15:59:10 <Paul_Dietrich_GS1> ... forward would be say that we were unable to write text around this that we could all agree to.  Do we want to spend time on this or on other things.
15:59:14 <Orie> TallTed, if w3id.org is compromised, proof could be defined and redirected to anything else... that is my point... previously proof pointed to the W3C CCG github... we should change what it redirects too, in this file: https://github.com/perma-id/w3id.org/blob/master/security/.htaccess
15:59:32 <Paul_Dietrich_GS1> ... That is where we are right now. I would not oppose a note that says the verbatim resolution, but say that the group would not
15:59:43 <Paul_Dietrich_GS1> .. s/would/could/ not write text.
15:59:44 <Orie> I said *should* I meant *could*
15:59:54 <Orie> meaning (people outside the W3C Working Group)
15:59:57 <brent> q-
15:59:59 <kristina> ack brent
16:00:00 <Paul_Dietrich_GS1> mprorock: I would not write text into the specification with negativity about the working group.
16:00:00 <mprorock> +1 selfissued
16:00:05 <Orie> +1 selfissued
16:00:42 <manu> s/mprorock: I wrote not/selfissued: I wrote not/
16:00:42 <cabernet> s/mprorock: I would/selfissued: I would/
16:00:44 <kristina> s/mprorock/selfissued
16:01:16 <Paul_Dietrich_GS1> selfissued: I would not write text into the specification with negativity about the working group.
16:01:29 <TallTed> RRSAgent, draft minutes
16:01:30 <RRSAgent> I have made the request to generate https://www.w3.org/2023/06/27-vcwg-special-minutes.html TallTed
16:01:37 <Paul_Dietrich_GS1> kristina: closing the meeting.
16:01:37 <Paul_Dietrich_GS1> scribe-
16:01:41 <TallTed> Worth noting as well that "the Miami resolution" was RUSHED through at the end of a session, and has since been quoted literally generally without consideration of the intent of the various folks involved in that discussion.
16:01:45 <brent> zakim, end the meeting
16:01:45 <Zakim> As of this point the attendees have been brent, manu, mprorock, oliver, decentralgabe, Paul_Dietrich_GS, DavidC, hsano, kristina, TallTed, cabernet, pl-asu, Will, JoeAndrieu,
16:01:48 <Zakim> ... dlongley, dmitriz, andres, Orie, selfissued
16:01:48 <Zakim> RRSAgent, please draft minutes
16:01:49 <RRSAgent> I have made the request to generate https://www.w3.org/2023/06/27-vcwg-special-minutes.html Zakim
16:01:55 <Zakim> I am happy to have been of service, brent; please remember to excuse RRSAgent.  Goodbye
16:01:55 <Zakim> Zakim has left #vcwg-special
16:02:07 <brent> rrsagent, bye
16:02:07 <RRSAgent> I see no action items