DID WG Telco — Minutes

Date: 2021-11-16

Attendees

Juan CaballeroPresent: Justin Richer, Ivan Herman, Daniel Burnett, Brent Zundel, Ted Thibodeau Jr., Manu Sporny, Ryan Grant, Dmitri Zagidulin, Drummond Reed, Adrian Gropper, Orie Steele, Juan Caballero, Pamela Dingle, Markus Sabadello, Kristina Yasuda, Charles Lehner

Regrets: Dave Longley

Guests:

Chair: Brent Zundel

Scribe(s): Justin Richer, Charles Lehner, Manu Sporny

Brent Zundel: agenda review: DID spec registry PR’s, DID spec registry issues.
… anything else?.

1. DID FO request from AC Forum.

Manu Sporny: See this recent request on the AC wrt. DID Core FOs.

Manu Sporny: recent email to AC form about formal objections.
… one of the objectors says the AC group isn’t getting anywhere with sustainability discussion re: proof of work; suggesting that DID WG deal with that.
… DID WG should recharter to include that.
… I don’t think there’s a clear message back to the AC forum around what this group thinks about working on DID method or more-decentralized methods than did:key and did:web or making “debating proof of work” a charter objective.
… could provide personal opinion, but we should get back to the AC.
… we need to give concrete guidance back about this direction from the AC.

Orie Steele: avoiding engaging on proof of work debate on AC list.
… don’t know what constructively will come from it, will echo what I said on charter.

Orie Steele: don’t think the next version of this WG should comment on proof of work at all.

juancaballero: +1.

Orie Steele: we have more important issues to focus on, like interoperability weak points.
… would love for folks to say the same thing, that this WG won’t debate proof of work.

Brent Zundel: +1.

Orie Steele: should come from multiple people.

Ryan Grant: +1 to not debating PoW.

Orie Steele: “we believe the WG should not use its charter to debate proof of work”.

Drummond Reed: agree with that; was wondering what manu was recommending in terms of action.
… looked at comment, this person is new, doesn’t know the context of AC discussion.
… manu, are you suggesting we designate someone to say “no”?.

Manu Sporny: two things, but first -.
… not engaging on mailing list results in things being thrust upon us that we don’t want.
… we need to be clear and consistent.

Orie Steele: say it here: https://github.com/w3c/did-wg-charter/issues/17, and link to it on the mailing list..

Drummond Reed: +1 to making sure we send a clear message on the AC mailing list.

Ted Thibodeau Jr.: “Perhaps the W3C should charter a specific PoW WG… “.

Manu Sporny: we need to say no each time someone brings it up.
… two things: we are not going to debate proof of work, we have other things to do, debates are happening elsewhere, we can cite the results when done.

Daniel Burnett: +1 TallTed.

Drummond Reed: +1 to that being a WG position.

Brent Zundel: +1.

Manu Sporny: second thing: group is trying to figure out what the right methods to standardize are, but are getting conflicting guidance from objectors.
… there is no solution we can propose to conflicting requirements.
… we need the formal objection resolved before we can form a path forward.
… by taking these positions, we put the work back on the formal objection process; we can’t make any decisions here b/c we’ll just be overruled.
… third thing (of 2): we need to propose something that should be reasonable.

Pamela Dingle: would like to see us officially acknowledge proof of work as orthogonal; this is meant to translate documents on any substrates.

Ivan Herman: +1 to pam.

Brent Zundel: +1, it’s not that it’s not worth our time, it’s that it is completely out of scope.

Pamela Dingle: should be acceptable to write a DID doc written on the wall in the blood of your enemies.
… as far as interop, we need to find our own way; we need these elements; implementors should have one unanchored implementation that works as soon as they install.

Ted Thibodeau Jr.: +1000 to offering that DID method for FO Panel & AC consideration!.

Drummond Reed: +1 to reinforcing that the specifics of ANY DID method are out-of-scope for the WG.

Pamela Dingle: don’t think we should let satisfying the objectors be the goals; should think about how we can make DID something the Web world can adopt.

Manu Sporny: I agree with everything Pam just said. :).

Ryan Grant: +1 to everything Pam said.

Orie Steele: +1 Pam.

Daniel Burnett: +1 Pam.

Drummond Reed: +1 that our goal should NOT be to let the objectors tell us what we need to do, but defend OUR view of what needs to be done.

Brent Zundel: having discussed it here is good, seeing where we agree; taking comments to mailing list is next step.
… or alternatively we could take proposals and make resolutions and link to the AC group.

Manu Sporny: unfortunately, may want to get it as a resolution in the group.
… going back to the AC empty handed isn’t good, it’s like “no we don’t want to do that”.
… vs “here’s what we feel is reasonable”.
… it’s going to take time to work through this; we believe standardizing did:key and did:web has merit; demonstrates all the features in did core; will work on those as notes.
… b/c it is not clear what the AC really wants at this point; w/o clear direction, that is what we think is a realistic goal.
… rechartered group is maintenance WG that will work on notes.

Brent Zundel: or maybe ccg work items?.

Manu Sporny: once it’s clear what’s in scope, we can do that.

Ivan Herman: worried about making formal resolution.
… this is not a formal request, it was just raised in a discussion.
… may be seen as overreacting; perfectly OK that someone or someones answer to the AC.
… OK to refer to the minutes of this meaning, which will be public.
… formal resolution has a weight which we should not do right now.
… another thing: I’m a little worried about rechartering; rechartering wakes up various parties; could say we could standardize methods if there’s agreement on what to standardize; leave it open, we could find none that people agree on..
… I realize this is an open ended charter that AC doesn’t always like, might need good english crafting to do that; be prepared to not force us into rechartering in 1/2 yr.

Ted Thibodeau Jr.: That mailing list may be informal discussion, and so not worth full engagement, but it is likely to feed into the formal discussion, and so be worth some response from us. I’m also wondering about how and when we (and how many of us) will be formally engaging in presentation to the FO Council..

Drummond Reed: I am a huge proponent of letting DID method authors drive their own standardization efforts and NOT make that the job of a rechartered DID WG.

Ryan Grant: looking at email, what’s the accusation? if we needed to respond, we should respond to specific accusation.
… “this cannot be sustainable or interoperable”.
… sustainable is the wrong goal if held in isolation, instead look to ethical web principles that conflict with each other.
… maybe we throw the request back and say there are problems with the request.

Drummond Reed: +1 to using this discussion as sufficient backing for responses on the AC list.

Manu Sporny: retract request to have formal anything, just point to the minutes.
… we have thoughts.
… ivan, about it being nebulous about future did methods: main charter will not be nebulous, it will be maintenance.
… one of the things we will look out is whether we can get W3C to come together to standardize methods; if we get there we can recharter to standardize those.

Ivan Herman: I’m almost where you say you are, manu – that’s fine. What I want to avoid is rechartering..
… What we have to realize, maintenance WG is a term that we use that is not a part of the process, this is a WG. I’d like to find a way to have “ok, it’s a maintenance WG that leaves it open wrt. whether a good target is found w/o rechartering” – not something we have to figure out right now. We should try to do that w/o saying we’ll recharter to do that..

Pamela Dingle: not sure if I want to throw a monkey wrench.
… one question, if we move to maintenance mode tomorrow, we end up with several specs that are still in draft mode; what are the paths for those documents?.

Manu Sporny: my expectation is that anything we publish would be maintained; don’t think we have anything except maybe registries that we intend to take any further than a note.
… when this group ends, we’ll have a req for did core and a couple of notes.
… what drafts are you concerned about?.

Pamela Dingle: status list $year spec, as an example.
… also did:web is a draft, no path to maturity for that.

Orie Steele: Pam, you appear to be referring to W3C CCG work items..

Drummond Reed: Right.

Orie Steele: those are not maintained by this WG..

Ivan Herman: there’s an issue if we move on to formal registries or not.
… no such thing as a maintenance group, only a WG that says what’s in scope.
… we are running ahead b/c I would be overly happy if all we need to find is what to do with the did charter….
… that’s not where we are.

Manu Sporny: those are CCG specifications (like statuslist), different group, different charter.
… we’d like to move did:web forward, can’t move it forward unless AC wants us to.

Dmitri Zagidulin: wait, why is did:web this group? That’s also ccg.

Manu Sporny: just because it’s not rec-track yet doesn’t mean we can’t work on it.
… just can’t put it in scope in charter.

Orie Steele: Note the “w3c-ccg”: https://github.com/w3c-ccg/did-method-web.

Orie Steele: neither are under this wg..

Pamela Dingle: Sorry to open Pandora’s box - I brought it up because the charter-per-spec administrative burden is something I think we all need to be thinking of from an industry perspective.

2. DID Registries PR review.

Brent Zundel: See https://github.com/w3c/did-spec-registries/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc.

Manu Sporny: all pull requests about changing format, new process, new process – all is in.
… build process has been fixed.

Brent Zundel: taking us through new and improved link.
… going to skip did method registration PRs.

Orie Steele: want to be clear about what editors are supposed to do against PRs vs old process.
… currently requesting changes, have discussed making changes manually for them.
… would suggest point people to the new process.
… need to handle it consistently.
… we get a lot of them every week.

Manu Sporny: want to make it easier for those that are already through, like did:id.

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

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

Manu Sporny: changes requested, what’s the status, how does it relate?.

Ryan Grant: status provisional column is solved; did we label old links? I don’t know.

Ted Thibodeau Jr.: https://github.com/w3c/did-spec-registries/pull/341#pullrequestreview-797802836 – overtaken by other events.

Manu Sporny: I think this PR is overtaken by events, no longer have a status column.
… that’s what the group agreed to, suggest we close this PR.

Ryan Grant: will close.

2.2. 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: I think this PR made a lot of changes all at once; changes have been requested for some time.
… PR seems dead to me, suggest it gets split up into smaller PRs.
… will comment on issue.

Manu Sporny: kyle said people are ready to re-review, but I broke things.
… feel like I agree w/orie, don’t know if this PR could really be … too much going on in this PR.
… all changes probably need to be made.
… would be OK with doing a re-review and get agreement to merge it.

2.3. Add implementation, conformance, and rubric fields for registration. (pr did-spec-registries#367)

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

Manu Sporny: meant to be a thought exercise about other fields; 3 new fields.
… one was implementation, one was conformance report, third was rubric evaluation.
… agreement that we don’t want rubric evaluation.
… link to conformance report is objective, passes or doesn’t.
… would like to see an array for implementations.
… two new fields are optional fields that can be filled out when people do a registration.

Orie Steele: don’t feel good about optional fields, any optional fields.
… of the fields proposed, I think implementations is most useful and other ones are less useful.
… question whether this is really the right place to add this information.
… did method spec, already a required URL, we could suggest that people add these links in their document.
… would rather see us have one URL and link out to other areas.

Justin Richer: -1 to having a linktree style URL as Orie suggests.

Ted Thibodeau Jr.: adding fields like this should be one per PR, they are vastly different.
… who gets to update it? if method author only, they get to bless what’s listed here.

Ryan Grant: +1 to not including blessed implementations in registry.

Ted Thibodeau Jr.: this feels like more of a registry thing than intended.

Pamela Dingle: +1 to the concerns about maintenance of implementations links over time in the registry.

Orie Steele: yes, I am concerned about these new “optional” fields..

Drummond Reed: I feel strongly that registrants should be maintaining their own links in the registry..

Manu Sporny: lumped them all together to generate discussion.
… there’s a lack of information in the registry; it’s useful to have information.
… v. concerned about an informational-only field; having a freeform way makes all information unstructured.
… hard to find information you’re looking for, everything’s formatted differently; linking to somewhere else, have no idea how it’s organized.
… would like to link to things that we expect will exist for production did methods.
… implementations will exist, conformance report will exist.
… can redo PR based on comments.

Orie Steele: should do those as separate PRs.
… other issues associated, like who gets to add implementation – how do you handle when someone tries to remove an implementation?.
… optional fields come with tremendous editorial process and potential abuse.
… editors know how to handle situations w/new fields.

Kristina Yasuda: we did agree not to make any value judgement in the registry.
… trying to address objectors confusion: don’t think this fields would help.
… would rather keep this simple, it’s just a registry, you make the decision.

Orie Steele: +1 to keeping the registry simple… do the work to make did methods great elsewhere..

Ryan Grant: not sure if rubric is intended to collect evaluations that refer to method by topic, but a good place to consider that feature.
… someone exploring did method could search for implementations w/evaluations on rubric.

Kristina Yasuda: rubric was an example.

Manu Sporny: will break these into separate PRs, expecting everything to fail.

Pamela Dingle: question becomes: who do we expect to be referencing the registry?.
… do we expect it to be end-users? verifiers? implementors of did methods?.

Dmitri Zagidulin: +1, mainly intended for implementors.

Pamela Dingle: my guess is the last, generally this is meant to namespace and ensure de-duplication.

Ryan Grant: +1 to say registry is for implementors.

Orie Steele: Who is this registry for: https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml ? :).

Drummond Reed: it’s a namespace, one we tried to avoid but had to establish it.
… W3C finally has a formal registry capability.
… what we should be looking at to become a formal registry.

Ivan Herman: all the details for registries are coming soon, this group is a guinea pig.
… once we have the new policy of maintaining the registry settled, all the rest will come after that.
… had a similar discussion with the rubric document.

Drummond Reed: Oh no! Another guinea pig!!!.

Manu Sporny: don’t want to guinea pig the group through candidate registry.

Drummond Reed: I suggest we put the Candidate Registry process discussion in a subsequent call.

2.4. Require that extension names are indicative of their function or nature (pr did-spec-registries#369)

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

Markus Sabadello: did:id sounds generic or universal, but in fact is central/universal.
… PR adds requirement that name of extension should give a hint to what it is.

Ted Thibodeau Jr.: +1 did:id is problematic, but we failed to ban it (and others like it). :-(.

Orie Steele: ^.

Markus Sabadello: eg property called “my_property” wouldn’t be indicative.

Manu Sporny: agree with intent, concerned that this is another value judgement.
… editors need to make a judgement.
… want to find a way to not register crazy properties but don’t want it ot be a value judgement.

Pamela Dingle: all you have to do is normatively define “crazy” and we’re fine.

Markus Sabadello: not a value judgement, it’s just a bad name regardless of whether it’s centralized or not.

Justin Richer: I have some experience being designated expert on IANA stuff, the Editors of this stuff need to be prepared to say “No” to people registering and sometimes that “No” needs to be “this isn’t a good name for the thing you’re doing” or “you haven’t specified this enough”.

Ted Thibodeau Jr.: did:shortname isn’t defined to require any meaning (and they should be treated as opaque), but english (and probably some other languages) have generic-looking strings that will imply things that aren’t accurate, such as more genericity, as in this case.

Brent Zundel: +1 TallTed.

Justin Richer: I had to turn something away recently, they had defined a CBOR thing, but it was a JSON thing, they had to spell out exactly what the data mapping was – this is the job of the designated experts… effectively “don’t pick a dumb name” is something that should be applied by designated Editors/experts of this registry..

Kristina Yasuda: +1 Justin to saying “no” to what does not make sense by the registry editors’ common sense and the understanding of the industry..

Ryan Grant: appreciate Justin’s perspective, wish we’d thought of this earlier.
… battle will be one when nobody looks at DIDs.

Dmitri Zagidulin: +1 ryan.

Brent Zundel: parting shots?.

Manu Sporny: what are we doing with this PR?.

Brent Zundel: as of now it’s ongoing.
… encourage continued chiming in.

Orie Steele: please use the “approve” or “request changes” feature of github when reviewing PRs..

3. AOB.

Brent Zundel: no meeting next week, US Thanksgiving week.
… 🦃.