DID WG Telco — Minutes

Date: 2021-11-09

See also the Agenda and the IRC Log


Present: Daniel Burnett, Ivan Herman, Justin Richer, Shigeya Suzuki, Brent Zundel, Dave Longley, Manu Sporny, Ted Thibodeau Jr., Drummond Reed, Michael Prorock, Ryan Grant, Juan Caballero, Adrian Gropper, Pamela Dingle



Chair: Daniel Burnett

Scribe(s): Dave Longley


1. Agenda Review, Introductions.

Daniel Burnett: So the agenda for today is actually much simpler than we’ve had in the past. We really want to just address this topic of DID method value judgment..
… It’s something that’s holding us up on moving forward on DID registries, that’s the main topic, there will be other quick updates before that. Any changes to the agenda?.

2. Special Topic Call.

Daniel Burnett: Let’s get right into the first update. This is on the special topic call..
… We do have time reserved later today at our special topic call time which is 6PM ET. If we need it. The intent is to spend our time on the DID registries value judgment topic. If we get into some other conversations and we don’t have time on that then we’ll have the special topic call, otherwise we won’t..
… If the group would still like to that have that call later we can for some reason, it’s there as a backup..

3. Media subtype suffixes at IETF 112.

Manu Sporny: As most of you know, we tried to register did+ld+json through IANA..
… They were like “we don’t know what those two plus signs mean, how should we interpret those”. The DID WG then created a draft for how you should interpret multiple suffixes..

Manu Sporny: Here’s the draft we prepared: https://datatracker.ietf.org/doc/html/draft-w3cdidwg-media-types-with-multiple-suffixes-01.

Manu Sporny: Amy and I worked on that and she put it together. They said “well, that’s great but we don’t have a WG to process it”. So they created a WG to process it and some other things..
… That WG met today and took up the question on accepting the draft..

Manu Sporny: Here’s the result of the poll: https://mailarchive.ietf.org/arch/msg/media-types/2DEvUeOYeqMrEKIdaO4A-djT_9Y/.

Manu Sporny: The result of the poll was that they like the draft at a high level, there’s some details to work out but 10 in favor, zero opposed..
… If there are no objections on the mailing list they will ask to make that a WG draft. I volunteers to be the editor, I’ll check with Amy to see if she has time, I don’t think we does..
… So there are now multiple ways to have suffixes. Some people wanted to be very specific about what suffixes meant and so on..
… If you want to go support on the media types mailing list that link will let you do that..

Daniel Burnett: Cool, hallelujah! This is a long time in the making..
… It will be interesting to see if there’s additional guidance on details..

Ivan Herman: is it in a state that we can add a work item on making these types normative into the new DID WG Charter?.

Manu Sporny: I think we already put that in DID core. We already said “This is the media type and it has two plus signs and we’ll register it whenever it becomes a thing at IANA”. So, in theory, we shouldn’t have to do anything with the DID core spec. Ie, we do say we’ll fix this in a future version: https://w3c.github.io/did-core/#application-did-ld-json.

Ivan Herman: You are right, I see that. That means that we can do the formal update of the spec in a new WG without further ado. Are the current application/did+json and application/did+ld+json not normative?.

Manu Sporny: application/did+json is normative, application/did+ld+json is not..

Ivan Herman: That’s not clear in the spec..

Manu Sporny: We do say it’s non-normative, but it’s a bit weird because the spec says we’ll be removing those sections at some point because they just have to do with IANA registration reminders..

Ivan Herman: Anyway, we are in good shape to finalize all that..

Daniel Burnett: Anything else on this topic?.
… Thank you..

4. DID Registry PR review as background.

Daniel Burnett: DID registry PR review as background. When Brent and I were discussing this, before we get into the key topic DID method value judgments, we thought it would be good to review the background on relevant PRs..
… I’d like someone to take us through that – Orie ideally..

Manu Sporny: I can..

Daniel Burnett: I don’t want to get into the discussion yet, just concrete examples for alternatives for understanding..

Manu Sporny: Understood, there are no alternatives now..

Drummond Reed: We are aligned on the way forward..

Manu Sporny: I think Orie and I are totally aligned. There’s no controversy anymore, we figured out a way to structure everything so that everything the group said was important to them last week and the way Orie and I wanted to process these things … we should be almost completely aligned and where we aren’t we can fix those up quickly..
… Maybe we can just go through those and then have a discussion..

Daniel Burnett: Alright, cool..

Manu Sporny: There can be controversy at the end when we discuss value judgments but the current set of PRs don’t get into that at all, they are just about what the group agreed to..

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

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

Manu Sporny: So, the first one that we’re talking about is PR #353..
… All this PR does is that it takes the existing table of DID methods and converts it into JSON. It doesn’t add new fields, it doesn’t add pointers to rubric or anything. It’s just the table we have right now converted to JSON. Shouldn’t be controversial..
… In the future, we can have other fields with links to rubric, examples, things like that – but that’s not in this PR..
… Any questions?.

Drummond Reed: No, that’s clear..

4.2. Add ReSpec plugin to generate DID Method table from JSON data. (pr did-spec-registries#357)

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

Manu Sporny: Seeing no one on the queue, the next PR is #357. This PR builds on the previous PR. It takes the JSON files and it just renders them with the same information that exists today in the thing that we have published. No new fields, doesn’t contemplate anything new, no value judgments, just a list of DID methods and contact info, etc. the things we already have in the table. Shouldn’t be controversial. It uses a respec extension to render the table instead of being static..

Drummond Reed: Very clear..

Manu Sporny: There’s an image of what the new rendering looks like..

Daniel Burnett: I have a feeling we may end up sliding into the value judgment discussion, so if there’s anything you want to hit before that please talk about those things..

Ryan Grant: What were the options for changing respec in this way and can we summarize the strategy taken?.

Manu Sporny: Two options: One was to depend on a command line tool to generate the HTML and commit to github, Orie implemented that last week. Option two was to use respec and pull the information from the JSON and render in full time. The end result is the exact same. The suggestion to do it through respec is to avoid junk getting generated as a part of change history..
… It also allows people to hack on display and rendering without having to install node.js tooling and run command line tools..

Ryan Grant: I agree that’s the better way to go. I’m having trouble understanding if I’m running local respec, I see common.js changing – these are local to the repository presumably, so anytime I have this repo, respec will automatically do the right thing or how do I pull those in and make sure I’m using the right respec stuff?.

Manu Sporny: Let’s talk about that offline. Basically, you shouldn’t have to deal with any of the node.js stuff. It should be as easy as load the file in your browser and modify common.js – if that doesn’t work something is broken..
… If all you want to do is mess with the rendering that should be it..

Ryan Grant: Right, it should work, it shouldn’t change anyone’s build process..

Manu Sporny: That’s right..

Ivan Herman: I have a project which is a bit similar to what you did, Manu. It’s producing testing reports for another WG where we expect to have a large number of tests. Those are expressed in JSON and then we do whatever you do as well..
… The experience I had when I was doing that was that it becomes a bit slow when you go to a page and you expect a result. It goes quite slow, I wonder if you have this problem..
… What I decided to do in the end was sort of the Orie way, I have a process that generates the necessary things and I use github actions to do this automatically and it even runs the respec stuff. So the user just sees the generated HTML..
… I wonder whether we can get through a timing issue like that..

Manu Sporny: So that was considered, it takes ~250ms to render the entire table, so the mechanism we have right now is fast..

Ivan Herman: Ok, good..

Manu Sporny: And it’s not expected to slow down as we get 200-500 more entries, etc..
… It should be just as fast..

Ivan Herman: Ok..

4.3. Add did method registration PR template (pr did-spec-registries#360)

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

Manu Sporny: Noting time, I’m going to keep going. The third one has to do with a registration template. We have to explain to people how to do it – before it was hack the HTML and now it’s edit a JSON file. The editors don’t want to have to tell people that they forget a quote mark or whatever, so Orie implemented validation..
… He also creates a new PR template that requires people registering to do the checks themselves so we don’t have to keep telling them these things..
… So before they even raise the PR they have to self-attest to those things. Once they submit the PR, Orie’s tooling runs and does a schema validation and the PR can’t be merged until the checks pass..
… So this has to do with making sure the editors don’t have to do extra test. Actually, I messed that up, I just explained two different PRs..
… PR #360 are only the instructions to the individual. PR #361 has the tooling..
… PR #360 – any concerns over having a registration template to fill out?.

Drummond Reed: It makes total sense. We don’t really have any option if we’re going to this form of doing it, we need clear instructions for registration..
… Do we run validation against what they submit to make sure it’s well formed?.

Manu Sporny: Yes, with a tiny caveat about something you care about – we’ll get to that..
… I suggest people look at the template..
… Ideally, it would be best if we merged all four of these PRs together, we don’t have to, but that’s the desire..

Ryan Grant: Thanks, I noticed that TallTed suggested that there should be a maximum time until registration, should we talk about that or should we wait for comments on that?.

Shigeya Suzuki: Looks good, and I will update my PR (#336).

Manu Sporny: This is a volunteer driven thing – and having a maximum time is … I don’t want to put the editors under that and we will do our best..
… Unless we get more people that will step up to agree to such a timeline I don’t want to force the editors to do that. Most of them are in the same position with being very busy..

Ivan Herman: We are talking about the tables for the DID method registration, right?.
… Or are we also we talking about various method data and parameters, etc..

Manu Sporny: Let’s try and scope the discussion to the former..

Ivan Herman: Will the same approach be used for the others?.

Manu Sporny: It’s a good question, we should have that as part of the discussion..

Ted Thibodeau Jr.: Max time might be a year. I’m not trying to pile anybody’s desk higher than it already is. We are saying it’s not going to be less than 7 days and saying a year is enough slack time for anybody..

Manu Sporny: I think saying a year sends the wrong message. I think 30 days is fine..

Drummond Reed: I agree that a year is too long. 30 days feels right..

Ted Thibodeau Jr.: Not saying anything seems like it takes forever..

Manu Sporny: I don’t think anything longer than 30 days..

Michael Prorock: +1 30 days.

Ted Thibodeau Jr.: 2 months is fine, not excessive but reasonable..

Manu Sporny: Anything else before we go to the last PR?.

4.4. Add registry ci tooling (pr did-spec-registries#361)

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

Manu Sporny: So this is the schema checking whenever someone is registering. This just makes sure the registration data is well formed. We also have a mechanism that rebuilds the list of all DID methods in JSON format. This is going back to Ryan’s previous question..

Drummond Reed: Good!.

Manu Sporny: You don’t have to run that tooling if you don’t want to. We’re going to run that as part of the github action, no one needs to run that to do development for rendering the table, etc. It’s not checked into github, it’s just part of the build process..
… That’s only kicked off if the validation checks pass. This makes the editors’ job easier..
… That’s all 4 of the PRs..

Drummond Reed: Tremendous progress. I’m in favor of merging all four..

Manu Sporny: I believe we’re aligned, at least Orie and I are – that it’s the right approach. We’d like to get these PRs in as soon as possible because we’re having to run beside all the new registrations right now..
… We don’t want to have to keep doing that..
… The intent is to merge these as soon as possible, so we typically wait 7 days and that means 5 more days until merge..

Dave Longley: +1 thanks to everyone for all the work.

Drummond Reed: IMHO, merging those PRs is completely orthogonal to any question of value judgments..

Ryan Grant: PR #361 looks really good for the editors but I’m confused when github is saying continuous integration is saying “no” – is there a way to add more documentation around what needs to be fixed so you can send it off to the editors?.

Manu Sporny: Yes, we can certainly do that, the problem is that there are multiple things that will start running. You can always click on “details” and it should tell you what failed. We can put that in a README and tell people to do that even though most people may not read that..
… More often than not, the editors have to tell people that their JSON file is not formatted well and they have to fix it, but +1 for documentation to help there..
… The real issue comes in when W3C tooling wasn’t working and people got confused and they didn’t know if it was them or not – and we had to tell them it would pass, etc..

Ivan Herman: One very specific thing from W3C, these things are important, do you check as part of your tooling whether the various URLs that appear are live or do they 404?.
… I see 404 links today..

Manu Sporny: That’s an excellent question, we should be doing that in time, we didn’t want to implement it right now. We just wanted to implement what people agreed to, we should talk about that as part of the discussion, we should talk about automated tooling that checks this stuff – there are some links that point at marketing now instead of a spec and that’s a problem..
… We should discuss that..

Daniel Burnett: At this point you’ve presented the 4 PRs and if anyone has concerns or objections please reply on those PRs – without objections they will be merged in 5 days..

Manu Sporny: Yes..

Drummond Reed: +1 to that process..

Daniel Burnett: Anything else related to that today?.
… There were a couple of topics you said, Manu..

Manu Sporny: This is the further discussion – whether we want value judgments and whatever else..
… We can move into that topic..

5. DID Method value judgments: yeah or nay.

Daniel Burnett: Yes, let’s do that. There’s a little bit of background on this as a reminder to the group. What we mean by value judgments and alternative positions on this topic..
… Could you summarize, Manu?.

Manu Sporny: The registration process today has the editors doing to the link provided for the spec and saying whether it’s “good enough”. We typically look to see that they’ve defined the DID syntax, that they’ve written something vaguely understandable on the CRUD operations and a sizable security/privacy section..
… We want there to be at least 3 bullet points, some paragraphs there – fundamentally we’re making a value judgment. There’s a question about whether we should be doing more, less, automating, removing these requirements, etc..
… Those are the kinds of value judgments we’re making today. There is also a suggestion that we should put other fields they should provide such as a link to an implementation, a link to a test suite, or test output for the DID test suite..
… Do you have a further test suite of your own – there are things that we can ask them – that aren’t value judgments and people can include it in their registration. There are two discussions there: 1. do we want to ask for more information? 2. do we want to make value judgments and if so, what is appropriate?.
… Today we some of those value judgments today and the editors don’t want to have to do that, if we can automate it that would be great and some people don’t want us to do it at all..

Daniel Burnett: There’s a desire for consistency – if we allow for value judgments how do we ensure that over time the editors can operate in a moderately consistent manner with those judgments..

Ryan Grant: +1 to automation. -1 to editor value judgments or requiring external certifications (although listing them is fine)..

Daniel Burnett: The title for this topic was a yay/nay on value judgments, it’s not necessarily binary. I’ll open it up for discussion now..

Drummond Reed: I’m a broken record on this… I’m going to leave off the topic of any other value judgment other than what I’ve been calling the baseline in all my comments. Basically the same level of editorial review – basic DID method spec conformance. Does it meet the requirements of section 8..
… It’s not a really high or arbitrary bar. As maintainers should be able to make this judgment. Orie has said all maintainers must sign off, I don’t think that should be required, I’d be happy with two..
… If we don’t set a bar for a baseline of quality for what it means to get into it – then we’re not doing a service for those people using the registry. It is a namespace, even though we don’t really like those, we do need to guide against bad entries for users..

Manu Sporny: I definitely hear that, Drummond. I will try to explain Orie’s viewpoint – I’m on the fence about it. I think he’s saying that if we’re going to keep making judgments, he thinks different editors might have different opinions, so he wants all three editors approving it..
… That way we’re raising the bar on being consistent on the evaluation..

Shigeya Suzuki: Note: If we want to have link to did core test results specific to a method, I need to find a way to create permanent link (currently it’s changing).

Manu Sporny: I think I agree with him but I don’t like the extra work on the editors. The people doing this are very busy and this is an expensive process. The counter argument is that hopefully we won’t get another 100 methods over the next year. I think the suggestion here is more than 1 editor..
… With section 8 there are a lot of MUST statements in there. I don’t try and check every single one of those – there are 20-30 of them, I definitely don’t do that level of checking. We would do that for a totally conforming thing – to say that this spec conforms to section 8 – I’d like to stay away from that until we have a way to automate it..

Pamela Dingle: How do we see this running in 10 years?.

Drummond Reed: I’m happy to, Pam, we could run it in 10 years exactly the same way we are running it today. I believe in 10 years we’ll have a low level of new registrations. We may have updates to specs..
… What I wanted to get back to was a simple proposal – to set the baseline is to say that 2 editors need to agree. If the two disagree then we need a third to break the tie. That keeps the bar as low as we can. That may address Orie’s issue that if two don’t agree you need a third to break the tie..
… Listening to Manu, to minimize the work on the editor’s part – this would be an independent process, it wouldn’t directly affect the registry, but a form of self-attestation, in addition to the spec you must fill out the form and say whether and how you meet the conditions in section 8. That would make it way easier – make the submitters have to say how they conform..
… There have been very new innovative ways of doing a DID method and it really helps to know how you’ve met the requirements..
… So give us the answers to the questions, it would make registration review much easier..

Manu Sporny: To try and wonder about 10 years, I think I agree with Drummond that we can run it the same way in 10 years. I want to automate everything. Remember W3C has tooling that automates the publishing process and it used to be very manual. We can push a lot of this work onto the DID spec authors – like you need to have anchors in your spec, you need two paragraphs here or there, that sort of thing..
… My hope is that, Pam, we automate all of this so it’s easy to maintain. Any new analysis that we want people to provide has tooling that does an automated check to make sure that they are self-attesting and two we’re doing a sanity check equivalent to what the editors are doing today..

Pamela Dingle: We’re creating state – in a spec that is otherwise stateless (not an attack, just a statement). Will we still have editors in 10 years? If the top five methods are there – will they have to start voting on new methods? What if they stop responding? This presupposes a level of long term support that is concerning to me. If automation will address that, great..

Justin Richer: I don’t believe automation will address any of Pam’s concern. I think an internet epic of 10 years – the concerns are very valid. IANA struggled with this for years before coming up with its current system, where the people that physically edit the registries and make the changes – those people are separate from the people who are deciding what should go in there..
… Because what happens if you can’t get a hold of all of the experts? I’m a designated expert on a number of IANA registries at this point in my career. There’s at least one registry where the designated expert has passed away. That kind of change needs to be accounted for..
… I’m hearing lots of hope and optimism and that’s good energy to take into this but there needs to be more realism for this for long term stability and maintenance. That’s the whole point of registries – it’s long term availability..
… For 6 months we can just point at a web page. This is for long term availability and consistency and that’s important..

Drummond Reed: I agree with Justin. All of this is predicated on having a set of folks that volunteer to continue as registry maintainers and the more we have the more the work is distributed. I expect a completely set of people in 10 years. If W3C is taking on registries I’m curious why we haven’t heard more formal action on it..
… We heard a details proposal two years ago at the TPAC meeting. We will need people to help maintain it if we can’t completely automate it..
… AI is amazing..

Daniel Burnett: I think it would be quite valuable to address Pam and Justin’s concern – if we add a process if the number of editors drops below a certain number..
… It’s reasonable to do that in any organization – in another case we talked about what happens if you fall below a certain number where you can’t get a majority, etc..
… At 10 minutes to the hour I wanted us to talk next steps and here we are..
… Do we need to continue this at the special topic call time?.

Ryan Grant: I wanted to say that we’re reopening the question of quality control in the DID method world. This is supposed to be an open environment, the registry is not supposed to tell people what a good DID method is – I’d like Justin and Drummond to keep that in mind when we talk about automation..
… We’re talking about a few fields filed out in JSON, we shouldn’t be grading for quality..
… Maybe Manu has other ideas on what to automate – like in a security section in spec that might need more work. I’d like people to keep in mind that we still have a Rubric and Rubric-evaluators can go click links and read more about DID methods there..
… We aren’t trying to satisfy formal objectors that think some DID method has a lot of junk – we want more decentralization and we want to be better at preventing editors or anyone else from censorin judgments..

Manu Sporny: W3C Registry Process 2021: https://www.w3.org/2021/Process-20211102/#registries.

Manu Sporny: To answer Drummond quickly there’s a new W3C registry process and we could take that route to maybe address some concerns..
… I suggest we’ve made enough progress today. We can merge down after the 7 day period and nothing bad will happen for the next month or two – the only reason to meet would be to talk about the other fields that we want to include in the registration, like pointer to the rubric, pointer to example DID doc, so forth. I suggest we just use next week’s call for that..

Daniel Burnett: Thank you..
… I will go ahead and say no special topic call today, I agree that we’ve been able to use most of the call on this area..

Drummond Reed: Just to make this point, in case we run out of time, the “quality” I’m proposing is a basic test of conformance of the submitted DID method specification to our Section 8 requirements. That’s it. Anything else about the “quality” of the DID method should be handled by Rubric-based evaluations. Which is why having a field for pointing to them would be so helpful..

Daniel Burnett: With that, keep in mind that we have a few minutes left, two people on the queue, be brief..

Ivan Herman: To connect some dots, W3C has a formal process now for registries – I connect this to what Justin said, which I like very much which, ie, to separate the experts who decide and those who do the mechanical work. Because the registries become part of the W3C work will hopefully use a team that will still exist in 10 years, they can make the additions provided that the experts say what to do..
… Just like the team may update RECs that are 10-15 years old provided that the experts say what has to be done..
… Going with the model that Justin described with this registry from day 1 would probably be a good idea..

Drummond Reed: +1 to that, I didn’t know that process had been put in place. I suggest we all take the action item to read through that and understand the wisdom of Ivan’s suggestion. I typed already what I think is to Ryan’s point – you can say it’s a value judgment to say if something conforms to the spec or not, maybe we can automate it – do you have the things required in the spec..

Ryan Grant: drummond: I agree, we could ask for links into the exact section.

Drummond Reed: Yes, you can put in mush and the machine can’t tell if it’s useful..
… That’s the only thing but that’s why I think we should include a field that’s a pointer to evals done for the rubric, that’s where we should be pointing people and encouraging people to have those evals done and make it easy for DID methods to be eval’d..
… Let’s keep the namespace as clean as possible and keep junk out to the greatest extent possible..

Daniel Burnett: Thanks, Drummond..

Drummond Reed: Huge thanks to Dave for scribing..