14:16:12 <RRSAgent> RRSAgent has joined #vcwg
14:16:16 <RRSAgent> logging to https://www.w3.org/2024/04/10-vcwg-irc
14:16:16 <Zakim> RRSAgent, make logs Public
14:16:17 <Zakim> please title this meeting ("meeting: ..."), ivan
14:16:26 <ivan> Meeting: Verifiable Credentials Working Group Telco
14:16:26 <ivan> Date: 2024-04-10
14:16:26 <ivan> Agenda: https://www.w3.org/events/meetings/0d074559-1457-4540-857b-24b1be7a8d7f/20240410T110000/
14:16:26 <ivan> chair: brent
14:16:27 <ivan> ivan has changed the topic to: Meeting Agenda 2024-04-10: https://www.w3.org/events/meetings/0d074559-1457-4540-857b-24b1be7a8d7f/20240410T110000/
14:24:37 <TallTed> TallTed has joined #vcwg
14:57:49 <ivan> present+
14:57:57 <ivan> present+ pauld
14:59:23 <brent> brent has joined #vcwg
14:59:25 <steele> steele has joined #vcwg
14:59:54 <brent> present+
15:00:38 <TallTed> TallTed has joined #vcwg
15:00:48 <ivan> present+ manu
15:01:13 <ivan> present+ TallTed
15:01:37 <ivan> present+ davidc
15:01:47 <ivan> present+ dlongley
15:01:52 <DavidC> DavidC has joined #vcwg
15:02:00 <DavidC> present+
15:02:14 <manu> present+
15:02:23 <ivan> present+ bigbluehat
15:02:35 <dmitriz> dmitriz has joined #vcwg
15:02:48 <ivan> present+ dmitriz
15:03:10 <bigbluehat> bigbluehat has joined #vcwg
15:03:19 <bigbluehat> present+
15:03:38 <pauld_gs1> pauld_gs1 has joined #vcwg
15:03:46 <pauld_gs1> present+
15:03:49 <dmitriz> scribe+
15:04:32 <dmitriz> brent: agenda today - work items, issue processing.
15:04:35 <ivan> q+
15:04:47 <brent> ack ivan
15:04:48 <dmitriz> ... any changes to the agenda or preferences?
15:04:59 <dmitriz> ivan: last week we said we'd vote for CR transition - was it today?
15:05:08 <dmitriz> ... at the moment, the day we had in mind was the 18th, which is next Thurs
15:05:27 <dmitriz> ... to do that, necessary to vote for it today. tho there are still minor issues to be settled before I can send it to management, and I dont' see Gabe
15:05:34 <dmitriz> brent: both Gabe and Mike are unable to join
15:05:39 <dmitriz> ivan: we'll have to postpone the CR
15:05:43 <dmitriz> brent: confirmed.
15:05:48 <manu> q+ to note next week is IIW
15:05:51 <dmitriz> ... we'll deal with it next week
15:05:58 <brent> ack manu
15:05:58 <Zakim> manu, you wanted to note next week is IIW
15:06:08 <dmitriz> manu: next week is IIW, and I expect a decent chunk to be gone for that as well
15:06:16 <ivan> q+
15:06:20 <dmitriz> ... I'm wondering if we could vote today anyway, and put it out to the mailing list to see if anyone objects
15:06:43 <dmitriz> ... I realize it's weird to do a vote without editors here, but I think everyone on the call last week heard that we'd do it this week, and people still have 7 days to object
15:06:56 <dmitriz> ... I'm afraid if we don't do it this week, next week we won't have enough people again, and it'll keep being delayed.
15:06:57 <brent> ack ivan
15:07:19 <dmitriz> ivan: that's one aspect, the other is - Gabe put out a CR text in a separate branch / PR. and I had some comments on the text that need to be addressed before merging
15:07:36 <dmitriz> ... so, the vote is one thing, final CR is another thing. and I don't feel like going there and doing changes myself (not even sure I could)
15:07:59 <dmitriz> ... if we vote today, it will not make things faster
15:08:11 <smccown> smccown has joined #vcwg
15:08:16 <dmitriz> brent: I don't mind putting a proposal in front of the group today as long as we can craft it properly
15:08:38 <dmitriz> ... Gabe mentioned to me that he was going to try and mend the PR with the draft; I don't see any current changes on it though
15:08:51 <dmitriz> ... if someone would like to craft a proposal to put in front of the group, I'm happy to run it
15:09:00 <dmitriz> ... I'm still planning to be on the meeting next week, even though it's IIW
15:09:15 <dmitriz> ... and if there's not enough people, it'll be a brief meeting
15:09:20 <dmitriz> ... anyone opposed to a proposal today?
15:10:01 <DavidC> q+
15:10:07 <brent> ack DavidC
15:10:31 <dmitriz> DavidC: I was just looking at the list of issues; there are a lot of issues, all flagged Post-CR. do we know for certain that when those issues are resolved, they won't require a second CR? or is not a problem?
15:10:35 <dmitriz> ivan: not a problem
15:10:51 <dmitriz> brent: I trust editors to triage appropriately
15:11:03 <dmitriz> ivan: to be clear, PR 265 must be addressed before we go on, but that's understood
15:11:09 <brent> PROPOSAL: Publish the vc-jose-cose specification based on https://pr-preview.s3.amazonaws.com/w3c/vc-jose-cose/pull/265.html as a W3C Candidate Recommendation with a 28 day CR period and a target date of April 18th for publication.
15:11:13 <ivan> +1
15:11:13 <manu> +1
15:11:15 <dlongley> +1
15:11:16 <brent> +1
15:11:19 <dmitriz> +1
15:11:23 <pauld_gs1> +1
15:11:25 <TallTed> +1+1
15:11:35 <manu> me :)
15:11:38 <bigbluehat> +1
15:11:44 <TallTed> s/+1+1/+1
15:11:52 <ivan> present+ smccown
15:11:55 <TallTed> s/me :)//
15:12:02 <smccown> +1
15:12:06 <brent> RESOLVED: Publish the vc-jose-cose specification based on https://pr-preview.s3.amazonaws.com/w3c/vc-jose-cose/pull/265.html as a W3C Candidate Recommendation with a 28 day CR period and a target date of April 18th for publication.
15:12:09 <TallTed> RRSAgent, draft minutes
15:12:10 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/10-vcwg-minutes.html TallTed
15:12:18 <dmitriz> brent: thanks all!
15:12:34 <brent> Topic: Work Item Status Updates/PRs
15:12:36 <dmitriz> ... let's jump into next topic
15:12:38 <manu> q+
15:13:01 <dmitriz> brent: I'm happy to announce that the status of vc-jose-cose has been approved to go to CR, hopefully a smooth transition
15:13:23 <dmitriz> ... number of post-cr issues on it, I trust will be resolved in due time. I do know the test suite for vc-jose-cose is in need of work; we have commitment from some people to do that though
15:13:25 <TallTed> s/Date: 2024-04-10//
15:13:25 <brent> ack manu
15:13:30 <dmitriz> manu: thanks brent, just to go over the other specs,
15:13:54 <dmitriz> ... we'll get to issue processing later. We have a healthy (small) list of issues on the core data model. that one media type discussion we need to have, the only real big question remaining
15:14:04 <dmitriz> ... a number of PRs on vc dm that need to be processed; largely editorial
15:14:12 <TallTed> s/manu, you wanted to note next week is IIW//
15:14:20 <TallTed> RRSAgent, draft minutes
15:14:22 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/10-vcwg-minutes.html TallTed
15:14:29 <ivan> q+
15:14:29 <dmitriz> ... for Bitstring Status List, I believe we have all the issues under control, would allow us to suggest a Candidate Rec post april 21st
15:14:57 <dmitriz> ... noting that we have actually had significant reviews from PING and the security group is aware of it, and is planning to do a review before or during CR
15:15:34 <dmitriz> ... the rest of the technical issues feel like theyr'e under control (internationalization - we do have an answer, if slightly shaky, around the messages in status list -- they're meant for devs not end users, so it's ok not to have i18n tags on them
15:15:42 <dmitriz> ... if we change our mind in the future, we can just use standard JSON-LD tags
15:16:08 <dmitriz> ... the potential F.O. about status list VCs being able to be changed after issuing, there's a PR for that (164)
15:16:24 <manu> Ensure that status messages are committed to at issuance time: https://github.com/w3c/vc-bitstring-status-list/pull/164
15:16:30 <dmitriz> ... which should address PING's and Joe's concerns around that
15:16:57 <dmitriz> ... although there have been questions raised around -- if messages have meaning only to developers, does that mean anything. I don't think those will lead to any kind of objections
15:17:15 <dmitriz> manu: bitstring status list is on a good path towards the end of April, so heads up to chair & editors
15:17:23 <brent> ack ivan
15:17:24 <dmitriz> ... should I prep the doc for CR, and of so, what's the target date?
15:17:41 <manu> q+
15:17:47 <dmitriz> ivan: there is an issue, 157, that requires manipulation on the repo level, you should take a look at
15:17:59 <brent> ack manu
15:18:03 <dmitriz> manu: +1 that needs to be fixed, I'll take a look
15:18:08 <dmitriz> ... that's a 'during CR' though
15:18:13 <dmitriz> ivan: should be done before
15:18:17 <dmitriz> manu: ok, let me change the label
15:18:57 <dmitriz> ... i'll handle it during my next edit cycle
15:19:09 <dmitriz> ... moving on to DI issues. VC DI is drawing a number of editorial changes, 3 are normative
15:19:29 <dmitriz> ... which will trigger a 2nd CR. same is true for ecdsa- and eddsa-, and probably BBS- as well, so look for PRs on those specs in the next few weeks,
15:19:34 <dmitriz> ... based on implementer feedback
15:19:43 <dmitriz> ... sometimes in normative statements, which is good, that's what CRs are for
15:20:07 <dmitriz> ... nothing major has come up though during CR though, no catastrophic security vulns, no formal objections brewing, etc
15:20:14 <dmitriz> ... I think that's true of all of our CR docs at this point
15:20:25 <dmitriz> brent: thank you manu. in general, regarding Bitstring Status List
15:21:12 <dmitriz> ... as soon as the docs are ready to move forward, we can move them forward
15:21:20 <manu> acknowledged, we'll do that ^
15:21:24 <ivan> present+ joe
15:21:25 <dmitriz> ... let's go to our VC DM issues
15:21:30 <brent> Topic: VCDM Issues
15:21:31 <brent> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc
15:21:57 <dmitriz> brent: first one we don't need to talk about, 1437, we know that needs to happen
15:22:06 <dmitriz> ... next one is 1239, we know that needs to happen
15:22:13 <JoeAndrieu> JoeAndrieu has joined #vcwg
15:22:15 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1462
15:22:22 <dmitriz> ... next topic to discuss is - 1462, revisit VC media type
15:22:29 <brent> https://mailarchive.ietf.org/arch/msg/media-types/iWc8TLcWOyO0jyqeiuF9VCZClIs/
15:22:40 <dmitriz> ... here's a link to the discussion that's continuing among the media type mgmt WG at IETF
15:22:55 <dmitriz> ... it's a long discussion, a number of us have taken part in it, have shared opinions
15:22:59 <manu> q+
15:23:06 <dmitriz> ... manu, if you would be willing to give the group a summary of where the thread has gone?
15:23:11 <brent> ack manu
15:23:29 <manu> Summary of what has happened to date: https://github.com/w3c/vc-data-model/issues/1462#issuecomment-2016609877
15:23:29 <dmitriz> manu: I won't go into the summary in too much depth, there's a link to it here
15:23:45 <dmitriz> ... we need to register a media type for VCs, we suggested using one that uses multiple suffixes, that has led to a long discussion at IETF over the past 5+ years
15:23:57 <dmitriz> ... we thought we were done as of last IETF, that was not the case, we don't know when we're gonna be done
15:24:12 <dmitriz> ... we're probably at the point that this group can't wait any longer for "the right thing to happen"
15:24:38 <dmitriz> ... a number of options has been brought up -- from use suffixes, to deprecate suffixes, and every variation in between
15:24:52 <dmitriz> ... based on the last 2 weeks, seems like eventually IETF is going to allow people to do whatever, in certain patterns and categories
15:25:04 <dmitriz> ... people are definitely using suffixes in some kind of ways, there seem to be different philosophies on it
15:25:33 <dmitriz> ... the outcome if we don't try and force the discussion to terminate any time soon is -- everything registered in the past in fine, here's some guidance for the future (for media types w suffixes)
15:25:50 <dmitriz> ... so what it seems like will happen, they'll punt the explanation of what suffixes mean back to the spec that is registering the suffix
15:26:06 <dmitriz> ... like "this is the media type we're registering, this is what suffixes mean, etc"
15:26:22 <dmitriz> ... we thought this was gonna end 6 months ago, and it hasn't yet, so that's where we are today
15:26:35 <dmitriz> ... we can take a couple of paths forward. there was the 'exception path' where we can register whatever
15:26:56 <dmitriz> ... option b was - not use any suffixes at all, and just use application/vc and /vp
15:27:11 <dmitriz> ... and then for SD-JWT, you can add +jwt to the end of that
15:27:18 <dmitriz> ... option c was - wait until discussion ends at IETF
15:27:33 <dmitriz> ... as the editor of that spec, I don't know when that will actually happen. might be within 6 months. 3 months unlikely
15:27:52 <dmitriz> ... I wouldn't be surprised if it went on for another year. Option C is - we're not gonna register a media type until the WG figures it out
15:28:17 <dmitriz> ... there has been some discussion in the issue; my gut tells me that Option B would result in us being able to register it immediately with no major pushback
15:28:30 <dmitriz> ... at the same time, it's not necessarily ideal, as some people are pointing out
15:28:40 <dmitriz> ... there are likely more technically correct ways to address the issue
15:28:55 <dmitriz> ... another option not there in the beginning, coming from Mozilla / Martin Thompson, was - our spec can say, here's the base media type,
15:29:13 <dmitriz> ... however you can ALSO use these other media types -- you can serve it as application/ld+json, or something else, and here are the rules for doing it that way
15:29:15 <brent> q+
15:29:19 <ivan> q+
15:29:19 <dmitriz> ... that would require a decent bit of discussion
15:30:06 <dmitriz> brent: I'm wondering -- my perspective, chair hat off, it seems like one of the reasons we'd want to move forward with a media type registered now, is because a data format that has a media type registered, there's a perception that it's "a real thing",
15:30:20 <dmitriz> ... like, we've graduated, we're real, we have a media type, I think that's the perception
15:30:28 <dmitriz> ... so from that perspective, it'd make sense to move forward and claim one
15:30:29 <manu> q+ to mention the "it's a real thing" perception ... is a real thing. :)
15:30:58 <dmitriz> ... the pros of option A, and moving forward w that, is that multiple suffixes make sense to us. drawbacks -- registration of multiple suffixes media types will be used for all time as a bad example
15:31:10 <dmitriz> ... and I don't want to be painted with that brush
15:31:22 <dmitriz> ... I recognize the drawbacks of choosing something simple like application/vc
15:31:35 <dmitriz> ... or you can just use ld+json in our description of the media type
15:31:37 <brent> ack brent
15:31:42 <brent> ack ivan
15:31:54 <dlongley> +1 to registering `application/vc`, `application/vp`, and saying that `application/ld+json` is also permitted -- and keeping open the option to add multiple suffixes in the future
15:31:54 <dmitriz> ivan: I am pretty worried about all of these things; we've been fighting w this for I don't know how many years now
15:32:17 <dmitriz> ... if we're getting to a registration of something that won't be really accepted by IETF, it leads to a lot of discussion, and at the end of the day, it will create problems for the final TR
15:32:39 <dmitriz> ... in the meantime, it's a lot of discussion; I don't remember how many media types we're talking about, and to add jose/cose to it, we're talking about 6 or 7 media types we have to fight for
15:33:07 <dmitriz> ... and I don't feel like doing that. I repeat what I said last week, I still believe an option is, we either don't do anything right now, or just try and register /vc and /vp
15:33:13 <TallTed> q+
15:33:24 <manu> q- later
15:33:30 <dmitriz> ... additionally, we have this pending charter proposal that we have to talk about at some point
15:34:00 <dmitriz> ... and we should add to the charter proposal -- if IETF takes a final stand, and if it allows us to register ld+json or whatever, we can do it in the next incarnation of the WG, and we don't do it now. I think that's the best option
15:34:03 <brent> ack TallTed
15:34:36 <dmitriz> TallTed: my sense of the IETF position at this moment is - there are a couple of very loud voices who have been around for a while, and type a lot, who are very much against what is being called "multiple suffixes", which I think of as sub-subtypes
15:34:55 <dmitriz> ... it is not my sense that this is an IETF position as a whole, or even just of the decision makers
15:35:14 <dmitriz> ... I don't think we should be scared off from doing the right thing, because we think it won't get through
15:35:31 <dmitriz> ... most of us have a sense of how media types have worked historically, and that is not what is currently being trumpeted by the loud voices
15:35:50 <dmitriz> ... the loud voices are saying, everything we've been doing historically is wrong, and we won't do it anymore. that should be objected to, by as many voices as poissible
15:36:10 <dmitriz> ... there are some errors in what has been registered in the past, and there are some errors in what's being requested in the jose/cose thread
15:36:51 <dmitriz> ... there's other options, and I believe those won't get objections from IETF
15:36:51 <dmitriz> ... the timing sucks, no way around that
15:36:59 <dmitriz> ... but I don't want to do anything that precludes us doing the right thing as time moves on
15:37:06 <manu> q+ to note "doing the right thing" as time moves on.
15:37:07 <dmitriz> ... IETF is giant in scope
15:37:20 <dmitriz> ... but it's also a giant cruise ship, difficult to turn quickly. more voices help in that
15:37:59 <dmitriz> ... partly because more voices can put it in different words, and can be heard differently. if you haven't participated in the thread, and understand what we're trying to do, weigh in
15:38:08 <brent> ack manu
15:38:08 <Zakim> manu, you wanted to mention the "it's a real thing" perception ... is a real thing. :) and to note "doing the right thing" as time moves on.
15:38:23 <dmitriz> manu: I agree with a lot of what Ted said, I do think there is a minority opinion driving the discussion at IETF
15:38:51 <dmitriz> ... I am still hopeful we can come to something that won't undo 20-30 years of media registrations. But that's not our fight. in this group, we just need a media type
15:38:54 <dmitriz> ... I'm a strong +1 to what Brent said, that when you have a media type, something is real
15:39:07 <dmitriz> ... for better or for worse. so let's pick a media type that does not limit our future options
15:39:33 <dmitriz> ... for example, one thing we can do (I'm willing to write a PR), is to say, we're registering application/vc and /vp, today
15:39:42 <dmitriz> ... and for the jose/cose specs, we can add a +jwt to it
15:39:57 <dmitriz> ... in theory, that matches everythign done previously, won't get pushback
15:40:13 <dmitriz> ... and in our specs, we can say, alternatively, you may serve things as application/ld+json,
15:40:21 <dmitriz> ... we'll make a very strong case for application/vc
15:40:30 <dmitriz> ... but if you want general semantics, you can just do ld+json
15:40:53 <dmitriz> ... in the future, if the multiple suffix stuff gets to consensus, in a future spec, we can say, you may serve it as application/vc+ld+json
15:41:02 <ivan> q+
15:41:15 <dmitriz> ... the only downside to that approach is - all of a sudden, we have potentially 3 media types. but it's not that difficult for software to deal with 3
15:41:26 <dmitriz> ... we do have one issue regarding file extensions.
15:41:39 <dmitriz> ... which you can associate with just one media type, if I remember correctly. but that's a smaller problem to deal with
15:41:48 <brent> ack ivan
15:42:13 <dmitriz> ivan: i have the impression that we are widely agreeing. the only thing I'd ask for this PR, which I agree with, can you also make a PR which adds something into the charter proposal for the future WG
15:42:24 <dmitriz> ... or, rather, the maintenance WG
15:42:30 <dmitriz> manu: happy to do that
15:42:39 <dmitriz> brent: sounds like we have a path forward
15:42:55 <dmitriz> ... we'll see how the discussion pans out with the PR. seems like we're in a place where that PR can be written
15:43:13 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1348
15:43:20 <manu> q+
15:43:26 <dmitriz> brent: 1348, non-normative changes from J Yaskin
15:43:26 <brent> ack manu
15:43:53 <dmitriz> manu: i would love help on this, not sure how to distribute the task, other than people picking sections from the big long list
15:44:06 <dmitriz> ... if people want to take sections from the bottom of that list, that'd be awesome
15:44:21 <dmitriz> ... there's roughly 35 changes that need to be made. not too bad, most of those should be editorial.
15:44:28 <DavidC> q+
15:44:29 <dmitriz> ... so, volunteers welcome
15:44:38 <brent> ack DavidC
15:44:53 <dmitriz> DavidC: the bit I've done is nearly agreed on now. the one thing I don't know how to do is to add a reference to an external document
15:44:54 <manu> q+
15:45:03 <brent> ack manu
15:45:19 <dmitriz> manu: at the top of the document, there's a section called Biblio or something like, that has a bunch of square brackets, that's where you add it
15:45:42 <dmitriz> ... if you're referencing an existing RFC, those should be there already, you just need double brackets around RFC<num>
15:46:03 <dlongley> https://github.com/w3c/vc-data-model/blob/main/common.js#L7
15:46:09 <dlongley> DavidC ^
15:46:11 <dmitriz> DavidC: I couldn't find that section
15:46:51 <dmitriz> manu: ok, yeah, what dlongley said
15:46:56 <dlongley> note that this: https://github.com/w3c/vc-data-model/blob/main/index.html#L48 links to that common.js file.
15:47:02 <brent> https://github.com/w3c/vc-data-model/pull/1469
15:47:10 <dmitriz> brent: just to note for the minutes, PR 1469 is DavidC's PR that he's addressing
15:47:17 <brent> https://github.com/w3c/vc-data-model/pull/1464
15:47:19 <dmitriz> ... and manu's PR for the rest is 1464
15:47:29 <dmitriz> ... and as has been mentioned, please feel free to claim a section and work on it
15:47:46 <dmitriz> ... moving on to 1472
15:47:49 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1472
15:48:08 <dmitriz> brent: Ted, it's your issue, do you want to walk us through
15:48:21 <dmitriz> TallTed: possibly just deleting that paragraph
15:48:21 <manu> q+
15:48:32 <dmitriz> ... the problem with "trust" at all is, it's outside the bounds of what we can really do
15:48:51 <dmitriz> ... we're cryptographically assuring that contents are the statements of the issuer, that's it
15:48:54 <dmitriz> ... there's nothing about the truth of them, or anything else
15:49:05 <dmitriz> ... just "this issuer said these things at this time"
15:49:10 <ivan> +1 to TallTed
15:49:15 <dmitriz> ... so talking about truth in the context of revocation doesnt make sense
15:49:15 <dlongley> +1 to TallTed
15:49:20 <brent> ack manu
15:49:26 <dmitriz> manu: +1 to that, Ted.
15:49:32 <dlongley> +1 to just remove the paragraph
15:49:35 <dmitriz> ... I think we do have, in some other part of the spec, exactly what you said
15:49:45 <dmitriz> +1 to remove paragraph
15:50:05 <dmitriz> manu: I think it is generally presumed that you're going to listen to the issuer, but of course there are cases where you might not trust em
15:50:12 <JoeAndrieu> q+ to say there is trust that the issuer is in control of the mechanisms
15:50:25 <dmitriz> ... or just a subset of what they're saying. I reacted strongly to "lets just delete it", but now that I'm reading it, if we have that language elsewhere,
15:50:47 <brent> ack JoeAndrieu
15:50:47 <Zakim> JoeAndrieu, you wanted to say there is trust that the issuer is in control of the mechanisms
15:50:51 <dmitriz> ... do you want to take this issue?
15:50:51 <dmitriz> TallTed: yeah, I'll take it,
15:51:12 <dmitriz> JoeAndrieu: this is a really good catch, Ted. I agree we don't have to depend on the trust. might be useful to say something about trusting that the issuer is using the mechanism correctly
15:51:29 <dmitriz> brent: sounds like we have a path forward, look forward to the PR
15:51:33 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1457
15:51:39 <manu> q+
15:51:48 <dmitriz> brent: we discussed this one a few weeks ago
15:51:53 <brent> ack manu
15:52:09 <dmitriz> manu: David Lehn is working on it, just has a long backlog, he'll get to it
15:52:31 <dmitriz> ... suggestion was - we update ReSpec VC, not only show data integrity securing mechanisms, but some of the VC-JOSE/COSE mechanisms
15:52:50 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1465
15:52:51 <dmitriz> ... in the respec vc library, would allow you to choose on an example-by-example basis which securing mechanisms you'd want to show
15:52:51 <dmitriz> brent: thanks
15:53:10 <dmitriz> brent: I raised this. I was reading through spec, and noted that two different sections both talk about the credential lifecycle
15:53:14 <dmitriz> ... so the split is not great
15:53:24 <dmitriz> ... let's merge them into one section. take 3.4, put it inside of 5.1
15:53:40 <dmitriz> ... also remove the concrete example, say - "we  have use cases, they're over there", like we've done in the path
15:53:42 <manu> q+
15:53:46 <dmitriz> ... would love to hear feedback.
15:53:53 <brent> ack manu
15:54:09 <dmitriz> manu: strong +1 to that. I'm wondering if we should go a step further, and merge that section into the Use Cases document
15:55:09 <dmitriz> brent: proposal on the table is, in as minimal fashion as possible, merge those two sections, and reference the Use Cases doc, like Joe said
15:55:10 <manu> +1
15:55:19 <dmitriz> JoeAndrieu: sounds right
15:55:26 <dmitriz> brent: ok, I'll do that
15:55:34 <dmitriz> ... Joe, does the Use Cases doc have this lifecycle stuff?
15:56:06 <dmitriz> JoeAndrieu: I think it's there, but we'll check
15:56:11 <dmitriz> brent: ok, we're at time, thanks everyone
15:56:34 <dmitriz> ... before we close, I do want to note issue 1467, I made a chair statement on that, I'm not seeing any new info that justifies the conversation taking further time
15:56:51 <dmitriz> ... that said, if in the comments of the issue and the resulting PR, if people can come to consensus on the way forward, I won't step in the way
15:56:56 <dmitriz> ... I'm just not seeing consensus form.
15:57:23 <ivan> rrsagent, draft minutes
15:57:25 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/10-vcwg-minutes.html ivan
15:58:25 <ivan> rrsagent, bye
15:58:25 <RRSAgent> I see no action items