15:40:32 <RRSAgent> RRSAgent has joined #did
15:40:32 <RRSAgent> logging to https://www.w3.org/2022/01/11-did-irc
15:40:34 <Zakim> RRSAgent, make logs Public
15:40:35 <Zakim> please title this meeting ("meeting: ..."), ivan
15:40:51 <ivan> Meeting: DID WG Telco
15:40:51 <ivan> Chair: brent
15:40:51 <ivan> Date: 2022-01-11
15:40:51 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2022Jan/0001.html
15:40:51 <ivan> ivan has changed the topic to: Meeting Agenda 2022-01-11: https://lists.w3.org/Archives/Public/public-did-wg/2022Jan/0001.html
15:48:09 <TallTed> TallTed has joined #did
15:58:40 <pchampin> pchampin has joined #did
15:58:52 <ivan> present+
15:58:56 <mprorock> mprorock has joined #did
15:59:03 <brent_> brent_ has joined #did
15:59:06 <pchampin> present+
15:59:40 <ivan> present+ mprorock
16:00:26 <shigeya> present+
16:00:26 <burn> burn has joined #did
16:00:33 <ivan> present+ brentz
16:00:33 <ivan> present+ shigeya
16:00:44 <ivan> present+ markus
16:01:08 <markus_sabadello> markus_sabadello has joined #did
16:01:22 <cel> present+
16:01:23 <brentz> present+
16:01:32 <Orie> Orie has joined #did
16:01:33 <markus_sabadello> present+
16:01:38 <Orie> present+
16:02:30 <cel> scribe+
16:02:33 <ivan> present+ dmitri
16:02:44 <cel> topic: Agenda Review
16:02:54 <ivan> present+ TallTed
16:03:06 <cel> brentz: A few minutes to Ivan, then talk about meeting schedule, then a few minutes about the id method, then the bulk of the time for the keri method.
16:03:13 <ivan> present+ manu
16:03:15 <cel> ... Anything to add/modify?
16:03:39 <cel> ivan: Some of you probably know that I have partially retired this year.
16:03:51 <cel> ... I am still active at W3C but on a reduced hour compared to before.
16:04:04 <cel> ... Other fact is that there are new activities with the VC WG, and with the canonicalization WG.
16:04:17 <cel> ... Bottom line is that I cannot be the staff contact for all these at once.
16:04:33 <cel> ... After discussing it with Brent, I decided I will stay active in the VC WG with Brent...
16:04:55 <cel> ... I am happy to introduce Pierre-Antoine Champin, "Pa", who will be the staff contact for this WG.
16:05:15 <cel> ... While the FOs are underway, I will also stay along, so there can be a smooth change.
16:05:41 <cel> ... Pierre-Antoine knows a lot about the web, and about JSON-LD, made an implementation of JSON-LD in Rust.
16:05:45 <justin_r> justin_r has joined #did
16:05:50 <justin_r> present+
16:05:51 <cel> pchampin: Thank you for the kind introduction
16:05:58 <ivan> present+ drummond
16:06:02 <cel> ... As Ivan told, I joined the W3C team a year ago, as a fellow.
16:06:11 <cel> ... Before that - I'm technically still an associate professor.
16:06:22 <cel> ... Involved in other groups... JSON-LD 1.1
16:06:35 <ivan> present+ rgrant
16:06:35 <cel> ... I've followed at a distance this group's activity...
16:06:54 <ivan> present+ agropper
16:07:01 <drummond> drummond has joined #did
16:07:01 <cel> ... I didn't write a JSON-LD impl in Rust, but contributed to an impl
16:07:10 <drummond> present+
16:07:12 <cel> ... I think that will give me time enough to get into the swing (Ivan staying along)
16:07:13 <manu> Very excited to have PA involved! :)
16:07:17 <cel> ivan: But you mastered Rust
16:07:24 <rgrant> rgrant has joined #did
16:07:38 <rgrant> present+
16:07:39 <cel> brentz: Reminder: Credentials Community Group (CCG) meeting after this meeting. Discussing chair election process as a chair has stepped down.
16:07:41 <manu> s/PA/Pierre-Antoine/
16:07:44 <brentz> Topic: Upcoming meeting schedule
16:08:09 <cel> topic: In recognition of the fact that we exist as a working group due to administrative extensions of our charter, in order to wait out the formal objection processs...
16:08:14 <cel> s/topic:/brentz:/
16:08:38 <cel> brentz: ... and in recognition of the monumental work that has been done, the chairs will be curtailing meetings going forward
16:08:45 <cel> ... We will be keeping abreast of changes...
16:09:11 <cel> ... So we won't be discussing did registries, rubric, impl guide, etc. We've published them, and feel the work is primarily done,
16:09:22 <cel> ... and feel deserving of spending a little less time on DIDs.
16:09:45 <cel> ... We ask you keep this slot on your calendars, but unless you get an agenda announcement, don't come, since we won't be here.
16:09:53 <brentz> q?
16:09:55 <manu> +1 on the proposed direction.
16:10:02 <drummond> +1 to this transition
16:10:04 <ivan> q+
16:10:12 <brentz> ack ivan
16:10:12 <cel> ... If nothing more to discuss, this may be our last meeting.
16:10:14 <Orie> +1 on the proposed direction
16:10:33 <cel> ivan: Just to make it clear, we don't intend to close down the repositories. Any discussion on GitHub - which this group is very active on - is of course very possible and welcome.
16:10:47 <cel> brentz: Yes, continue to work offline. If anyone feels the group needs to meet and discuss something, that's possible.
16:10:59 <cel> ... I don't think it's necessary to do a proposal... We've fulfilled our charter.
16:11:10 <cel> ... But if someone wants to propose a proposal, we have time...
16:11:25 <Orie> Agree with brent, we don't need a proposal to do what we are doing.... we would need proposals and resolutions to do something else, imo.
16:11:38 <cel> agropper: Where might we discuss biometrics as it relates to the current or future DID specifications?
16:11:46 <ivan> q+
16:11:51 <cel> brentz: the CCG probably would be the best place
16:11:55 <brentz> ack ivan
16:12:00 <cel> ivan: At this moment, the CCG...
16:12:15 <Orie> Biometrics should be discused here: https://github.com/fedidcg/
16:12:17 <cel> ... What we don't know yet is what exactly we will put in the charter for a future version of the DID specification.
16:12:43 <manu> q+ on "maintenance WG".
16:12:55 <cel> ...  Originally the idea was that the next version of the DID WG would be the maintenance WG, and so would not include something like that... but who knows, these days things are changing rapidly - maybe we will have a full-blown specication on our hands
16:12:55 <brentz> ack manu
16:12:55 <Zakim> manu, you wanted to comment on "maintenance WG".
16:13:35 <Orie> DIF would also be a good place to discuss. biometrics, there is a device binding work item in the wallet security group.
16:13:44 <JoeAndrieu> JoeAndrieu has joined #did
16:13:53 <JoeAndrieu> present+
16:14:16 <brentz> Topic: did:id Method
16:14:20 <markus_sabadello> q+
16:14:29 <brentz> subtopic: https://github.com/w3c/did-spec-registries/pull/363
16:14:39 <brentz> ack markus_sabadello
16:15:02 <cel> markus_sabadello: This is a new PR to add a DID method to the registry
16:15:10 <cel> ... I have reviewed it and requested changes.
16:15:25 <agropper> agropper has joined #did
16:15:37 <cel> ... I think it's a pretty extreme example of a centralized DID method that has significant privacy issues... big potential for surveillance and censorship, and other problematic things.
16:15:46 <agropper> present+
16:15:56 <ivan> q+
16:16:01 <cel> ... I think this stands against everything DIDs stand for... But we decided centralized DID methods can be registered
16:16:15 <cel> ... But I think some of these issues should be mentioned in the method specification
16:16:25 <manu> i/DIF would also/Manu: I think a maintenance WG is fine, the community is doing DID Method interop in the CCG on did:key and did:web, and it's not clear if that work will make the three orgs that have raised FOs happy. So, +1 for maintenance WG for next DID WG./
16:16:27 <cel> ... (did:id by Mastercard)
16:16:46 <cel> ... They have some of these considerations in there, but there are many others they should be mentioning...
16:17:12 <cel> ... tracking, etc.
16:17:19 <manu> q+ to agree with concerns that Markus has said, and how we might deal with this in the future.
16:17:36 <ivan> present+ selfissued
16:17:52 <brentz> ack ivan
16:18:09 <markus_sabadello> Summary is that even though the method spec has a Privacy Considerations section, I think it is missing much that matters, and therefore the method spec is incomplete.
16:18:53 <markus_sabadello> q+
16:19:04 <mprorock_> mprorock_ has joined #did
16:19:10 <brentz> ack manu
16:19:10 <Zakim> manu, you wanted to agree with concerns that Markus has said, and how we might deal with this in the future.
16:19:33 <cel> ivan: ...
16:19:44 <cel> manu: I think we should discuss this after recharter
16:19:55 <Orie> +1 manu, this is a charter conversation... that aligns with the FOs perspective as well, AFAIK.
16:20:43 <mprorock_> mprorock_ has joined #did
16:20:43 <agropper> agropper has joined #did
16:20:43 <JoeAndrieu> JoeAndrieu has joined #did
16:20:43 <rgrant> rgrant has joined #did
16:20:43 <drummond> drummond has joined #did
16:20:43 <justin_r> justin_r has joined #did
16:20:43 <Orie> Orie has joined #did
16:20:43 <markus_sabadello> markus_sabadello has joined #did
16:20:43 <burn> burn has joined #did
16:20:43 <brentz> brentz has joined #did
16:20:43 <mprorock> mprorock has joined #did
16:20:43 <TallTed> TallTed has joined #did
16:20:43 <tzviya> tzviya has joined #did
16:20:43 <smoothsalt> smoothsalt has joined #did
16:20:43 <faceface> faceface has joined #did
16:20:43 <dlehn> dlehn has joined #did
16:20:43 <asocrt> asocrt has joined #did
16:20:43 <juancaballero> juancaballero has joined #did
16:20:43 <damian77> damian77 has joined #did
16:20:43 <msim> msim has joined #did
16:20:43 <cel[m]> cel[m] has joined #did
16:20:43 <dietrich> dietrich has joined #did
16:20:43 <bigbluehat> bigbluehat has joined #did
16:20:43 <dlongley> dlongley has joined #did
16:20:43 <manu> manu has joined #did
16:20:43 <etropea73101> etropea73101 has joined #did
16:20:43 <cypherhippie> cypherhippie has joined #did
16:20:43 <shigeya> shigeya has joined #did
16:20:43 <Travis> Travis has joined #did
16:20:43 <hadleybeeman> hadleybeeman has joined #did
16:20:43 <jyasskin> jyasskin has joined #did
16:20:43 <wayne> wayne has joined #did
16:20:43 <cel> cel has joined #did
16:20:54 <brentz> q?
16:21:02 <ivan> q+ dmitriz
16:21:04 <selfissued> selfissued has joined #did
16:21:06 <JoeAndrieu> q+ to say its inappropriate to change the rules because we don't like the method
16:21:13 <selfissued> present+
16:21:14 <cel> ... Markus, I appreciate that you are trying to fight from a principled position, but we would be changing the rules.... compared to the ones that came before it.
16:21:17 <selfissued> q+
16:22:03 <cel> ... We want to improve the registries, we can do that later... one thing would be to apply all the normative statements in the DID Methods section, make an announcement months in advance saying methods need to be updated or fall out of the registry
16:22:25 <cel> ... But I think even then Mastercard would be reregistered.
16:22:31 <brentz> ack markus_sabadello
16:23:09 <cel> markus_sabadello: Completely agree we shouldn't change the rules of the process. I don't think we should allow centralized DID methods. Can't change that now. But the Privacy & Considerations section doesn't discuss the considerations.
16:23:22 <cel> ... Same as if the DID Syntax section didn't describe the syntax of the DID...
16:23:29 <drummond> I am willing to offer to facilitate a dedicated discussion w/the Mastercard team about what changes would be necessary to accept their method if that would help.
16:23:34 <manu> These are different rules -- I want to be crystal clear about this.
16:23:46 <manu> We have not applied this level of scrutiny to any other DID Method.
16:23:53 <brentz> ack dmitriz
16:23:54 <cel> ... Section doesn't describe the privacy considerations. We have requested changes from a lot of changes from other DID methods that were incomplete and missing significant parts, and that's also what we should do here.
16:24:17 <justin_r> huge +1 to everything Dmitri just said
16:24:22 <cel> dmitri: this group created the registry rules and can change tham. We're under no obligation to apply the same criteria, we can change the rules going forward.
16:24:44 <brentz> ack JoeAndrieu
16:24:44 <Zakim> JoeAndrieu, you wanted to say its inappropriate to change the rules because we don't like the method
16:24:46 <cel> ... I understand we have limited charter status; I would propose we do not accept any more, or await discussion of this DID method until the next chartered group.
16:24:56 <Orie> The charter should guide a change of rules... I hear a proposal to pause all new registrations... make a proposal please.
16:25:25 <cel> JoeAndrieu: I agree with what Manu and not with what Dmitri said. I think it's against our framework to change the rules. I agree don't like centralized methods...
16:25:35 <mprorock_> +1 manu and JoeAndrieu
16:25:40 <justin_r> -1 to JoeAndrieu
16:25:45 <cel> ... But when we change rules because we don't like it, it's like abandoning free speech because we don't like what was said.
16:26:06 <brentz> ack selfissued
16:26:17 <cel> ... We could have criteria that might remove methods... but I believe we meet the requirements as said, and would abandon our moral integrity to change it
16:26:25 <Orie> justin_r thats not a generous interpretation, I am hearing that we can change the rules, and that we should use the charter to give use clearer powers regarding these changes.
16:26:33 <markus_sabadello> This one isn't spec conformant.
16:26:40 <cel> selfissued: We decided we would not apply criteria to determine spec conformance...
16:26:55 <Orie> +1 selfissued
16:26:57 <cel> ... Otherwise we have no grounds to run a registry if we're going to pick and choose what to register.
16:27:00 <brentz> q?
16:27:02 <manu> There is no requirement to be spec conformant, Markus.
16:27:03 <manu> q+
16:27:07 <brentz> ack manu
16:27:08 <cel> ... We should stop that and register it right now.
16:27:53 <markus_sabadello> q+
16:28:01 <cel> manu: To respond to what Markus said, we have no such requirement to be spec conformant. We call out a couple things (have to do the CRUD stuff), but we don't require full spec compliance (we should in the future, when we've got our act together on all these things). Agreeing with Mike Jones
16:28:06 <brentz> ack markus_sabadello
16:28:10 <burn> present+
16:28:31 <cel> markus_sabadello: I think if it's not spec-compliant, we do have a rule in the spec registries that says that DID methods that don't meet the requirements in DID Core won't be accepted...
16:28:51 <cel> ... Even if we don't apply it, since in the past we haven't, even then I think this registration should not be accepted as-is, because it's incomplete.
16:28:57 <manu> Just about every DID Method is incomplete... not a good criteria.
16:28:59 <brentz> q?
16:29:23 <manu> q+ to suggest a determination.
16:29:31 <brentz> ack manu
16:29:31 <Zakim> manu, you wanted to suggest a determination.
16:29:35 <cel> brentz: We've heard arguments for an against merging it. The chairs leave it to the editors to make a determination here. We will note any objections.
16:29:38 <Orie> PROPOSAL: we will merge did:id over the objection from markus.
16:29:44 <mprorock_> +1
16:29:44 <Orie> please run the proposal
16:29:45 <cel> manu: Editors, I suggest a determination to merge it as-is.
16:29:46 <manu> +1
16:29:48 <drummond> q+
16:29:49 <Orie> +1
16:30:30 <cel> drummond: I wanted to suggest the editors should discuss it on the call on Thursday.
16:30:36 <Orie> -1 to discussing, we have discussed this on the editors call for months.
16:30:39 <cel> manu: The ditors discussed it on the last week's call.
16:30:41 <drummond> -1
16:30:48 <brentz> ack drummond
16:31:06 <cel> drummond: I believe, Markus, we should have a conversation directly with the Mastercard people directly, and then have a vote.
16:31:17 <cel> s/people/team/
16:31:21 <mprorock_> -1 to yet another discussion
16:31:21 <cel> ... I think Markus's points have been well-made...
16:31:27 <Orie> we are here to get this on record, so this is a helpful process.
16:31:39 <cel> ... I think they would make changes that are satisfactory
16:31:56 <cel> brentz: Thank you for this conversation
16:31:59 <brentz> Topic: did:keri Method
16:32:17 <brentz> subtopic: https://github.com/w3c/did-spec-registries/pull/395
16:32:42 <cel> brentz: Changing the source repository for this method
16:32:53 <cel> ... KERI was created and then brought into DIF.
16:33:01 <justin_r> for the record and the notes: I agree w/ drummond and markus_sabadello re: registries and think dmitri's got the best proposed approach
16:33:03 <cel> ... There was a split in the KERI community, and one of the pieces of that is did:keri.
16:33:23 <cel> ... This PR moves the source repository link to outside DIF
16:33:27 <ivan> present+ burn
16:33:31 <markus_sabadello> q+
16:33:35 <manu> q+ to ask them to sort it out. :)
16:33:35 <cel> ... We've been essentially asked to arbitrate a decision that's not ours to make.
16:33:40 <brentz> ack markus_sabadello
16:33:46 <agropper> q+
16:33:53 <cel> markus_sabadello: In contrast to the previous topic, I don't actually have a very strong opinion here.
16:33:55 <Orie> q+ to suggest a formal proposal for pausing new registrations to the did spec registries methods section.
16:34:13 <cel> ... As a background, I believe this was worked on in DIF. Then there was a PR to change the location, and there has been a long discussion.
16:34:13 <drummond> q+ to note that I am working with the DIF and KERI folks to resolve this issue
16:34:28 <markus_sabadello> https://github.com/w3c/did-spec-registries/issues/399
16:34:29 <manu> q+ to note change controller issue
16:34:45 <cel> ... There was interesting discussion on something called a change controller - who would have the authority to make changes to a registration - Juan created an issue about that, #399, on how to set up privileges and governance for making changes.
16:35:03 <cel> ... I made a proposal that whoever is listed as a contact has the right to make changes, and is responsible for the consequences
16:35:13 <JoeAndrieu> q+ to suggest adding changeController section with support for email, github, and did properties
16:35:13 <cel> ... to attempt to keep controversy out of the WG.
16:35:21 <cel> ... Note that this may be a change of rules
16:35:39 <cel> ... In this particular case I'm not sure if we should handle it like that; maybe for future changes.
16:35:50 <cel> ... In this case I think we should wait until their community issues as a result
16:35:55 <brentz> ack manu
16:35:55 <Zakim> manu, you wanted to ask them to sort it out. :) and to note change controller issue
16:36:02 <cel> s/issues as/issues/
16:36:20 <cel> manu: +1, there has been conversation
16:37:05 <brentz> q?
16:37:06 <cel> ... We've always put in things like contact email to mean something like change controller... Suggest we do a bulk search-and-replace to change "contact" to "change controlller"
16:37:09 <brentz> ack agropper
16:37:14 <drummond> +1 to Manu's proposal
16:37:37 <cel> agropper: It's probably not worth taking the group's time... but I have no idea what the controversy or substantive issue is that we're discussing. If that's my bad for not reading this very long thread, let's move on
16:37:50 <brentz> ack Orie
16:37:50 <Zakim> Orie, you wanted to suggest a formal proposal for pausing new registrations to the did spec registries methods section.
16:37:55 <cel> brentz: For now we'll move forward but if others want more detail, we can provide some
16:38:11 <cel> Orie: There have been a couple proposals made. We should try our best to run the proposals to record consensus on the call.
16:38:33 <cel> ... Specifically I think I heard Ivan, Dmitri, Justin... There might be interest in pausing new DID methods until the new charter is accepted
16:38:45 <cel> ... (reading between the lines)
16:38:46 <dmitriz> dmitriz has joined #did
16:38:56 <selfissued> q+
16:38:57 <cel> ... I q'd to run that proposal
16:39:12 <brentz> ack JoeAndrieu
16:39:12 <Zakim> JoeAndrieu, you wanted to suggest adding changeController section with support for email, github, and did properties
16:39:25 <cel> JoeAndrieu: I agree, best resolution is if DIF and Sam can figure it out
16:39:35 <cel> ... But if they don't, existing email contact is best
16:39:54 <cel> ... But need to push back that we always had this. In fact Veres One didn't have one until this week
16:40:07 <cel> ... When we reached out to method authors, we had a hard time getting contact info.
16:40:08 <brentz> +1 to Joe
16:40:25 <cel> ... I think an auto change would be unfortunate... The party to contact might not be the party with authority to make changes.
16:40:31 <cel> ... +1 to freezing registrations
16:40:43 <manu> -1 to freezing registrations
16:40:49 <cel> ... We should have a controller change property - DID, email, GitHub - multiple mechanisms
16:40:53 <brentz> ack selfissued
16:41:00 <manu> Agree with Mike Jones, again! :)
16:41:04 <cel> MikeJones: Should we pause, we are abdicating our responsibility to operate the registry.
16:41:11 <cel> ... How would people feel if IANA stopped accepting registrations?
16:41:15 <agropper> +1 MikeJones
16:41:19 <JoeAndrieu> that's a good point @selfissued
16:41:22 <cel> ... If we're claiming authority to operate it, we should not pause it.
16:41:22 <manu> +1 to Mike
16:41:23 <dmitriz> if IANA was about to be rechartered?
16:41:26 <Orie> +1 selfissued
16:41:28 <brentz> ack drummond
16:41:28 <Zakim> drummond, you wanted to note that I am working with the DIF and KERI folks to resolve this issue
16:41:31 <markus_sabadello> This is about pausing method registrations, not all registrations, right?
16:41:31 <justin_r> -1 to selfissued, pausing is :being: responsible and not reckless, in my opinion
16:41:32 <dmitriz> it would absolutely make sense for them to pause until rechartering
16:41:40 <cel> drummond: I just want to assure folks that we are working to resolve the conflicts in the DIF+KERI communities around this
16:41:52 <cel> ... Completely different question than what to do about the registries.
16:42:03 <manu> q+
16:42:08 <cel> ... In fact there's another call right after this one. Separate from proposals being made now.
16:42:17 <markus_sabadello> q+
16:42:19 <brentz> ack manu
16:42:19 <cel> brentz: Two proposals to run. Manu?
16:42:40 <cel> manu: +1 to what Mike Jones said. It would be an abdication of our responsibilities. The world goes on, people will create new DID methods.
16:42:43 <markus_sabadello> q-
16:42:49 <Orie> +1 manu
16:42:51 <JoeAndrieu> note: registration is not required
16:43:07 <drummond> I agree with Manu about not "abdicating" our responsibility for the registry
16:43:09 <cel> ... Just because we pause registrations, people are still making DID methods. Then there would be no up-to-date place for people to look for specs. -1 to pausing
16:43:10 <justin_r> also, registration is not normatively referenced from did core
16:43:50 <cel> ... about change controller, concerned... the points are good, but I never saw this like that... It was a change controller field. I think we can at least change contact email to change controller email, because that's how we've been using that field to date.
16:44:07 <cel> brentz: Queue is empty. Running the proposal Orie mentioned. ^
16:44:17 <rgrant> -1 to registry pause
16:44:20 <drummond> -1
16:44:31 <cel> ... Not voting yet... draft proposal
16:44:33 <ivan> -1
16:44:33 <brentz> PROPOSAL: We will stop accepting changes to the DID Method Registry until the DID WG is re-chartered
16:44:37 <manu> -1 (with pitch forks and torches)
16:44:38 <ivan> -1
16:44:39 <drummond> -1
16:44:39 <dmitriz> +1
16:44:39 <brentz> -1
16:44:40 <shigeya> -1
16:44:40 <burn> -1
16:44:41 <justin_r> +1
16:44:42 <agropper> -1
16:44:42 <JoeAndrieu> 0
16:44:42 <rgrant> -1 to registry pause
16:44:44 <Orie> -1
16:44:44 <pchampin> +0
16:44:50 <markus_sabadello> +0.5
16:44:52 <TallTed> -1
16:44:58 <selfissued> -1
16:44:59 <mprorock_> -1
16:45:01 <cel> -0.1
16:45:21 <cel> brentz: Not passing. Manu put draft language above... repeating as a draft - don't vote yet ^
16:45:30 <cel> manu: modify to changeControllerEmail?
16:45:39 <rgrant> q+ to comment
16:45:47 <brentz> ack rgrant
16:45:47 <Zakim> rgrant, you wanted to comment
16:45:52 <agropper> change controller did?
16:46:10 <drummond> Agree w/
16:46:12 <JoeAndrieu> q+
16:46:16 <cel> rgrant: The idea of change controller rename might be more acceptable if it is paired with a decision to in the future add another contact field, which may be a DID or other variable for contact
16:46:18 <brentz> ack JoeAndrieu
16:46:37 <cel> JoeAndrieu: I think that treating the contact email as change controller is entirely in scope and I would support that. But changing the semantics of conformance...
16:46:48 <cel> ... To rewrite that without their involvement I think is inappropriate
16:46:49 <brentz> PROPOSAL: For DID Spec Registries registration, change "contactEmail" to "changeControllerEmail" (with a definition of change controller) to be more clear about the purpose of the field.
16:46:53 <markus_sabadello> +1, but only apply to future cases
16:46:54 <JoeAndrieu> -1
16:46:57 <ivan> 0
16:46:58 <drummond> +1
16:46:59 <manu> +1
16:46:59 <shigeya> 0
16:47:00 <agropper> +0
16:47:05 <rgrant> +1
16:47:06 <justin_r> +1, the registries do not run at the whim of those who register within
16:47:07 <pchampin> +0
16:47:11 <burn> +1
16:47:14 <TallTed> +0.5
16:47:15 <brentz> +1
16:47:16 <Orie> +1
16:47:18 <cel> -0
16:47:19 <mprorock_> +1
16:47:21 <dmitriz> +1
16:47:23 <selfissued> 0
16:47:50 <markus_sabadello> q+
16:47:55 <brentz> ack markus_sabadello
16:47:58 <cel> brentz: Joe, and Markus, is there language that either of you would approve?
16:48:06 <justin_r> @markus any changes would only apply to future entries. Retroactive application is ... weird.
16:48:14 <cel> markus_sabadello: My assumption is that this would be applied to future cases anyway. Then we would just not change the rules for current cases.
16:48:14 <justin_r> at least with any registry I've ever seen
16:48:25 <rgrant> hmm, good point @markus_sabadello
16:49:03 <cel> JoeAndrieu: Justin, you seem to support it, but you suggest retroactive application is weird. That's my reason not supporting this - it's a retroactive application to those methods in ways they may not be aware of.
16:49:08 <markus_sabadello> In the whole did:id discussion, we consistently said that we woudn't change rules for current cases..
16:49:41 <cel> justin_r: Yeah, I get where you're coming from. If the worry is that changing the name of the field changes the semantics - people could either update it, or ignore it.
16:49:46 <manu> q+ to note it's not changing the semantics of how the registry editors have been treating the field.
16:49:57 <cel> ... If we want to be extraordinarily cautious, we could drop the field and add a new column
16:50:25 <markus_sabadello> q+
16:50:30 <cel> ... The spectre that keeps getting raised here is that if we change the rules... it's absurd. The editors do not agree with me, I think that is to this group's detriment...
16:50:48 <cel> ... I think changing the name is fine. The registry decides what the info in it means.
16:50:58 <ivan> present+ juancaballero
16:51:00 <rgrant> q+ to disagree
16:51:02 <brentz> ack manu
16:51:02 <Zakim> manu, you wanted to note it's not changing the semantics of how the registry editors have been treating the field.
16:51:03 <cel> ... If the registry decides it's a reasonable interpretation that this field now has this meaning, then we apply that.
16:51:32 <cel> manu: I think the thing that makes this different is that the editors have been treating all the contact fields as the change controller. We have no other signal as to who should be able to change that thing.
16:51:48 <brentz> qq+
16:51:50 <cel> ... We're not changing the semantics of the field, we're updating the name of the field to be clear to what we are using it for.
16:51:52 <JoeAndrieu> how about adding a changeController field with an email property that we set to the current contactEmail value as default
16:52:02 <cel> ... We're not changing process, we're making it more clear about what that field is meant to assert.
16:52:11 <brentz> ack brentz
16:52:11 <Zakim> brentz, you wanted to react to manu
16:52:18 <cel> ... That's why we think it's okay to make it "retroactively" - we're just making documentation more clear.
16:52:48 <cel> brentz: Please be respectful of one another and make sure we are cognizant of the hard work people have been making. People have been operating with the best interests of the group and the ecosystem at heart.
16:52:53 <brentz> ack markus_sabadello
16:53:32 <manu> I'm fine w/ holding on did:keri
16:53:43 <cel> markus_sabadello: Just to clarify what I meant "only for future cases" I think this change should be made both for current and existing DID method registrations, I agree with Manu that we should update it, but for existing changes in process (did:keri) we may want to wait
16:53:45 <manu> (until that community sorts its stuff out)
16:53:57 <cel> ... but I think it's fine for existing and future ones.
16:54:06 <brentz> ack rgrant
16:54:06 <Zakim> rgrant, you wanted to disagree
16:54:09 <cel> brentz: Five minutes left
16:54:10 <ivan> q?
16:54:11 <ivan> q+
16:54:15 <Orie> I am in favor of merging the PR for DID Keri, would love to run a proposal on that... would prefer more proposals and less debate.
16:54:43 <cel> rgrant: I think copying the fields allows us to maintain the prior contact field and either inform registrants that we are interested in change controller, and the best we can do is interpret contact as change controller
16:55:00 <cel> ... I disagree with that we can change the rules at any time. That's the same logic the formal objectors used.
16:55:14 <cel> ... I strongly suggest we don't be hippocritical
16:55:14 <brentz> ack ivan
16:55:20 <justin_r> to be clear, the ability to change rules is not arbitrary
16:55:40 <cel> ivan: don't want to go into the details, but we have to have a proposal of what to do with the did:keri PR, that's what's out there right now.
16:55:51 <manu> It will be viewed as arbitrary if we don't give everyone a heads-up on the rule changes (which is what I'm proposing)
16:56:05 <cel> ... I agree with Orie that a proposal should be done, but not with what he rights... The community out there, the did:keri community, they have to sort out their own problems.
16:56:13 <cel> ... To do it here, while it's unclear, is not right
16:56:14 <manu> We give everyone a big heads up on the rule changes (once we settle on them)... then give people ample time to bring themselves up to conformance
16:56:20 <Orie> +1 justin_r, we can change rules we are chartered to change... the ambiguity originates from what the current charter allows us to do to the registry.
16:56:21 <brentz> PROPOSAL: we will merge https://github.com/w3c/did-spec-registries/pull/395 since the change controllers / points of contact have approved the PR.
16:56:26 <rgrant> +1
16:56:26 <Orie> +1
16:56:33 <JoeAndrieu> +1
16:56:33 <ivan> -1
16:56:34 <selfissued> +1
16:56:36 <drummond> +1
16:56:38 <justin_r> +0
16:56:39 <pchampin> 0
16:56:39 <markus_sabadello> -1
16:56:46 <dmitriz> +1
16:56:47 <shigeya> +0
16:56:54 <agropper> 0
16:56:58 <manu> +0 (I'd rather the community figures their own stuff out first)
16:57:01 <juancaballero> 0, same reason
16:57:07 <TallTed> +0
16:57:07 <manu> s/the community/the did:keri community/
16:57:26 <cel> ivan: Based on the comment, my -1 is equal to manu's 0
16:57:35 <cel> brentz: markus_sabadello about your -1?
16:58:06 <cel> markus_sabadello: In this case I think we should wait for the did:keri community to figure out, because at the point when it was registered, it was not clear the meaning of the field.
16:58:29 <brentz> PROPOSAL: wait to merge PR 395 until the did:keri community sorts itself out
16:58:32 <manu> +1
16:58:33 <ivan> +1
16:58:33 <justin_r> +0
16:58:35 <JoeAndrieu> +1
16:58:37 <drummond> 0
16:58:37 <TallTed> +1
16:58:38 <markus_sabadello> +1
16:58:38 <burn> +1
16:58:39 <agropper> +1
16:58:40 <rgrant> 0
16:58:41 <shigeya> +1
16:58:42 <pchampin> 0
16:58:47 <selfissued> -1
16:58:49 <Orie> -1, they can always open another PR
16:59:00 <juancaballero> 0
16:59:09 <markus_sabadello> Like Brent, I'm also DIF Steering Committee, should I have abstained too?
16:59:12 <cel> brentz: Good conversation, will continue in PR 395
16:59:16 <TallTed> Is there a way we can add a note to the registry, that "xyz is in flux. see {uri}"?
16:59:26 <juancaballero> not necessarily, @markus !
16:59:44 <cel> brentz: Thanks for being here. We anticipate the next meeting not happening until February... We'll let you know... Keep this space available.
16:59:57 <cel> ... I'll do my best to say if a meeting is scheduled or not... but I am fallible
17:00:10 <cel> ... I've appreciated working with all of you, and look forward to doing so in the future. See you again!
17:00:12 <drummond> Thanks so much to Brent and Dan!
17:00:27 <Orie> thanks, especially for the polling, it helps editors a lot
17:00:33 <ivan> zakim, end meeting
17:00:33 <Zakim> As of this point the attendees have been ivan, pchampin, mprorock, shigeya, brentz, markus, cel, markus_sabadello, Orie, dmitri, TallTed, manu, justin_r, drummond, rgrant,
17:00:36 <Zakim> ... agropper, JoeAndrieu, selfissued, burn, juancaballero
17:00:36 <Zakim> RRSAgent, please draft minutes
17:00:36 <RRSAgent> I have made the request to generate https://www.w3.org/2022/01/11-did-minutes.html Zakim
17:00:38 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
17:00:42 <Zakim> Zakim has left #did
17:01:35 <ivan> rrsagent, bye
17:01:35 <RRSAgent> I see no action items