DID WG Telco — Minutes

Date: 2021-12-07

See also the Agenda and the IRC Log

Attendees

Present: Daniel Burnett, Ivan Herman, Justin Richer, Michael Prorock, Manu Sporny, Markus Sabadello, Orie Steele, Geun-Hyung Kim, Drummond Reed, Adrian Gropper, Brent Zundel, Ted Thibodeau Jr., Ryan Grant, Pamela Dingle, Charles Lehner, Dmitri Zagidulin

Regrets:

Guests:

Chair: Daniel Burnett

Scribe(s): Orie Steele, Manu Sporny

Content:

1. Agenda Review, Introductions.

Daniel Burnett: agenda… review, nobody new here… we are going to mention a rubric PR, and primary topic will be looking at registry PRs and issues..
… any requests for changes or additions?.
… one more admin item… we are canceling Dec 28and Jan 4th… we want to ask about the 21st…..
… who on this call knows they will not be able to attend the 21st.

Drummond Reed: I will not be able to attend.

Manu Sporny: I won’t be able to be here on 21st.

Daniel Burnett: seems like a few folks can’t make the 21st..

2. DID Rubric PR 59.

Daniel Burnett: next item on the agenda, did rubric https://github.com/w3c/did-rubric/pull/59.

See github pull request did-rubric#59.

Daniel Burnett: be aware, we are going to start tackling rubric PRs next….

3. Progress on DID Core Formal Objections.

Manu Sporny: There is an update from the AB regarding the DID Core FO..

Manu Sporny: https://www.w3.org/2021/11/04-ab-minutes.html#t04.

Manu Sporny: The AB met to discuss the FOs they have… they have a lot of FOs… they think that its related to not meeting face to face….
… there was a discussion regarding timing… the time frame they specified on the AC mailing list, see Ralph’s email regarding expected timeline..
… these minutes are new, and good, but there are already arguments being made about the way we tested stuff without the FO council being engaged….
… there are minutes demonstrating arguments against our test suites, but we can’t attend the meetings where this is discussed..
… we sent out a summary for where we are….

Manu Sporny: –> Summary of where we are to AC https://lists.w3.org/Archives/Member/w3c-ac-forum/2021OctDec/0316.html.

Manu Sporny: –> Link to DID WG Formal Objection FAQ https://github.com/w3c/2021-didwg-formal-objection-faq.

Manu Sporny: –> Rendered page is here https://w3c.github.io/2021-didwg-formal-objection-faq/.

Manu Sporny: Edit this file if you want to make changes: https://github.com/w3c/2021-didwg-formal-objection-faq/blob/gh-pages/index.md.

Manu Sporny: there was a response that was frustrating, folks should review and respond….
… I will share a link to the FO faq that we have written, and we can take changes on it now..
… if you have change suggestions, you should make changes to the file….
… the expectation is that FO council will review this document..

Ryan Grant: you proposed a letter last week, I had comments, do we have an update?.

Manu Sporny: I merged your comments and sent it.
… i think I got all your changes, so I sent it.

Ryan Grant: happy with the version we have now.

4. DID Registries PRs.

Daniel Burnett: https://github.com/w3c/did-spec-registries/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-asc.

Daniel Burnett: lets looks at registries PRs.

Michael Prorock: lets go through the normal order.

4.1. Registering did:snplab did method (pr did-spec-registries#340)

See github pull request did-spec-registries#340.

Michael Prorock: there are change requests from some folks and change request from others..
… looks like changes have been addressed.

Manu Sporny: +1, this has changes requested, waiting for PR submitter..

Orie Steele: please comment on the PR..

Manu Sporny: I thought we were still waiting on them….

Michael Prorock: there are still conflicts.

Manu Sporny: their security are privacy section needs work..

Michael Prorock: I will ping the PR.

4.2. Add did:earth (pr did-spec-registries#364)

See github pull request did-spec-registries#364.

Michael Prorock: next PR same issue, they need to be reminded to update the PR.
… correct the 404, remove conflicts..

Manu Sporny: I think we should ask them to close this PR.
… my understanding is that they wanted to register this, but they don’t have a spec, so they should raise the PR when they have one..

Michael Prorock: I will ping them.

4.3. Add conformance field for registration. (pr did-spec-registries#377)

See github pull request did-spec-registries#377.

See github pull request did-spec-registries#378.

Michael Prorock: next PR, 377… conformance registration related….
… there appear to be outstanding change requests.

Manu Sporny: I have had a change of heart on this PR, we should kill it with fire, and keep the registry simple..
… use other places to signal other things..
… lets make the editors job easier.

Michael Prorock: +1.

Manu Sporny: i am suggesting we close the 2 PRs that make the registration process more complicated immediately.

Orie Steele: +1 to closing those 2 PRs immediately.

Drummond Reed: I am supportive, but want to talk about the registration process for DID methods later (issue 382)..

Ryan Grant: this is a good idea… if we close this now, we might want to say where we think this should go… where might this go, should it all go in the rubric?.

Manu Sporny: I think the suggestion is put this anywhere else, rubric is an option, but we expect pushback… another possibility is another public site.
… we can actually pull the registry json file and annotate it elsewhere….

Ryan Grant: +1 to closing the PR and finding the spot later..

Manu Sporny: suggestion is put this anywhere but the did spec registries.

Drummond Reed: I have been thinking that additional information about the did spec method can go in the spec or in a self assesment… but its from the author of the spec… and that would not need to go to the registry.
… i have been thinking there should be a link from the registry to the spec, and they spec can link elsewhere..

Daniel Burnett: put a 7 day close on it.

Michael Prorock: next up ….

4.4. Add did:id: method (pr did-spec-registries#363)

See github pull request did-spec-registries#363.

Michael Prorock: 363 the did:id method … fantastic branding and naming.
… changes requested from markus.

Markus Sabadello: I have commented many times on this issue, i think its problematic registration of a centralized did method where the registry is controlled by one company, which is allowed, thats not forbidden..
… another challenge is the name, “id” sounds generic, and its also a “reserved property in the data model”… but that is also allowed..
… personally I feel like the combination of these facts, is potentially a violation of the rules.
… it might be more reasonable for it to be named mastercardid or mcid… there is another requirement regarding privacy and security considerations.
… the section does not sufficiently discuss specific threats, specifically the issues related to centralized did methods… I think the PR should be accepted without changes.
… should not..

Michael Prorock: I think this is a dangerous road to go down, regarding gatekeeping, the company registering this method owns the trademark, I don’t see any reason block registration..

Manu Sporny: markus there is an option in the current process, that allows us to annotate entries with warnings… if we are concerned we can add warnings… we could annotate the registry entries….
… I don’t think we have ever enforced all these rules on registration..

Markus Sabadello: first time I heard about the warnings… don’t think we have ever done that… we have not approved registrations that do not meet requirements… I think this registration does not meet the requirements..
… I don’t see what this has to do with trademarks or value judgement… just requirements.

Orie Steele: I’m an Editor of this specification, I do think this entry meets the registration requirements to the best of the registrants abilities. I think it meets the requirements. I don’t see an alternate path forward other than requesting concrete changes or closing PR, then merging. Markus, I heard you say concretely if they added a couple of sentences to Privacy/Security Considerations, they would meet the registration requirements. What concrete changes.

Manu Sporny: would be needed for them to meet requirements?.

Markus Sabadello: happy to add a comment.

Daniel Burnett: it may be appropriate for us to annotate entries that the WG has concerns with….
… we can always annotate this entry, we might say something regarding a “trademarked term”….

Ryan Grant: +1 to an annotation disclaiming the use of “id”.

Daniel Burnett: so folks have the context regarding this..

Manu Sporny: The registration process currently states – “Entries that are identified to cause interoperability problems MAY be marked as such at the discretion of the maintainers of this registry, and if possible, after consultation with the entry maintainer.”.

Manu Sporny: I was wrong, we don’t have an ability to apply annotate..
… we might be able to update the process to highlight any concerns..
… when people register, we are not applying the did method section consistently… I don’t think we can push back on this particular entry for those reasons..

Michael Prorock: I have strong concern on any value judgement in the registry, even if from the WG.

Markus Sabadello: we have text that says “the normative requirements for a method spec, did methods that don’t meet these requirements must not be accepted”.
… therefore this method should not be accepted… but if they added a few sentences, the PR should be accepted..

Michael Prorock: they have a reasonable privacy section - https://github.com/Mastercard/did-methods/blob/master/id.md - can those sections be better? yes always, but should that block this PR, likely not.

Orie Steele: I don’t think the DID Spec registries is a “values included” registry – the registry is about defining terms/methods and a place to find the specs for those. It is not meant for environmental/economic/ concerns – we shouldn’t be annotating specific DID Methods. I do appreciate what Markus said wrt. concrete change requests… if we convey that to them, they’ll be able to meet those requirements..

Drummond Reed: is there a baseline requirement or not? feels like mastercard registration request is forcing this issue… and we will have to apply this to all entries.

Justin Richer: +1 to drummond about there not being a choice but to address this.

See github issue did-spec-registries#382.

Michael Prorock: +1 text should reflect process.

Manu Sporny: couple points, markus makes a good point, we can refuse methods that don’t meet requirements…. but we have a lot of things to fix then..
… looks like we will need to address this…and we may need to extend past 30 days.

Daniel Burnett: the 30 day requirement is to avoid the case where nothing happened… its not to force a decision..

Manu Sporny: +1 to burn’s reading of what we decided..

Justin Richer: I want to push back against this notion that there is an unbiased technology, thats the entire purpose of having a gated registry… we are applying bias every time we do anything..
… I see a lot of well meaning and naive folks…. the WG signed up for this when we agreed to have a registry… we don’t need to “de-register”…. we can mark things as provisional….
… i am saying, we have solutions to these problems..

Manu Sporny: I think what the group is saying is that we don’t want to do /more/ value judgement than we’re already doing..

Manu Sporny: (although, that’s not coming across in the words people are saying).

Daniel Burnett: do we need to discuss anything else before we do to rubric?.

Manu Sporny: We need to get to issue 382 :).

Manu Sporny: We need a resolution for this.

Drummond Reed: Yes, we need to do that.

Orie Steele: I think I mostly agree with what Justin is saying – we are inherently biased, my bias is to minimize bias – I want the registry to just be terms and URLs and not spend a lot of time debating whether someone chose a good name for their DID Method..
… The extent to which they implement the normative requirements for the DID Specification, if we apply those rules unevenly, I’m not comfortable with being an Editor. I do have a bias, absolutely, regarding DID Core requirements, they need to be consistently applied. I’m not opposed to deregistering, and not allowing anything else if they don’t follow all mandatory requirements in DID Core..

Justin Richer: Orie: you are specifically asking for a lighter hand for this spec to avoid the did core requirements.
if we don’t cross t’s and dot i’s then it’s just a bunch of l’s and nobody knows what you’re saying.
hard disagree with Orie on this point: it is absolutely fair to start making things better now.
it’s bugfixing the process.

Michael Prorock: +1 orie - consistency is key here.

Orie Steele: We can’t get out of admitting some responsibility out of this registry – the requirements are subjectively applied – Editors don’t always agree, even if single objection, we won’t merge. Concretely speaking, Markus’ change suggestion raises the question on “what should we do with these other entries”. It’s not fair to this author to make changes for the registration process in flight. Or we have to admit we’re not being consistent. I’m fine w/.

Manu Sporny: saying “we’re not consistent”, but I won’t be an Editor if that’s going to be the WG’s approach..

Orie Steele: I want same rules to be applied to all methods. Or we can accept registrations that make good faith effort. Relax requirements, move value judgement elsewhere. My bias will be contributed to any work I participate in..

Markus Sabadello: we should not accept did methods that are not conformant… thats easy…. we should reject all did methods that are not conformant..
… we have to acknowledge that editors are not going to apply these rules consistently, and entries are not all fully conformant… if there is a “known issue” they they should not be accepted or they should be removed..

Justin Richer: +1 – we don’t keep making our old mistakes just because we made them in the past.

Markus Sabadello: we should remove entries that are not consistent.
… or that don’t meet the requirements.

Drummond Reed: Or we can use a Status label to differentiate between Provisional status and another status reflecting Conformant.
+1 to Markus’ point - this is why I’m saying we need to make a decision about issue 382.
This is also why I am suggesting the role of the self-assessment in this process..

Manu Sporny: I’m going to step away as an Editor for this document if we are going to say “DID Method Registrations MUST conform to all DID Method requirements”..

Ted Thibodeau Jr.: do we have a disclaimer on the registry, that basically says that users are expected to perform their own due diligence; the registry is just a helpful step on that road?.

Manu Sporny: I’m going to step away as an Editor for this document if we are going to say “We are going to unevenly apply registration criteria”..

Daniel Burnett: looks like no resolution will happen, but we should discuss.
… 382.

Orie Steele: To be clear, I am also considering resigning over how the WG is choosing to address this issue (382)..

Drummond Reed: the question comes down to are we going to make a conformance judgement here or not..
… can we introduce registration requirements for a “self assessment”… seems like a useful artifact that we can use to force the folks doing the registration work to make our jobs easier..
… if they don’t conform they are not registered..

Manu Sporny: the amount of work that is being suggested is not sustainable… checking a did method is conformant is more work than can be done.
… we will find even more exceptions and value judgments the more work we as editors to do.

Orie Steele: Concretely speaking, it sounds like we have two proposals on the table –.
… Proposal #1 is to accept this did:id method as-is and merge over objections that are asking for more specific objections to DID Core (override Markus).
… Proposal #2 – indeed, all registered DID Methods must be apply to DID Core normative requirements – analyze each of those methods for normative methods, yes, it’ll be a lot of work, but maybe folks want to do that sort of work?.
… As an Editor, I’m willing to apply principles consistently – but I expect no one will want to be an Editor once they see what kind of work that requires. We can wish something, but if we don’t have enough people to do the work, it’s not going to happen..

Drummond Reed: Agreed, Justin, we just need to decide about the process we will apply.

Ryan Grant: -1 to having Orie (and a coeditor) make these judgement without a lot more process set up..

Drummond Reed: We need to have a call dedicated to this topic..

Michael Prorock: +1 rgrant - this kind of thing would require a ton more process setup and definition as a group.

Orie Steele: This is also going to create a political issue, DID Methods being de-registered are going to be unhappy. I already know of a number of them that don’t meet the requirements..

Daniel Burnett: I strongly suggest we decide on the specific did:id method and leave the general rules for later so we can move forward.
… Virtually no registry on the planet mandates an update to prior entries upon a rules change. Let’s not go there. We can change our minds as we learn more.

Drummond Reed: We don’t have to “de-register”, we just need to apply a Status tag to registrations..

Daniel Burnett: thanks.

Drummond Reed: I will not be able to attend next week - on holiday.