14:57:29 <RRSAgent> RRSAgent has joined #did
14:57:33 <RRSAgent> logging to https://www.w3.org/2025/07/03-did-irc
14:57:56 <ottomorac> rrsagent, draft minutes
14:57:58 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/03-did-minutes.html ottomorac
14:58:04 <ottomorac> rrsagent, make logs public
14:58:43 <ottomorac> Meeting: Decentralized Identifier Working Group
14:58:51 <ottomorac> Chair: ottomorac
14:59:06 <ottomorac> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Jul/0000.html
15:00:22 <denkeni> denkeni has joined #did
15:05:27 <manu> present+
15:05:33 <ottomorac> present+
15:06:10 <denkeni> present+
15:06:42 <manu> q+
15:06:53 <pchampin> present+
15:07:04 <ottomorac> ack manu
15:08:27 <bigbluehat> bigbluehat has joined #did
15:08:36 <bigbluehat> scribe+
15:08:44 <ottomorac> Topic: DID Methods WG Charter - Special Topic Call on 9-July
15:09:07 <bigbluehat> ottomorac: thanks to pchampin we have this setup
15:09:13 <bigbluehat> ... I've announced it to several groups
15:09:41 <manu> q+
15:09:45 <bigbluehat> ... and I clarified that one could be a member of Trust Over IP, DIF, or W3C
15:09:49 <JennieM> JennieM has joined #did
15:09:52 <bigbluehat> ... and maybe others? we can discuss
15:09:56 <ottomorac> ack manu
15:09:57 <JennieM> present+
15:10:09 <bigbluehat> manu: I'm fine with whatever the chairs from the groups decide
15:10:16 <bigbluehat> ... this is a general chartering discussion
15:10:31 <bigbluehat> ... so one thing I don't want to see is someone saying they were left out
15:10:40 <bigbluehat> ... I don't think we're at risk of anyone injecting new IP into the discussion
15:11:10 <bigbluehat> ... It is a discussion happening in public on GitHub around a W3C WG recharter
15:11:25 <bigbluehat> ... so the more folks get involved, the better, and I'd prefer we don't limit it
15:11:40 <bigbluehat> ... we did send the invite to the CCG mailing list, but we also said it was limited
15:11:48 <bigbluehat> ... which is not what I wanted to see
15:11:52 <pchampin> q+
15:12:00 <bigbluehat> ottomorac: agreed. Does this need to be a resolution sort of thing?
15:12:04 <ivan> present+
15:12:22 <bigbluehat> pchampin: no, I don't think we need a resolution
15:12:28 <bigbluehat> ... it's not depending on anything from this group
15:12:31 <ottomorac> ack pchampin
15:12:40 <bigbluehat> ... the team are the ones who will submit the charter to the members
15:13:07 <manu> +1 to what PA said.
15:14:30 <bigbluehat> ottomorac: manu you wanted to say more about chareting?
15:14:50 <bigbluehat> manu: yes, mainly I wanted to explore this with the team around bandwidth, membership expectations, etc.
15:15:00 <bigbluehat> ... especially around related groups in the process of rechartering also
15:15:14 <bigbluehat> ... I don't want it to wander into the weeds of too many other things
15:15:30 <bigbluehat> ... but there are some specs that I don't want to see fall through the cracks or end up on incompatible timelines
15:16:03 <ottomorac> q?
15:16:09 <bigbluehat> ... My preference would be to know that we and the team have a clear understanding of where we want to end up
15:16:23 <bigbluehat> ... that's it, ottomorac, and what I'd love to focus on if possible
15:16:26 <manu> q+
15:16:28 <pchampin> q+
15:16:30 <bigbluehat> ottomorac: yeah, let's spend some time on this
15:16:32 <ottomorac> ack manu
15:16:46 <bigbluehat> manu: k. let me propose something then
15:17:12 <bigbluehat> ... there are limitations as always
15:17:30 <bigbluehat> ... so we are going to have to make some practical decisions which of course won't please everyone
15:17:44 <bigbluehat> ... consequently, I'll start with what I see as an ideal state
15:17:48 <bigbluehat> ... and we can discuss from there
15:17:59 <bigbluehat> ... there was one option to do a WG per DID Method
15:18:12 <bigbluehat> ... however, I don't think any of us (especially not the staff) have that kind of capacity
15:18:29 <bigbluehat> ... and instead we may want to explore groups of methods into WGs over time
15:18:48 <bigbluehat> ivan: if we have one WG for several methods, we would need to define task forces for each method
15:19:25 <bigbluehat> ... administratively speaking, one WG with task forces vs. several WGs doesn't make that much difference practically
15:19:43 <bigbluehat> ... for the staff contact, the publishing, admin, etc. are all very similar
15:20:01 <bigbluehat> ... whether it's one place or three places doesn't make that much difference
15:20:10 <bigbluehat> ... imo... pchampin may disagree
15:20:20 <bigbluehat> ... the problem might be the staff context
15:20:31 <bigbluehat> ... but finding the right chair persons to do the chair job properly
15:20:57 <bigbluehat> ... we'd also need the right number of editors and experts across all the task forces
15:21:19 <bigbluehat> s/might be the staff context/might NOT be the staff contact
15:21:33 <manu> q+ to suggest splitting into task forces only if necessary.
15:21:44 <ottomorac> ack pchampin
15:21:54 <bigbluehat> ... so it's more of a concern around general resource availability not staff bandwidth alone
15:22:00 <bigbluehat> pchampin: +1 to what ivan said
15:22:24 <bigbluehat> ... I tried to explain this previously, but I'm not sure I've convinced $him yet
15:22:53 <bigbluehat> ... if it's a resource problem, is it better to have several in sequence?
15:23:07 <bigbluehat> ... I'm not sure this would be enough for Joe
15:23:11 <bigbluehat> s/$him/Joe
15:23:14 <ivan> q+
15:23:28 <ottomorac> ack manu
15:23:28 <Zakim> manu, you wanted to suggest splitting into task forces only if necessary.
15:23:29 <bigbluehat> ... there was some concern around conflicts between the needs of the groups
15:23:33 <bigbluehat> ... but who knows
15:23:42 <ivan> q-
15:23:50 <bigbluehat> manu: I think we'll also discuss some of this next week more in depth
15:24:01 <bigbluehat> ... my main concern is divided attention
15:24:26 <bigbluehat> ... we really need the same level of review across all the things
15:24:41 <bigbluehat> ... and if we spread the folks so thin across the groups, I fear that review would not happen
15:24:42 <ottomorac> +1 to splitting attention would be difficult
15:24:54 <bigbluehat> ... so, ivan, I don't think we should immediately split into task forces
15:25:01 <ottomorac> q?
15:25:07 <bigbluehat> ... but instead make sure all the groups spend time together initially
15:25:31 <bigbluehat> ... we don't want the WGs becoming rubber stamping organizations of the work of 3+ people in task forces
15:25:42 <bigbluehat> ... anyhow. I would like to move onto some other proposals
15:25:48 <pchampin> q+
15:25:51 <bigbluehat> ... One thing is moving the CID spec in
15:26:03 <bigbluehat> ... because we currently can't edit that because it's not in our group
15:26:08 <ivan> q+
15:26:13 <bigbluehat> ... and if we need these changes, perhaps that moves over
15:26:35 <bigbluehat> ... and maybe there's also a way to synchronize our rechartering timing
15:26:48 <bigbluehat> ... so we can group them for easier review by the TAG and Members, etc.
15:26:53 <ottomorac> ack pchampin
15:27:32 <bigbluehat> pchampin: the reason why the CID spec was created
15:27:47 <bigbluehat> ... was, as I understand it, that people wanted some features of DID...but didn't want DIDs
15:28:02 <ottomorac> ack ivan
15:28:04 <bigbluehat> ... if we move CID into DID WG, should we reconsider the name of the group?
15:28:20 <bigbluehat> ivan: I'm not sure that DID was the main reason that CID happened
15:28:39 <bigbluehat> ... there were a number of concepts that were used and usable
15:28:43 <manu> q+ to respond to PA on CID and migration of spec to DID WG.
15:28:49 <bigbluehat> ... that were useful in the VC WG
15:29:13 <bigbluehat> ... essentially, it was the overlap between envelop security and inline security mechanisms
15:29:45 <bigbluehat> ... the CID spec was a peace making endeavor to reduce conflicts between those two groups
15:29:59 <ottomorac> https://xkcd.com/927/
15:30:18 <bigbluehat> ... whatever we do, some things will be in parallel
15:30:35 <bigbluehat> ... review periods, etc. will (as ever) be very complicated
15:30:44 <bigbluehat> ... and we'll be sending them reviews one after the other
15:31:02 <bigbluehat> ... sending them several vs. sending them one will make a huge difference
15:31:23 <bigbluehat> ... so sending them one charter may be a better play
15:31:31 <bigbluehat> ... this also relates to the CID situation
15:31:39 <bigbluehat> ... even if it's not ideal...
15:32:03 <bigbluehat> ... carpet bombing the AC with a barrage of rechartering will not likely give us what we need
15:32:19 <bigbluehat> ... if we moved CID to DID WG, we'd also have to recharter the VC WG
15:32:30 <manu> q+ to speak to VC rechartering.
15:32:36 <ottomorac> ack manu
15:32:36 <Zakim> manu, you wanted to respond to PA on CID and migration of spec to DID WG. and to speak to VC rechartering.
15:32:37 <bigbluehat> ... since many of the people overlap between the groups, I think we'll have what we need to make those changes
15:32:47 <bigbluehat> manu: yes. good points, ivan
15:32:57 <bigbluehat> ... there is definitely a risk to wearing out the AC
15:33:21 <bigbluehat> ... and I also agree that moving the CID spec is pretty far down the list of our general concerns
15:34:03 <bigbluehat> ... ignoring those realities, though, ideally, there would be a group (DID WG or that under a new name) would be the best place for the CID spec to live
15:34:20 <bigbluehat> ... with the VC WG, we are looking at around 6 specs to go into its recharter
15:34:52 <bigbluehat> ... ivan pchampin not sure if you've seen this list yet, but here it is
15:34:54 <TallTed> TallTed has joined #did
15:35:21 <bigbluehat> ... VC Barcodes, VC Rendering Methods, Confidence Methods, and several others
15:35:49 <bigbluehat> ... since the VC WG is going to recharter, it seems like a good time to question the placement of the CID spec within the VC WG
15:36:27 <ottomorac> https://github.com/w3c-ccg/community/issues/250
15:36:28 <bigbluehat> ... because the DID spec depends on the CID spec, the DID WG will be stalled for 3 years while the rechartered VC WG runs its course
15:36:33 <bigbluehat> ... and that timing would be terrible
15:36:59 <bigbluehat> ... there are also questions around the JSON-LD WG...which might be better named the Linked Data Formats WG
15:37:12 <bigbluehat> ... there was a call yesterday about that--the minutes are worth a look ivan and pchampin
15:37:26 <ivan> q+
15:37:29 <bigbluehat> ... some of the VC WG specs depend on work likely to go into the JSON-LD WG recharter
15:37:57 <bigbluehat> ... my concern is that we've got stuff that's moving into production within the community that will soon be on much slower timelines in one or more WGs at the W3C
15:38:00 <TallTed> present+
15:38:09 <ottomorac> ack ivan
15:38:28 <bigbluehat> ... and as vendors, we're drifting into a bad state where we're pushing things into production that are not yet fully standardized per W3C process
15:38:39 <bigbluehat> ivan: if my count is right, it looks like there are about 10 documents
15:39:05 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/03-did-minutes.html TallTed
15:39:11 <bigbluehat> ... we previously had 7 standardized and 2 stalled/failed (currently) in the VC WG
15:39:13 <bigbluehat> ... and that was a huge work
15:39:20 <bigbluehat> ... and you are now proposing 10 documents
15:39:25 <bigbluehat> ... which is more than in the last VC WG
15:39:34 <bigbluehat> ... and we don't yet have a second co-chair
15:39:44 <bigbluehat> ... so I feel that we have to come up with a priority list
15:39:53 <bigbluehat> ... and see which are truly the most important ones
15:40:02 <bigbluehat> ... and which ones will have to wait 1-2 years
15:40:10 <bigbluehat> ... I have no idea where I will be in that time frame
15:40:17 <bigbluehat> ... and this sounds like an enormously tall order
15:40:33 <bigbluehat> ... and when I look at even just the VC WG list of specs, it's frightening
15:40:49 <bigbluehat> ... we know that the specs coming from the CCG have historically required a great deal of work
15:41:08 <manu> q+ to agree w/ priority list, but also (incubation has us further down the road).
15:41:10 <ottomorac> q?
15:41:12 <ottomorac> ack manu
15:41:12 <Zakim> manu, you wanted to agree w/ priority list, but also (incubation has us further down the road).
15:41:17 <bigbluehat> ... even though they come in as drafts from the CCG, it took most of our 3 years to rework them into publishable specs
15:41:29 <bigbluehat> manu: I agree. It is a long list of specifications
15:41:36 <bigbluehat> ... and it will certainly be a lot of work
15:41:48 <bigbluehat> ... maybe what we need to do is that we have the ability to take some of this work on
15:42:00 <bigbluehat> ... because if it doesn't happen at the W3C, it will happen somewhere
15:42:10 <bigbluehat> ... pchampin recently saw how big this space is becoming
15:42:23 <bigbluehat> ... and we need help moving all this work forward
15:42:29 <bigbluehat> ... so, I completely agree ivan
15:42:34 <bigbluehat> ... it's a scary amount of work
15:42:52 <bigbluehat> ... but at the same time, it would not be acceptable for this work to delay for 2 or more years
15:43:07 <bigbluehat> ... obviously, the spec priorities are pushed forward by whomever shows up
15:43:19 <ivan> q+
15:43:26 <bigbluehat> ... so, naturally, the ones that people depend on will get attention/activity
15:43:42 <bigbluehat> ... and I think any WG knows how to naturally prioritize their work
15:43:57 <bigbluehat> ... but I think relatedly that the total list should include the things the group also needs to get to
15:44:17 <bigbluehat> ... and it would send the wrong message for the W3C to walk away from significant portions of the specification list
15:44:38 <bigbluehat> ... so, thinks like Render Method for example may not be that big of a deal--relative to some others
15:44:43 <bigbluehat> ... but we never really know
15:44:58 <bigbluehat> ... but what I think would be problematic would be cutting things prematurely
15:45:07 <bigbluehat> ... without the group members having some say
15:45:24 <bigbluehat> ... I'd much rather start with a list that the group is interested in, and have us not get through the entire list
15:45:33 <ottomorac> ack ivan
15:45:35 <bigbluehat> ... than to be unable to work on things because we cut things out too early
15:46:13 <bigbluehat> ivan: I hear what you say, and I don't think I can personally set the priorities
15:46:16 <manu> q+ are "specs really W3C things"
15:46:20 <manu> q+ to note are "specs really W3C things"
15:46:22 <bigbluehat> ... so...let me propose something "wild"
15:46:32 <bigbluehat> ... do these all truly need to be W3C specs?
15:46:41 <bigbluehat> ... I know we've been burned at the IETF before...sadly
15:46:49 <bigbluehat> ... but perhaps some of these things could go there?
15:46:52 <bigbluehat> ... or elsewhere?
15:47:06 <bigbluehat> ... it doesn't need to be a drama because the W3C may have a resourcing problem
15:47:07 <ottomorac> ack manu
15:47:07 <Zakim> manu, you wanted to note are "specs really W3C things"
15:47:37 <bigbluehat> manu: it's a fair question
15:48:04 <bigbluehat> ... all of these seem to be W3C specs to me
15:48:22 <bigbluehat> ... VC Barcodes which builds CBOR-LD because it builds on JSON-LD
15:48:32 <bigbluehat> ... many of the rest of these are extensions to VC Data Model v2
15:48:38 <bigbluehat> ... or they're cryptosuites
15:48:48 <bigbluehat> ... the VC API is focused on moving VCs
15:49:05 <bigbluehat> ... Verifiable Presentation Requests are obviously for presenting VCs
15:49:31 <bigbluehat> ... VC Over Wireless are related to Web NFC and while that's not an official W3C thing, it's clearly related to VCs
15:49:43 <bigbluehat> ... the only one that I think could be debated would be the ZCAP specification
15:49:48 <dmitriz> that was my thought as well, re zCaps and possibly IETF
15:49:50 <bigbluehat> ... that could potentially go to the IETF
15:50:20 <bigbluehat> ivan: you successfully reduced the list by one, so that's progress
15:50:33 <bigbluehat> ... for the VC related ones, those seem fine
15:50:40 <bigbluehat> ... others are built on Data Integrity
15:50:50 <manu> q+ on post-quantum.
15:51:04 <ottomorac> ack manu
15:51:04 <Zakim> manu, you wanted to comment on post-quantum.
15:51:06 <bigbluehat> ... do we risk running into issues with the JOSE/COSE stuff and getting lost in long discussions around all that?
15:51:14 <bigbluehat> manu: I think the danger is less this time around
15:51:22 <bigbluehat> ... because we already have the VC JOSE/COSE spec
15:51:41 <bigbluehat> ... and if we focus on post-quantum, then that will be the focus for any of these specs
15:51:54 <bigbluehat> ivan: so double the work?
15:52:14 <bigbluehat> manu: IETF is already doing JOSE/COSE stuff, so it may just be leaning on that work by changing to a new identifier
15:52:30 <bigbluehat> ... so hopefully in most cases it's like changing out which cryptography is being used
15:52:52 <bigbluehat> ... if we had to prioritize the work, I'm not sure post-quantum would go first
15:53:07 <bigbluehat> ... there's a deadline, but the WGs would happen within that
15:53:31 <bigbluehat> ... and we could prioritize if/when the computers finally get to a high enough level of risk
15:53:40 <bigbluehat> ivan: they have been "close" for the last 20 years
15:53:52 <pchampin> but they may progress in a quantum jump!
15:54:00 <ottomorac> q?
15:54:00 <bigbluehat> manu: I think we can parallelize  much of this work
15:54:09 <bigbluehat> ... but we should pin down the priorities and whom will work on what
15:54:13 <manu> q+
15:54:25 <pchampin> q+
15:54:29 <ottomorac> ack manu
15:54:32 <bigbluehat> ivan: and you want all this before TPAC?
15:54:41 <bigbluehat> manu: that would be wonderful!
15:54:59 <bigbluehat> ... there is a discussion about where the data integrity stuff might fit better
15:55:16 <bigbluehat> ... there are groups focused on things like Zero Knowledge SPARQL for example
15:55:23 <bigbluehat> ... and that will likely have positive outcomes
15:55:38 <bigbluehat> ... and it may be that the W3C could restructure the work around something like Linked Data Protection
15:55:54 <bigbluehat> ... and the Data Integrity stuff could move there to be closer to that kind of work
15:56:08 <bigbluehat> ivan: all this because the RDF WGs have nothing to do <laughs>
15:56:25 <bigbluehat> ... if I say that the VC WGs hands are full, that's nothing as compared to the RDF groups
15:56:33 <bigbluehat> ... they are currently in the fighting phase...
15:56:40 <bigbluehat> ... you know that I worked on DI adapted to RDF
15:56:45 <bigbluehat> ... so I full understand
15:57:11 <bigbluehat> ... but I have no hope that this work will materialize in the next couple years
15:57:30 <bigbluehat> manu: mainly, W3M really needs to focus on VCs, DCs, and cryptography around data
15:57:31 <ottomorac> ack pchampin
15:57:38 <bigbluehat> ... and there needs to be a broader strategy defined there
15:57:43 <bigbluehat> pchampin: point taken
15:57:51 <bigbluehat> ... I have had some discussions around this
15:58:10 <bigbluehat> ... and when ivan was talking about rechartering the DID WG and that effecting the VC WG
15:58:23 <bigbluehat> ... I realize it's the other way around where the VC WG is happening sooner
15:58:41 <ottomorac> Topic: next time - Special Topic Call on 9-July for DID Method WG Charter
15:58:45 <bigbluehat> ... and though DID WG is on a slower path, perhaps we can make the move of CID to the DID WG happen all the same
15:58:50 <manu> yes, very productive, thank you Ivan and PA! :)
15:58:57 <bigbluehat> ottomorac: thank you for the discussion!
15:59:05 <bigbluehat> ... we'll have a special topic call next week
15:59:16 <bigbluehat> ivan: before getting to that, I have one more question
15:59:20 <manu> q+
15:59:27 <bigbluehat> ... how much work does it take to define some of these methods?
15:59:40 <bigbluehat> ... how narrowly can these groups be focused?
15:59:55 <bigbluehat> ... we had good success with RDF canonization
16:00:09 <bigbluehat> ... so, if we had a WG for did:web or whatever it is called today
16:00:14 <ottomorac> ack manu
16:00:18 <bigbluehat> ... one would think it would be a short lifespan, correct?
16:00:25 <bigbluehat> manu: it depends on the DID method
16:00:37 <bigbluehat> ... for something like did:key we could be done very very quickly
16:00:51 <bigbluehat> ... but with did:web and/or did:webvh it will take much longer
16:01:05 <bigbluehat> ... as there's a good bit to discuss around several related activities
16:01:10 <bigbluehat> ... so... it depends
16:01:22 <bigbluehat> ottomorac: but there are also some similarities, right manu ?
16:01:23 <bigbluehat> manu: yes
16:01:28 <bigbluehat> ottomorac: thanks so much, all
16:01:55 <bigbluehat> ... see you next Wednesday for the special topic call
16:01:55 <pchampin> RRSAgent, make minutes
16:01:57 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/03-did-minutes.html pchampin
17:18:55 <ottomorac> m2gbot, link issues with transcript
17:18:55 <m2gbot> nothing to do (no issue in the (sub)topics)
17:19:04 <ottomorac> zakim, end the meeting
17:19:04 <Zakim> As of this point the attendees have been manu, ottomorac, denkeni, pchampin, JennieM, ivan, TallTed
17:19:06 <Zakim> RRSAgent, please draft minutes
17:19:08 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/03-did-minutes.html Zakim
17:19:14 <Zakim> I am happy to have been of service, ottomorac; please remember to excuse RRSAgent.  Goodbye
17:19:14 <Zakim> Zakim has left #did
17:19:25 <ottomorac> RRSAgent, please excuse us
17:19:25 <RRSAgent> I see no action items