16:41:23 RRSAgent has joined #did-topic 16:41:23 logging to https://www.w3.org/2020/12/17-did-topic-irc 16:41:25 RRSAgent, make logs Public 16:41:26 please title this meeting ("meeting: ..."), ivan 16:41:40 Meeting: DID WG Topic Call on Registry Handling 16:41:41 Chair: brent 16:41:41 Date: 2020-12-17 16:41:41 Agenda: https://www.w3.org/mid/CAHR74YXgY+bv-P8P_bEVv3Wsi8=eU0aPRVbH1YE7CRPcHV8OwA@mail.gmail.com 16:49:11 justin_r has joined #did-topic 16:57:03 present+ 17:00:03 brent has joined #did-topic 17:00:23 present+ 17:00:38 present+ 17:00:43 scribe+ 17:00:44 present+ 17:01:00 jonathan_holt has joined #did-topic 17:01:38 present+ jonathan_holt 17:01:49 joining soon 17:02:10 present+ 17:04:41 manu: I have a series of proposals that i don't think the CG would object to.... but some people missing 17:04:59 Orie has joined #did-topic 17:05:01 slides, issue 58,did-spec-registries#149 17:05:11 PROPOSAL: this Working Group maintains the registry until the end of its charter. The Working Group plans to request the management of W3C to submit a charter for a maintenance DID Working Group to the W3C Advisory Committee as a successor to this Working Group. Per the planned charter of that Working Group, that group would officially manage the registry, and would do that in cooperation with the CCG. 17:05:17 JoeAndrieu has joined #did-topic 17:05:18 drummond has joined #did-topic 17:05:26 present+ 17:05:32 present+ 17:05:42 present+ 17:06:11 brent: we have a large enough group to get started 17:06:27 ... manu and ivan have proposals to put before the group 17:06:39 q+ 17:06:40 q+ 17:06:51 ack ivan 17:07:00 ivan: let me try to summarise some things that were discussed 17:07:07 ... there were two issues that were used for the same issue 17:07:16 ... (58 and 149) 17:07:22 ... the Registries is published as w3c working group note 17:07:32 ... the first thing that's very formal is that only a WG has the right to reissue a note 17:07:45 ... if we do any kind of update on the Spec Registries there must be a WG or the Team to republish a note 17:07:50 ... this is the first thing we should not forget. 17:08:04 ... the second is that by now we have thi spractice of having continuation working groups which have to be approved by the AC, so it is always conditional 17:08:13 q+ to note that we may not want a NOTE, more of a living document. 17:08:17 ... but my mental model is that this WG when it finishes will create a continuation WG 17:08:23 ... but probably only maintenance 17:08:27 ... this is something we can decide later 17:08:40 ... that seems to be a natural place which formally speaking maintains the registry and has the right to republish it and do things 17:08:43 ... this is the formal part 17:09:00 ... in practice, the same way as we have in other groups, there is a CG somewhere in the background which is active because the WG will not have regular meetings 17:09:05 ... and that's how I came up with the proposal 17:09:53 ... for me this is a clear path, and no disagreement with mike who is adament on saying the w3c must continue to have control over the registry which I agree with 17:10:00 ... and there are practicalities to work out, and what the CG process is 17:10:07 ... but that's way down the line, not something we have to worry about right now 17:10:08 q? 17:10:18 manu: agree with ivan 17:10:19 ack manu 17:10:19 manu, you wanted to note that we may not want a NOTE, more of a living document. 17:10:25 ... I did a minor reword of the original proposal to align it with the others 17:10:41 ... I'd like to see if we can get ivan's proposal passed, that shortcuts a lot of the other discussions we could have 17:10:46 ... there are other things that have come up wrt the registries 17:10:54 ... one has to do with a copyright trademark/legal concerns 17:10:59 ... the other has to do with security and privacy concerns 17:11:04 ... and how much power the registry editors have to say no 17:11:14 ... we've traditionally had the position that we can't block anything from getting in 17:11:33 ... and some of our members rightly pointed out that no that's really dangerous to not be able to stop things that are racist, trademark violations, a whole class of things we would not want 17:11:38 ... being able to say no i simportant 17:11:48 ... if the editors can say no, people have said they want a process that allows them to override the editors, what is the escalation process 17:12:00 ... so the proposals are meant to address all of those questions when we put them forward 17:12:04 ivan: we should try to separate those things 17:12:15 ... the propoasl I had was on the ownership of the registry 17:12:18 ... and the way it is managed later 17:12:24 ... that is something that can be agreed upon 17:12:27 ... and then we can get it out of the way 17:12:38 ... the second question you have is regardless of that problem. We have to discuss it, but it's a separate issue 17:12:42 manu: +1 17:12:50 brent: I think we can put those proposals forward 17:13:02 PROPOSAL: The DID Working Group will maintain the DID Spec Registries until the end of its charter. The DID Working Group plans to request the management of W3C to submit a charter for a maintenance DID Working Group to the W3C Advisory Committee as a successor to this Working Group. Per the planned charter of that Working Group, that group would officially manage the registry, and would do that in cooperation with the W3C Credentials 17:13:15 +1 17:13:31 +1 17:13:34 +1 17:13:37 +1 17:13:48 ROPOSAL: The DID Working Group will maintain the DID Spec Registries until the end of its charter. The DID Working Group plans to request the management of W3C to submit a charter for a maintenance DID Working Group to the W3C Advisory Committee as a successor to this Working Group. Per the planned charter of that Working Group, that group would officially manage the registry, and would do that in cooperation with the W3C Credentials Community Group 17:13:53 +1 17:13:54 +1 17:13:56 +1 17:13:57 s/ROPOSAL/PROPOSAL 17:14:03 +1 17:14:10 +1 17:14:10 +1 17:14:15 +1 17:14:31 RESOLVED: The DID Working Group will maintain the DID Spec Registries until the end of its charter. The DID Working Group plans to request the management of W3C to submit a charter for a maintenance DID Working Group to the W3C Advisory Committee as a successor to this Working Group. Per the planned charter of that Working Group, that group would officially manage the registry, and would do that in cooperation with the W3C Credentials Community Group 17:14:50 ivan: we should be formal, this is a long term committment. The reoslution of this call is not formal, so that should be reaffirmed by the WG next week if possible 17:14:52 brent: will add to agenda 17:14:59 ivan: should be administrative, but prefer to have something like that 17:15:05 +1 to have this reaffirmed in the full WG meeting 17:15:35 present+ burn 17:15:53 brent: next tuesday is last calls of the year, normal call and special topic call 17:15:55 agropper has joined #did-topic 17:15:57 q+ 17:16:09 ... and it's an asia time call... which means there is no special topic call... 17:16:11 q+ to put forward next proposal. 17:16:14 ... just one next tuesday 17:16:15 present+ 17:16:20 ack manu 17:16:20 manu, you wanted to put forward next proposal. 17:16:29 manu: the next one seems obvious, but we had confusion about where the discussion should happen 17:16:32 ... this is to try and clarify 17:16:37 ... the group has a preference on where it happens 17:16:43 q+ 17:16:54 ... we'd like it to happen in the DID spec registries issue tracker, followed by the mailing list, and then the credentials CG mailing list 17:16:56 q+ 17:17:01 ack jonathan_holt 17:17:04 ack jonathan_holt 17:17:09 jonathan_holt: my reservation about this is there's not a lot of discussion happening in the DID spec registry issue tracker 17:17:17 ... and it's been slow and painful to get my contributions resolved 17:17:27 ... I'm all for the registry but we need to get to some sort of commonality of the extension process 17:17:32 ... I'm more of a proponant of pulling that into DID Core 17:17:47 ... as orie will also point out it was not getting enough communication and coordination, being ian a separate repo 17:17:53 ack ivan 17:18:24 ivan: i don't disagree with what is said, and it's okay if this is a resolution for this WG, remaining a year or so, but I don't think that this WG should take any resolution which is valid for the continuation WG which has the right to organise its own work 17:18:32 ... I don't see the reason of having this resolution longer term 17:18:38 ... we can agree how it is done now while we are active 17:18:42 ... but why do we want to go beyond that? 17:18:43 q+ 17:18:55 manu: to point out it doesn't say anything about future 17:19:01 ... each of these proposals talks in the present tense 17:19:10 ... I agree with ivan, I don't think the proposal is saying anything about the new group 17:19:15 ack manu 17:19:18 ivan: what's in the proposal is something that is happening already 17:19:47 manu: that is correct but people were objecting to it happening in this way, they were saying it must only happen in the DID WG and the problem there is there's conversation that happens in the CCG as well so it's just highlighting the order of preference, but it's okay if the conversations happen in any of these places 17:19:51 q+ to ask about adding guideline to did core for extensions 17:19:57 ivan: the conversation can happen anywhere as long as the result is submitted to the WG 17:20:11 manu: agreed but there was confusion.. we can not pass it and the person that was objecting to the conversation happening elsewhere can raise an issue 17:20:24 q+ 17:20:25 q+ to propose the did core issue tracker 17:20:30 ... this is us stating this is where we expect the conversations to happen as a group so that anyone objecting to conversations happening in the CG would understand where group consensus is 17:20:33 ack brent 17:20:33 brent, you wanted to ask about adding guideline to did core for extensions 17:20:49 brent: is there an intention, should we add normative guidence about the registries and how to add extensions to them to did core? 17:20:55 ack jonathan_holt 17:21:05 jonathan_holt: and also say what's the governance framework of adding extensions, who are the deciders? 17:21:06 q+ 17:21:11 ack Orie 17:21:11 Orie, you wanted to propose the did core issue tracker 17:21:29 Orie: i agree with both, the comment I have is that the did spec registries issue tracker, if you're saying that's where the conversation should be had it's not a good idea, it doesn't get enough traffic 17:21:53 ... I'd propose the answer to the first is yes we have to comment in did core about maintenace and governance or we're setting the registry up to rewrite chunks of did core in ways we dno't want. DID core has to have some guidnece for maintaining the registry 17:21:54 q+ to say registry governance should go in the registry... not in DID Core -- because we can't change what's in DID Core easily. 17:21:59 ... we should start the conversation in the did core issue tracker 17:22:09 ... if people want to talk in other palces that's fine, but the WG needs to take responsibility and onwership of this registry 17:22:10 +1 to orie 17:22:13 q? 17:22:24 ... and I'd prefer people not to comment on the did spec registries issues, nobody reads those 17:22:26 ack drummond 17:22:36 drummond: I might have misunderstandings 17:22:42 ... let me pose a different path, for feedback 17:22:56 ... if we're talking about ongoing maintenance of the registries and ivan's proposal to have a WG continue that's got that function 17:23:02 ... it feels lik ethat's the primary thing that's going to be going on there 17:23:11 ... so the did spec registries is its own spec 17:23:29 ... when I attended a meeting a year ago in kyoto and the w3c session on registries I think all of us, manu was there, we saw this is the model we can follow 17:23:37 q+ 17:23:37 ... the governance of that registry spec should be in that spec 17:23:40 ... the maintenance should be of that spec 17:23:53 ... we don't have to have any involve did core, that's separate, but that's about extending did core not *maintaining* the registries 17:24:04 ack manu 17:24:04 manu, you wanted to say registry governance should go in the registry... not in DID Core -- because we can't change what's in DID Core easily. 17:24:04 ... putting the governnance in the registries spec, and maintaining the registries spec on an ongoing basis should be the focus 17:24:08 +1 17:24:09 ... if i've got that wrong please correct me 17:24:15 manu: that is what i thought too, I thought we had agreed to do that 17:24:18 ... I'm confused by suggestions otherwise 17:24:24 ... we've discussed it before, I guess people missed that 17:24:30 ... the reason it's not in DID core is DID core is going to be locked in stone 17:24:39 q+ to clarify I am not proposing the registry goes in did core 17:24:48 ... any suggestion we can put the registries in DID core or that that is a good palce for the governance rules to be is deeply misguided, we're going to lock that and it is going to be very hard to update it 17:24:50 ... that is why it is separate 17:24:56 ... Orie, -1 for bringing any of that into did core 17:25:03 q? 17:25:03 ... if you want it to move fast, moving it into did core will guarantee it moves very slowly 17:25:15 ... jonathan asked who gets to say what goes in the registries, it's the editors, that's the first line 17:25:20 totally agree with Manu here - the DID Spec Registries is the place where we maintain the registries 17:25:30 ... and the governance rules of what they ahve to follow should be written in the registry, that's what the process is and where it stands today 17:25:46 ... the scope opened on this conversation I was not expecting that, I thought we had decided to split the two apart because the registries need to move faster and have its own issue tracker 17:25:47 q+ to ask how that works with Registries being non normative 17:25:49 q? 17:25:52 ... and it's own management process that was separate from did core 17:25:57 ack ivan 17:26:03 ivan: I fundamentally agree with manu, but some additional facts 17:26:24 ... first, my understanding of what orie said is not that the registry should be folded into the core, it should stay as a separate document 17:26:48 ... reflecting to what drummond said, before this meeting I tried to talk to ralph to see where we are with the registry process development, hopefully it wil be part of process 2021, roughly when we end 17:27:06 ... and the approach which seems to develop is that to have a registry there has to be a clearly defined way of management or processing the registry 17:27:21 ... something which is now in section 3 which says how the registry is governed 17:27:34 ... in the new form of registry what should probably happen is that this governance is the only thing that the AC would review 17:27:42 ... and once it is accepted then it is cast in concrete 17:27:56 ... the rest of the registries, the effective terms you put there, would .. like today, you can put it there as long as the governance is followed 17:28:17 ... I have no idea whether that would require at that point to separate the governance into a separate document from the registry itself if the registry is like we hav enow, or if it can stay in the same document, that i don't know 17:28:35 ... my proposal is to leave everything in terms of docs as it is today because that's probably the best way of being future proof if the Process ends up providing a formal registry mechanism 17:28:48 ... the only thing from what orie said which is slightly separate is which repository we would use for issue discussion 17:28:56 ... whether we want to have registry relevent issues discussed in the core repo or not 17:29:02 q+ to ask if registry governance needs to be normative 17:29:02 ... I don' thav ea strong opinion on that 17:29:02 manu: I don't fundamentally disagree that the did core needs to be 'locked down', I was agreeing that issue tracking need to happen with as much contributors as possible. 17:29:07 ack Orie 17:29:07 Orie, you wanted to clarify I am not proposing the registry goes in did core 17:29:09 Orie: that's what I was about to say 17:29:17 ... I'm not proposing that we move the content of the registries into DID Core 17:29:25 ... I'm proposing we not use an issue tracker that sees no foot traffic 17:29:31 ... there are laready sections of DID core that point to the registries 17:29:34 q+ to note why there is probably no engagement. 17:29:36 ... and when DID core is set in stone, those sections ar eset 17:29:46 ... what the registries WG decides to do at that point, there is a risk of privilige escalation 17:29:56 ... if they decide DID core was wrong and decide to take DID Core apart because they have a WG 17:29:57 q+ 17:29:58 ... that could be a thing 17:30:01 q+ 17:30:05 ... you can approve new terms and add new deprecation warnings 17:30:30 ... Registries maintained by editors in a new WG without the proper alignment with the DID WG that has ended, and the charter of the DID SPec registries maintenance group, I would fear priviliege escalation and goes off and harms DID Core 17:30:38 ... I'm suggesting DID COre should have language about the responsibilities of the registries 17:30:42 ... and should have some guidnece on governance 17:30:52 ... and propose we in the DID COre WG tighten that first and discuss it in the DID COre issue tracker 17:30:58 ... and to put the final point on it, definitely NOT merge the two documents 17:31:00 q+ to ask if we're actually talking about two maintenance WGs? 17:31:10 ... DID spec registries might two years from now say things that everyone who worked on DID core is going to be really unhappy with 17:31:39 q- 17:31:43 ivan: Orie, you misunderstood.. nobody is talking to have a separate WG for the registries. The plan and practice is that this WG with an appropriate scope, would continue as a maintenance WG 17:31:53 ... that means the WG would have in its scope the maintenance of the Core as well as the registries 17:31:59 ... there is no separation of responsibility 17:32:22 ... the only difference between the current WG and the maintenance WG like we hav enow with VC, is that the Core document should consider to be essentially done, which does not exclude addition to its technical content, taking care of errata etc 17:32:25 ack ivan 17:32:29 ... and the continuation WG would have the right to do so 17:32:33 ack brent 17:32:33 brent, you wanted to ask how that works with Registries being non normative and to ask if registry governance needs to be normative 17:32:34 ... there is no problem there of what you were afraid of 17:32:41 q+ to ask about what the maintence wg can do to the registry 17:32:48 brent: question - does registry governance need to be normative and how does that work if the registries are a non normative note? 17:33:13 ivan: this is something.. what probably the process 2021 will say is that the registry would represent a kind of document which does not exist today 17:33:18 ... it is a not a recommendation, there is no CR phase 17:33:26 ... it is not a NOTE because it is reviewed 17:33:34 ... but the only thing cast in concrete like a REC is the governance of the registry 17:33:46 ... that's exactly the problem that you are saying that this is the way it will work, there will be a review of the governance that cannot just change 17:33:52 ... and the content will obviously evolve 17:34:00 ack manu 17:34:00 manu, you wanted to note why there is probably no engagement. 17:34:04 manu: I think we can put this in a proposal 17:34:10 ... hopefully that addresses both jonathan and orie's concerns 17:34:17 ... I want to speak to why registries tend not to get a lot of discussion 17:34:27 ... stuff in registries tends to be extensions that people fundamentally don't care about unless it's theirs 17:34:45 ... people tend to not be too concerned about plumbing, it's somebody elses' sproblem, i think that is what we are suffereng from and every registry suffers from 17:34:55 ... moving the discussion into did core is not going to change that, people will continue to not care about plumbing 17:35:12 ... I also think let's keep the issue tracker separate. I think the reason the CDDL stuff didn't get a ton of review is people aren't depending on it yet 17:35:18 ... if people start depending on it or care about it you will see more feedback 17:35:28 ... I expect a very sharp uptick in interest when they can't pass the test suite because the CDDL is causing that 17:35:31 ... there's a timing aspect of this 17:35:39 ... everyone wants to get IDD Core done before they focus on the regstries 17:35:51 ... it's frustrating but th ereality is moving where people talk about issues rarely gets people to talk about issues they're not concerned about 17:36:02 ... I'm hearing there's a desire to have the maintenance process normatively defined in DID Core 17:36:06 q- 17:36:07 q+ to take up the proposal. 17:36:11 ack drummond 17:36:41 drummond: to clarify with orie that if we do this properly, as ivan says they're still putting the process in place at w3c, the goal is the registry beocmes something we're maintaining and the maintenance WG can't turn around and change DID Core 17:36:48 ... it can only do what the WG is chartered to do 17:37:07 ... the governance of the registry, we need to decide on that and write it in now, we do that as *this* WG, and the registry has to be maintained that way, they can't arbitrarily change the governance 17:37:18 ... the way we set up the process those fears aren't going to happen 17:37:30 I'm still wondering is registry governance NEEDS to be normative 17:37:32 q+ 17:37:34 ... that will come down to each party a stakeholder that says I need a new extension will argue for it, folks who will enforce the governance rules, and away it goes 17:37:42 ack manu 17:37:42 manu, you wanted to take up the proposal. 17:37:52 PROPOSAL: The DID Spec Registries maintenance process will be normatively defined in DID Core. 17:37:56 +1 17:38:02 -1 17:38:04 +1 (with appropriate pointer from DID Spec registry to the process) 17:38:04 -0 I think that's out of place in the spec 17:38:10 -1 17:38:31 ack JoeAndrieu 17:38:31 0 17:38:32 q+ to ask about what this means? 17:38:36 +0, not sure what language would be 17:38:41 0 17:38:42 JoeAndrieu: it feels to me that the structure of the registry should be self defining 17:38:53 ... Orie, I don't know how to characterise your fears in a diplomatic way 17:39:02 ... the maintenance group needs to be able to change anything because we don't know what might happen 17:39:04 q+ to kill it with fire -- we put the process in DID Spec registries so it would be documented there. 17:39:22 ... if it was literally locked down, we wouldn't have a maintenance group. There may be lawsuits.. it's the maintenance group's job to figure that out within the scope of what is chartered 17:39:30 ... I'm not worried about the fears because that's their job is to navigate those two tensions 17:39:32 ack Orie 17:39:32 Orie, you wanted to ask about what this means? 17:39:33 Orie: I can get behind that 17:39:45 ... I think the concern here is that there's going to be a living thing with less eyes on it than the DID WG 17:39:56 q+ 17:40:01 ... everything method in there might get annotated with ethereum considered not safe, bitcoin considered not safe.. who ever is merging those.. are people watching it? 17:40:07 ... I agree it's plumbing, but if it's done wrong it can kill you 17:40:20 ... as long as there is enough structure in the regsitries and something formal that the registry editors can't just give themselves god privileges 17:40:24 ... it' can't be an unbounded authority 17:40:29 ... I agree we don't know what will need to be updated 17:40:32 ... we have to account for some of that 17:40:39 +1 to defining the governance process for the registries in the registries spec since that's how the proposed process is supposed to work for registries at W3C. 17:40:40 ... I just feel uneasy about the way that its governance is defined today 17:40:51 ack manu 17:40:51 manu, you wanted to kill it with fire -- we put the process in DID Spec registries so it would be documented there. 17:40:52 ... I'm not specifically seeing language to improve that which is why I'm concerned. but possible we can fix it 17:40:57 The governance section of DID Spec Registries is an open action item. 17:41:12 manu: the reason why we decided to put the maintenance process in the did spec registries doc in the first place, is we want people to read the process to add to the registry while you're looking at the registry 17:41:14 +1 to Orie, perhaps the language in did core points to the charter of the maintenance group for the governance 17:41:18 ... so it's obvious, it's at the top of th edocument how to add stuff 17:41:44 q+ to talk about how much simpler this all gets if there is going to be a maintenance WG as Ivan proposes. 17:41:48 q+ to ask if we can just pretend process 2021 is already here and make normative statements in the registries doc 17:41:54 ... with respect to Orie's concerns, you can't stop a concerted set of individuals of making the changes you disagree with, but you can put enough oversight over the doc, so it is hopefully prevented or if it were to happen ther is a process to go through by appealing to the WG and if you're not happy then appealing to w3c staff 17:42:03 ... anything beyond there says you don't trust w3c process or any of the checks and balances 17:42:07 ... and there's not much we can do outside of that 17:42:20 ... If you want people to look at this stuff, you can't wish it into existence. It's only going to have as much people looking at it as care about it 17:42:32 ... the vast majority of people just do not care about the plumbing. I agree bad plumbing can kill you 17:42:38 ... people only pay attention when the pipes are bad. When they're good they don't care 17:42:49 ... It's specifically up to the editors to make sure people look at it when things come across to be merged 17:42:56 ... Eg. let's say somebody decided to register did:nike 17:43:02 ... the first thing the editors say is no that's trademark 17:43:21 ... and someone says no I want it in there, i'm going to raise it, they say talk to the DID WG, and they say no, and the person insists, an dthey escalate to w3c who has the final word 17:43:28 ... that gets more people looking at it, without needing a heavy oversight process 17:43:34 ... fundamentally to get people looking into it, it is the editors job 17:43:50 q? 17:43:54 ack ivan 17:44:02 ivan: I try to understand the worries of Orie 17:44:07 ... today, you are the editor of the registry document 17:44:09 ... you are part of the WG 17:44:24 ... and you know you don't have the right to accept any PR just out of your own judgement 17:44:32 ... and that pr can be merged only through the approval of the WG 17:44:41 present+ 17:44:42 ... there is a first level, the WG has the responsibility of what happens with the registry doc 17:44:52 ... this is exactly the same situation as what will happen iwth a maintenance WG 17:44:56 +1 to document the governance in the DID Spec Registries. If possible let's agree on this call who is going to collaborate on the PR 17:45:03 ... there's no change. The Editor of the registries whether it's you or someone else, should not have more right than what you have today 17:45:14 ... if you are not worried about this problem right now then why would you be worried about the problem with a maintenance WG 17:45:52 ... And what's in section 3 which is the registration process, as far as I can read it, ti deosn't have anything about.. it's only a technical registration process, it doesn't have anything about governance. I would be fine if we want to put something into that section on the governance of the registration process 17:46:18 ... it is part of a note, section 3 will be something reviewed eventually when the new process comes into being, so section 3 of this document must not change.. can only change as far as a REC can change 17:46:24 ... we sort of cast it in concrete 17:46:28 ack drummond 17:46:28 drummond, you wanted to talk about how much simpler this all gets if there is going to be a maintenance WG as Ivan proposes. 17:46:42 yeah... agreed we need governance in the regstries, I think that's the core issue.. 17:47:03 drummond: when we define the governance process in section 3, I always thought the biggest challenge was if we don't have a formal structuere how do we arrange that governance to work 17:47:10 ... as soon as I heard the proposal of the maintenance WG, it gets much simpler 17:47:22 ... we still need to define the process, but now we have a WG who can apopoint and maintain editors 17:47:30 ... the first line is the editors following the process 17:47:34 ... an appeal can go to the WG, then to w3c 17:47:39 ... I think that's all that's going to be necessary 17:47:51 ack brent 17:47:51 brent, you wanted to ask if we can just pretend process 2021 is already here and make normative statements in the registries doc 17:47:53 ... if everyone is good with that let's make it so 17:48:12 brent: it sounds like it would be good if the governance principles or guidence for the registries were normative 17:48:22 q+ to put forward proposals. 17:48:39 ... but it would be better at this point if the guidnec was part of the DID Spec NOTE so that when process 2021 exists with the registries portion, the maintenance group could then make that portion of the registries NOTE normative? 17:48:42 ivan: yea 17:48:45 ack manu 17:48:45 manu, you wanted to put forward proposals. 17:48:55 manu: to reaffirm that we are going to put this process in the DID SPec Registries document 17:49:02 PROPOSAL: The DID Spec Registries maintenance process will be documented in the DID Spec Registries document. 17:49:03 +1 17:49:04 ... that doesn't mean we can't change it in the future onc ethe w3c proces sstuff is resolved 17:49:05 +1 17:49:06 +1 17:49:07 +1 17:49:11 +1 17:49:12 +1 17:49:12 +1 17:49:13 +1 17:49:31 +1 17:49:53 RESOLVED: The DID Spec Registries maintenance process will be documented in the DID Spec Registries document. 17:49:55 q+ to run next proposal 17:50:01 ack manu 17:50:01 manu, you wanted to run next proposal 17:50:02 but, can we refer to it in did core? 17:50:13 manu: the next proposal has to do with who gets to add stuff to the registries and what they should consider 17:50:18 ... the who, the first line is the editors 17:50:30 ... they have to consider copyright, trademark, legal, security, privacy and other concerns 17:50:45 ... we are explicit about that because people are trying to sneak trademarks or racist or other harmful terms in, and it is up to the editors to decide what causes harm 17:51:02 ... but if the editors say no,t he person wanting to add the item, can say they disagree and want WG opinion or I want w3c staff to weigh in on this after the WG has been put forward 17:51:05 PROPOSAL: The Editors of the DID Spec Registries must consider copyright, trademark, legal, security, and privacy concerns when reviewing additions to the registry and may reject registry entries if they deem the addition would cause undue harm. Entities registering items can challege rejections first with the DID WG and then with the W3C Staff. 17:51:10 q+ to ask about legal liability? 17:51:14 q+ 17:51:24 ack Orie 17:51:24 Orie, you wanted to ask about legal liability? 17:51:40 Orie: I hope thi sisn't a can of worms, but the way it is phrased is that we're singling out the editors as being legally liable? if someone says no I'd be fine 17:51:43 ivan: there is no legal liability 17:51:45 drummond: right 17:51:47 JoeAndrieu: are you sure? 17:53:12 Agree with Manu that the legal responsibility lies with W3C 17:53:30 Orie: I feel protected. 17:53:34 ack JoeAndrieu 17:53:47 s/manu: the editors don't have legal liability that we should be concerned about, nor does the WG// 17:53:53 q+ 17:54:08 JoeAndrieu: we should have a moral clause 17:54:10 q+ 17:54:25 ... people could spam the system and make it look unprofessional with things that are not profanity or trademarks, and we shoudl give the editors some way to engage with those issues 17:54:30 ack drummond 17:54:36 brent: i don't think thhis proposal limits us from adding that additional protection in the future 17:54:59 drummond: my assumption is this proposal is an overall directive to the preparation of the governance rules that will go in section 3, an dagree with joe, we don't just provide a list of hey think about these things 17:55:07 ... we need to provide policies, they're not rocket science or hard to write 17:55:22 ... I'm positive with just the folks on this call we can arrive at something 17:55:47 ... if we've narrowed it down to this an dthe folks on this call care, we can nail it down 17:55:52 ... this is not the whoel guidence 17:55:59 ... it's just the agreement we're going to go write that section and put guidence in it 17:56:03 ack jonathan_holt 17:56:17 jonathan_holt: i do like the way that ietf uses rfcs to formalise the process for comments rather than just the issue tracker 17:56:22 @manu, can we add "moral" to that proposal? 17:56:46 ... as well as aries and ethereum, where i'ts a document that has a structure to argue thte case, and a formal process to review those documents, provide comments, and bubble up to PRs. I'd like to see that as part of the governance structure 17:56:52 I like Jonathan's idea 17:56:54 thanks 17:56:59 PROPOSAL: The Editors of the DID Spec Registries must consider copyright, trademark, legal, security, moral, and privacy concerns when reviewing additions to the registry and may reject registry entries if they deem the addition would cause undue harm. Considerations will be expressed as policies in the DID Spec Registries Process section. Entities registering items can challege rejections first with the DID WG and then with the W3C Staff. 17:57:24 +1 17:57:24 +1 17:57:25 +1 17:57:25 +1 17:57:25 +1 17:57:26 +1 17:57:26 +1 17:57:31 +1 17:57:34 +1 17:57:47 drummond: this is productive and a good conclusion 17:57:47 q+ 17:57:52 RESOLVED: The Editors of the DID Spec Registries must consider copyright, trademark, legal, security, moral, and privacy concerns when reviewing additions to the registry and may reject registry entries if they deem the addition would cause undue harm. Considerations will be expressed as policies in the DID Spec Registries Process section. Entities registering items can challege rejections first with the DID WG and then with the W3C Staff. 17:57:53 q+ to run another proposal 17:58:00 ack ivan 17:58:08 ivan: two minor things.. this question of trademark, legal, etc, came up in issue 425 17:58:24 ... and I did ask wendy seltzer to comment on this, Joe, I dont' know if you saw the reply it's in the issue 17:58:33 Sure, we're on a roll, if we can get in one more, let's go for it. 2 mins and waiting... 17:58:42 ... you may want to look at it, I can't judge it, she's referring to the iana protocol registry and registration procedures to be looked at and maybe use it as a guidence for what we want to do 17:58:44 ... that's one thing 17:59:09 +1 to Ivan structuring the minutes 17:59:10 ... the other very minor thing is.. can i structure the discussion in the minutes? 17:59:11 brent: yes 17:59:18 PROPOSAL: W3C Staff need not be consulted on changes to the DID Spec Registries, but do have the final say on registry contents. This is to ensure that W3C can adeqately respond to time sensitive legal, privacy, security, moral, or other pressing concerns without putting an undue operational burden on them. 17:59:33 manu: this proposal just makes it clear that we don't expect w3c staff to be consulted on every single change to spec registries, but they are the ultimate authority in this 17:59:40 ivan: there is a staff contact in the WG anyway 17:59:55 manu: I expect you dont' want to be in every single decision in the registries and for us to be mandated to talk with you? 18:00:09 ... staff in general, whoever that is 18:00:11 +1 18:00:11 +1 18:00:11 +1 18:00:12 +1 18:00:13 +1 18:00:14 0 18:00:29 +1 18:00:31 +1 18:00:39 RESOLVED: W3C Staff need not be consulted on changes to the DID Spec Registries, but do have the final say on registry contents. This is to ensure that W3C can adeqately respond to time sensitive legal, privacy, security, moral, or other pressing concerns without putting an undue operational burden on them. 18:00:55 Nice job everyone 18:01:00 brent: we'll bring up these resolutions on the main call on tuesday. Thanks! 18:01:02 And Amy, you are the best! 18:01:07 zakim, end meeting 18:01:07 As of this point the attendees have been ivan, shigeya, rhiaro, brent, jonathan_holt, manu, drummond, JoeAndrieu, Orie, burn, agropper, justin_r 18:01:09 RRSAgent, please draft minutes 18:01:09 I have made the request to generate https://www.w3.org/2020/12/17-did-topic-minutes.html Zakim 18:01:12 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 18:01:16 Zakim has left #did-topic