DID Working Group Topic Call — Minutes

Date: 2021-11-04

See also the Agenda and the IRC Log

Attendees

Present: Drummond Reed, Manu Sporny, Brent Zundel, Orie Steele, Charles Lehner, Kristina Yasuda, Michael Prorock, Daniel Burnett, Adrian Gropper, Justin Richer

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Manu Sporny, Drummond Reed, Orie Steele

Content:

Brent Zundel: We have enough people today to have a discussion..

Drummond Reed: Sounds good..

Orie Steele: I have notified some other people to come to this meeting..

1. DID Spec Registries.

Brent Zundel: https://github.com/w3c/did-spec-registries/issues.

Brent Zundel: We are here to discuss Registries today.
… That can serve as framework for conversation.

Orie Steele: let’s to PRs first.

Brent Zundel: Ok, works for me..

2. PRs.

Orie Steele: I can take us through them..

Orie Steele: See https://github.com/w3c/did-spec-registries/pulls.

Orie Steele: Let’s look at open PRs, oldest to most recent..

2.1. Registering did:dnssec method (pr did-spec-registries#336)

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

Orie Steele: Oldest PR is did:dnssec - I have changes requested, does not conform to minimum requirements for DID Method, would be helpful if other folks would review that specific PR..

Manu Sporny: what I have been doing, is not reviewing PRs with change requests…. if they address your change request, I don’t review….

Orie Steele: .. happy to review, but agree with the current review..

Orie Steele: That’s probably ok given we don’t have a formal process that describes what we’re supposed to be doing (as multiple editors) – I like clear signals, bunch of changes signals more than just one..
… If it’s just me, maybe people don’t need to listen?.
… We should document it a bit better..

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

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

Manu Sporny: People should read change requests as – the Editors need it cleared for it to go in..

2.3. change registry columns per issue #83 (pr did-spec-registries#341)

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

Manu Sporny: One Editor has a problem, we all (Editors) have a problem with it – unless we specifically disagree in writing..

Orie Steele: This is open by ryan, attempts to remove provisional status. Manu requested changes, there is a merge conflict, it has been overtaken as you noted, we should close and continue discussion on more recent PRs..

Manu Sporny: +1 to that..

Orie Steele: MikeP - please request changes, might have approved before merge conflicts..

Michael Prorock: I will do that now..

2.4. update links to permalink context URLs and other minor editorial notes (pr did-spec-registries#346)

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

Orie Steele: This was open by Kyle, lots of change requests on it, they remain unaddressed, we don’t need to cover it – close pull request or make changes. Someone should ping Kyle..

2.5. Add PSI (did:psi) method specification (pr did-spec-registries#350)

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

Orie Steele: Police Science Institute Republic of Korea – multiple approvals, open for several days, this will cause merge conflicts… we are in the situation where we continue to take registry entries..
… Since we’re look at PR now, any objections to merging?.

Manu Sporny: No objections.

Orie Steele: merging..

Michael Prorock: as long as you cool with conflicts.

Brent Zundel: no objections.

Orie Steele: I didn’t review it, but Mike and Manu did – if there is an issue, we should talk about Editorial process..

2.6. Remove PROVISIONAL status from all DID method registrations (pr did-spec-registries#351)

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

Orie Steele: There were changes requested by Manu, other approvals..

Manu Sporny: seems like there is agreement to rename provisional, and address status of deprecated and withdrawn… seems the other PRs address the concerns better..
… lets focus on the other PRs..

Michael Prorock: The concern I have is what’s going on w/ overall approvals/objections – overall perspective formal objections… one issue is that really, the charter doesn’t support any sort of value assessment. Provisional was put in because we didn’t think people would take it as a value judgement..

Brent Zundel: provisional was inherited along with the registry from ccg.

Michael Prorock: Let’s get this in and then go from there. Let’s get public facing docs corrected, some of this stuff might take longer..

Kristina Yasuda: The main reason to keeping status, deactivated, can you have a separate section “withdrawn methods” or “active methods” – having that extra column seems like there is a value judgement, “we removed this”… I’ll make a comment in the PR, just a comment, MikeJ couldn’t make it to the call..

Michael Prorock: if #356 is an option, then great.

Brent Zundel: I think the FOs interpreted the provisional status as a value judgement, and then wondered why we weren’t making better ones.

Orie Steele: I removed from the q to try and give us more time to address other PRs.

Manu Sporny: I think we’re converging on what we’re doing in other PRs, data driven, let’s focus on those, don’t want a partial solution..

Kristina Yasuda: re Manu’s interpretation of the objectors, having “provisional” does give an impression of incomplete value judgement.

Drummond Reed: Yes, can we focus on other PRs – getting this done and updated, here is how the registration process is going to work – will make a difference w/ FO Council..

Kristina Yasuda: so removing “status” while keeping withdrawn etc, would help clarify where we are making value judgement and where we are not.

Brent Zundel: +1 kristina.

Orie Steele: Let’s move on to next PR.

2.7. Convert all DID Method entries to JSON files. (pr did-spec-registries#353)

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

Orie Steele: This is manu’s draft, PR 353..

Manu Sporny: PR 353 attempts to turn all the registry entries into JSON files.
… it changes everything into Orie’s YAML file format.
… it renames “Provisional” to “Registered” and retains “Deprecated” and “Withdrawn”.

Manu Sporny: https://github.com/w3c/did-spec-registries/pull/353/files#diff-c68755f9bc842d714659a770fdade9d566c926890c48f9448152b57d70f7b14d.

Manu Sporny: that’s an example of what a registration looks like..
… it allows for a description field.
… it breaks out name and email.
… and it has links to implementation, test suite, and other self-asserted info.
… this PR does not address any review of the DID method specification.
… the PR itself is just to change the overall composition of the table.
… the spec, the name, and the status are required; all others are optional.
… the purpose of this PR is just to redo the format of the current table.
… other PRs can then tackle the rendering challenge.

Orie Steele: Most of what Manu said, I agree with. This PR adds some new empty fields to every entry, it also duplicates registry entries if we were to merge it w/o additional requirements. My two primary objections – duplicates data w/o registration process, adds fields that don’t exist today..
… I did attempt to address in future PRs. We might want to talk about what content should look like… registration changes in one shot..

Kristina Yasuda: +1 Orie.

Orie Steele: if I got it to the point, we could merge it in one shot..

Drummond Reed: Is fastest thing to do to talk about convergence plan?.

Orie Steele: ^ yeah, lets look at my PR and then talk about differences.

Drummond Reed: Almost seems the same..

Manu Sporny: let’s just talk about the differences.
… my opinions become stronger if I have to build/maintain the system.
… my suggestion is to talk about the end-result and work backwards.
… let’s make sure we clarify what the final result is, then the editors can figure out how to accomplish it.
… for example, is there a status field or not.
… do we want to provide a description field?.
… do we or do we not make value judgments?.
… the mechanics matter only to the editors, but the fields we see matter to everyone.

Orie Steele: +1 manu.

Manu Sporny: my suggestion is that we go “top down”, deciding on what we want to show up, then let the editors tackle the tech details.

Orie Steele: I agree, my goal with these PRs was to have what folks see at the end of what people see w/o the word provisional in it..
… MikeJ’s PR accomplishes that goal as well – rendering the same information we have today w/o misleading value judgments in the table… don’t add any new fields, preserve existing talbe structure, rename provisional to registered – first thing is what folks should see is not the word provisional, existing registry entries w/ no additional changes..
… However, folks will need to see documentation on how to register a DID Method, it’s not how process was before – they will need instructions on how to add JSOn files – my PR covers those instructions. Those are also a requirement, to summarize – what folks should see is same information they see today w/o provisional showing up… they can read, update DID Method..

Orie Steele: I will not approve a PR that mixes adding new fields with removing provisional.

Drummond Reed: I understand, we’re merging two different perspectives – I hear Orie saying “let’s do this one thing for what people see in the table” – add new registration process – Manu saying “Do we want to add additional fields?” and there is a 4th decision – are we going to make any value judgement at all? My proposal is only one..

Orie Steele: +1 manu… either we keep the existing process and remove provisional…. or we update the process, document it, and remove provisional.

Drummond Reed: What do we want to see? Are we making any value judgement about specification? I’m still proposing baseline value judgement, if you want to call it that. Conformance judgement..

Kristina Yasuda: I think we agree not making any value judgement in the registry.
Kristina Yasuda: making a decision to include a DID method to a registry is different from making value judgments.

Manu Sporny: the issue I have with Orie’s PR is that it puts multiple issues together in one PR.
… if we just want to remove “Provisional”, then let’s just modify Mike’s PR.
… but the other stuff still remains.

Brent Zundel: +1 to pulling in Mike’s PR as a first step.

Kristina Yasuda: +1 to PRs per issue.

Manu Sporny: I’d rather talk about those in “clean PRs”.

Orie Steele: let see if we can get Mikes PR merged on the call then..

Manu Sporny: one that talks about the fields.

Charles Lehner: Removing withdrawn or deprecated entries might be considered as a separate change also.

Manu Sporny: a second one that renders that data.

Orie Steele: -1 to splitting generating and rendering… but also -1 to doing any of that until Mike’s PR is merged.

Manu Sporny: the third PR is specifically what are the new registration requirements.
… if we don’t do it that way, it’s going to be all tangled up in one PR that will take forever.
… so if we want to get rid of “Provisional”, we should merge Mike’s PR.

Brent Zundel: but those issues don’t retain the content.

Kristina Yasuda: If withdrawn and deprecated is not defined in the spec, Mike’s PR should be merged as-is.

Orie Steele: We have statuses – I do agree with Manu, changing the process and ability to retain registry entries is hard - in favor of merging Mike’s PR given that we have open issues to track what withdrawn/deprecated meant, so Mike’s PR is acceptable to merge. We haven’t lost any info, we can do so when we update process to how to handle deprecation, how to handle withdrawn. If it’s possible – we don’t want to commingle that issue..

Orie Steele: all status are not defined…
Orie Steele: all undefined status should be removed first…
Orie Steele: then defined. Orie Steele: then added back if wee can get agreement…

Kristina Yasuda: +1 Orie.

Drummond Reed: Sounds like we’re converging – to address what Kristina said – withdrawn/deprecated not defined in DID Spec, provisional wasn’t defined, status column exists, no official process – inherited from CCG..
… if we agree on that, would like to second manu’s proposal, 3 separate PRs… what is the data, how are we going to render it, what is the registration process?.
… That’s where we can tackle conformance judgement about spec or not..

Orie Steele: Comment on where we’re converging, let’s focus on Mike’s PR. Manu said he’d object to merging if we can’t preserve existing statuses..

Manu Sporny: I’m objecting that we should not just remove any registry information..
… the latest PRs still preserve that info.
… there is a reason that info is in the registry.
… so the issue I’m concerned about is deleting info without checking with the registrant.
… if we want to reach out to them, we might be able to make that decision.
… that’s the reason I wanting to keep it somewhere, such as a comment field.

Kristina Yasuda: I don’t agree with that. We have a valid, logical reason to remove and once we define the provisional, etc. we can re-add withdrawal etc..

Manu Sporny: so “change the status column to a Comments column” and then add those comments.

Justin Richer: -1.

Drummond Reed: I know Dave Huseby would send a torpedo – he was emphatic that status of did:git was withdrawn and he doesn’t want anyone to misinterpret that..
… We’d have a big issue there. I’d be surprised if that wasn’t the case. Let’s not lose that information, we’re going to end up replacing it with something, we just need to figure out how to go through this transition. Interested in Justin’s -1..

Kristina Yasuda: This will not set a bad precedent, valid logical reason to remove, not removing for the sake of removing. We could put a short note, do not use did:git – make sure Dave doesn’t have an issue – once we handle the definition of withdrawn and deprecated, we can always clarify that. Incremental approach, most logical approach, merge Mike’s PR as is..

Drummond Reed: IMHO the info about the Deprecated and Withdrawn methods can be retained in notes outside the table..

Kristina Yasuda: we can just add a text saying do NOT use did:github instead of labeling it “provisional”.

Brent Zundel: +1 to Drummond.

Justin Richer: The more you push a registry to just be free text, the more it becomes not like a registry – comment, read the bits, aspirational at best, disaster at worst… purpose of registry is get to code points that mean very specific things. That’s the main point of a registry..

Orie Steele: +1 justin, we ought not to fill the registry with fluff or undefined terms..

Justin Richer: It is purview of the registry to manage contents, it is up to registry maintainers to make the determination, make best effort to reach out to people – tell people you’re changing it… don’t dance around – I can’t change that text, it’s not mine – absurd, not taking control of data that this registry is meant to control..

Kristina Yasuda: +1 Justin.

Drummond Reed: I think it’s fine, I do agree with Justin, registry controls what’s there – maintain fidelity with what’s registered, status has never been fully defined, fine to move information that two methods have status information outside of table – get that done, can start on steps manu has started earlier..

Justin Richer: to be clear, I like a status column but with clearly defined values tied back to a spec definition.

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

Manu Sporny: Merge the PR, go ahead and get it done even though I object.

Orie Steele: Ok, merged..

Orie Steele: process.

Drummond Reed: Let’s agree on next agenda – process, conformance, not necessarily sequential… what can we get done between now and next call..

3. Process.

Orie Steele: we should focus on registration requirements that Editors will comply with – document what Editors will do in writing… that will impact fields that will be required to be submitted – don’t think we should start w/ shape of registry… behavior of Editors and what they’re going to be required to do..

Justin Richer: Do as much of this as we can: https://datatracker.ietf.org/doc/html/rfc8126.

Orie Steele: For example, my PR defines how a new method is registered: https://github.com/w3c/did-spec-registries/pull/356/files#diff-7eb74253de966f5a4176db7ca2d815a316da2b370c08ec7ad6137b7956d12c16R1.

Orie Steele: there is currently no written process..

Drummond Reed: While I understand that perspective, in the end the registry defines the needs of the market, how does registry best fulfill what it’s chartered to do together with … has to be a reasonable process. Orie has been point of that spear, knows what it will take… the process is not optimal for editors..

Manu Sporny: There is a written process :(.

Drummond Reed: I meant, one that we’d agree to going forward..

Orie Steele: not for reviewing did method registrations..

Manu Sporny: agreed..

Brent Zundel: We’ll come back around to this on the next call..