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