DID Working Group Telco — Minutes

Date: 2020-05-05

See also the Agenda and the IRC Log

Attendees

Present: Daniel Burnett, Ivan Herman, Sumita T. Jonak, Amy Guy, Chris Winczewski, Dave Longley, Brett McDowell, identitiywoman, David Ezell, Phil Archer, Markus Sabadello, Eugeniu Rusu, Brent Zundel, Paul Madsen, Manu Sporny, Drummond Reed, Justin Richer, oliver terbu, Jonathan Holt, Joel Hartshorn, Orie Steele, Oliver Terbu, Dmitri Zagidulin, Thomas Schwarz, Kaliya Young, Kim Duffy, Daniel Buchner

Regrets:

Guests: Adrian Gropper

Chair: Daniel Burnett

Scribe(s): Dave Longley

Content:

1. Agenda Review, Introductions, Re-introductions

Jonathan Holt: I am a triple board certified physician, been at Stanford/Vanderbilt, and a healthcare/cybersecurity health. Been recruited to a subsidiary of Consensys. They are heavy into consensus and the ethereum platform. I’m deep in the projects for COVID-19.

Daniel Burnett: Next is the review of the agenda for today. Anything anyone wants to bring up on today’s call?

Manu Sporny: Are we going to discuss the next special topic call time/date?

Daniel Burnett: Yes.
… After the statuses.
… That will be at the end. In fact, we will make sure that that gets brought up.

2. Today’s call is a status check

Daniel Burnett: Today’s call is a status check.

Brent Zundel: We’ve been doing a lot of awesome stuff lately. Great conversations about resolution contracts and meta data, what should a DID identify, what should section 6 have, etc. This is a reminder of our timeline.

Brent Zundel: See our own timeline

Brent Zundel: If you follow the link – that’s our original timeline. The red circle says May 2020 feature freeze.
… This is probably not going to happen. But, this is a reminder, this is the point at which we wanted to have everything pretty much settled.
… We have a long process yet to go through with CRs and PRs and the whole W3C process. We have a lot of work that is underway that is left to do.
… The point of this call is to figure out what is left for us to do so we can more formally move forward, freezing features, refining the document, getting formal reviews.

Daniel Burnett: I think just a reminder of the pieces of the doc and what’s relevant would be good.
… When I go to a conference like IIW I think it’s good to say what we’re talking about again.

Brent Zundel: We need to get back to main topics, core contract, meta data, what else needs to be settled before we can move the main spec forward?
… Also, what’s going on with the DID registries.
… We also have an implementation guide (who will write it what goes in there?) and a use cases document (pretty much done?).
… We have a DID rubric we need to check in on.

3. Resolution Contract Conversation Status

Brent Zundel: This call is about all this.

tom s - usaa: Tom_S__-_USAA has joined #did

Markus Sabadello: Status of the resolution contract discussion is basically, I did the original PR about a month ago to add content related to DID resolution which was replaced with a new PR from Justin and others, and then Manu did a great job splitting that up into 4 different PRs.
… One that adds non-normative stuff to the architecture, that has already been merged.
… So we have some content on that now in the spec. The 3 remaining PRs that Manu created based on the original content from Justin, myself, and others. 263,264,265.

Manu Sporny: https://github.com/w3c/did-core/pull/263

Manu Sporny: https://github.com/w3c/did-core/pull/264

Manu Sporny: https://github.com/w3c/did-core/pull/265

Markus Sabadello: They are all about normative content. The first 263 is normative content about DID resolution. 264 is normative content about DID URL dereferencing. 265 is about normative content about meta data.
… They are still marked as draft PRs and personally I think they are going in the right direction. They have normative content about the nature of important outputs of resolving DIDs and dereferencing DID URLs, they express the abstract interface not the implementation which matches the expectation from the F2F.
… We have external references to the DID resolution spec without making those normative. Phil Archer has reminded us to be very careful there. Personally I think they are in good shape and may require a bit more review and back and forth.

Daniel Burnett: Ok, I will take Manu next but I wanted to ask next steps. Is there more discussion needed, do we just need to work on PRs, so on?

Manu Sporny: They are split up in a way that we need to focus on. They are in an order that I think we’d take them in. DID Resolution lays the basis, URL derefing is split from the meta data discussion. It seems there is some disagreement on URL dereferencing and its place on the spec and we’ll need to discuss that with Joe because he seems to have the strongest feelings.
… For the special topic call we need to figure out how we’re testing this stuff. Based on the resolutions the group made about charter interpretation. This allows us to test things more directly which is good.
… Part of the DID resolution call should probably be reviewing the existing test suite we have, how it was architected, and how we’ll do DID resolution tests. And once we do that how the language in the spec will support that.
… One of the concerns I had was that some of the statements would be difficult to test but some of the language in those PRs may change around the concreteness of what we’re testing.
… I wanted to take a bit of time and look at Markus’s PR because it had some good language.
… Understanding what we need to do with the test suite – and once we do that I think everything will fall into place.
… With the other PRs.

4. Metadata Conversation Status

Daniel Burnett: Ok, great. Moving onto next topic.

Markus Sabadello: Meta data is closely related to resolution and the three PRs we were just talking about. The last one is about meta data. That is covered by this work. I encourage everyone to review and rethink what it was that we took out of the meta data discussion. There was a different understanding of what “created” meant – DID subject created, DID document created, when it was resolved, so on – this is how we got to different buckets.
… That means some things in the spec would now be considered meta data – like created, updated, proof, etc.
… We may consider those to be meta data about the DID Document rather than core properties (about the DID subject).

Manu Sporny: +1, really like what Markus just said.

Dave Longley: +1

Justin Richer: +1 to everything Markus just said. Also to point out PR 265 really doesn’t define meta data properties so much as it defines a data structure to contain meta data. The thinking behind this was first we have a structure so that all meta data statements conform to it.
… Once we agree to it we can figure out which properties are meta data and what their property names and values look like.

Daniel Burnett: That’s a good reminder, we haven’t agreed on what is meta data or not, we have just been working on structure.

Justin Richer: Yes, this creates the buckets.
… Next we must decide what goes in them.

Drummond Reed: +1 to “creating the buckets” and then deciding what goes into them.

Daniel Burnett: So next steps?
… Just the review you asked for?

Markus Sabadello: Yes, and review the original issue that was discussed, #65.

Daniel Burnett: Ok.

5. Abstract Data Model Status

Justin Richer: https://github.com/w3c/did-core/issues/65

Daniel Burnett: Drummond can you give us an update on that?

Justin Richer: https://github.com/w3c/did-core/issues/203

Drummond Reed: That section is complete now, the PR made it through the Manu-filter.
… I don’t know of any outstanding action items directly related to defining and completing that section.

Daniel Burnett: I didn’t really ask you this, but could you talk about the front matter, this is the structure of the document and so on, I know a lot is in flux.

Drummond Reed: You bet. The one section with several outstanding bits is Section 3. I looked at what is currently in Section 1, the intro, and some things that are now in Section 4 which is conformance, and I recognized that a lot of that very early text that goes back 3.5 years now. We really need a clean approach to all the front matter, there’s duplication in some places, there are older things that don’t need to be in a mature spec such as positioning statements.

Manu Sporny: Agree with Drummond that we need significant Editorial rework to refactor the spec to make it easier to read… concerned about the timeline for doing so and getting horizontal review.

Drummond Reed: My suggestion is to do a clean up since it’s all editorial. So that it reads smoothly and as elegantly as we can with the introduction.
… That’s the general approach, and it will take time and I know that we want to get ready for horizontal review. I want to get feedback from the editors to see if we can substantially improve the front matter in one pass.
… So we can modernize that section and simplify it.

Amy Guy: I just wanted to say that I’ve had doing a pass through that whole section as an editorial for a while now so I’m happy to help with this.

Manu Sporny: Agree with drummond on all of those points, it’s the timing of those points that I’m concerned about. If we time box it and you can get through it this week and through next week I’m comfortable with that. If it drags on for 4 weeks that’s an issue for horizontal review.
… What do you think?

Drummond Reed: I can stop writing this email because that’s what I’m proposing. I want to get that done, my big chunk of time is over the weekend. I want to get it proposed and get feedback on the PRs next week. It’s all non-normative and editorial, it’s important, but it’s not the final pass just a substantial improvement. I want to be done with it by the end of next week.

Manu Sporny: +1 to that.

Drummond Reed: After review and everything.

Daniel Burnett: Ok.
… Do you need anything else, Drummond?

Drummond Reed: Nope.

6. Status of the spec

Daniel Burnett: The next item is status of the spec.
… After we’ve heard all of these different pieces – all parts of the spec that have to go in. Can you speak to overall status of the spec, Manu – horizontal review and next steps?

Manu Sporny: Yes. The spec is getting into good shape. I feel like a lot of the big big conflicts at least to this point have been resolved. We do still have 70 outstanding issues. I would think about 50 of those we will get to, just based on W3C history/how it goes, 20 we won’t.
… Overall, we’re in decent shape but behind schedule. We wanted to start going into CR now and we’re not there. Once Drummond gets this rewrite in that’s the last bit to get horizontal review. We should be able to get that out with the document in a state that’s acceptable for HR, and a way to get responses back before we go into CR. That’s good news.
… I am a bit concerned about a couple of issues like capability-based stuff that we haven’t necessarily talked about. There’s some registries stuff that we haven’t talked about that do impact the core spec. At a high level we’re in pretty decent shape. In the last week I was about to finally make a complete pass all the way through the spec and set down a good base layer. Nitpicky stuff like overflows, section alignments, etc. But the spec is now in a
… state where we can parallelize a lot of the changes to the spec.
… That should help Drummond and Amy because they have stable foundation, it helps the meta data/resolution stuff for the same reason and editorial processing, etc.
… If everyone rolled up their sleeves with the PRs assigned to them we could probably process 10-15 in parallel at this point. My expectation is that it will be 2-3 months before going into CR. That’s a significant delay. We still need a test suite, we need to dust that off and prep it for CR.
… But it feels doable.

Daniel Burnett: Consider Manu’s comments a motivation to work not be discouraged. The group has had a number of issues and disagreements to work through and that’s normal.
… It’s normal to work through them and I’m very pleased with the direction I’m seeing and the work that’s been done.
… The work tends to go faster once the major items are resolved.
… Thank you to Manu and the other editors.
… Anything to add before we move on?

Drummond Reed: No, I agree with Manu. We will get over the hump, I’m worried about little land mines in the issues and those may take some time and until we process those we won’t know how close we are to the finish line.

Orie Steele: I wanted to give an update on where we are in terms of properties that are documented and not documented. There are a couple of layers to comments on the registries.
… The first layer is on the editors side, we are close to covering most of the properties that have been floating around in DID core in DID core registries.
… Most properties there are documented now. Now the question is did we document them in the right place, what should be in DID core, in DID core extensions, somewhere else, etc. That’s worth having a deeper conversation there and how to get the separation of concerns right for interop there.
… Just as an implementer working on the tests, the process of adding properties to the registries is too heavy and I haven’t see any contribution to it.
… If we’re running late, I think we’re setting ourselves up for some pretty significant failure and there’s an opportunity to cut around the structure there and reduce the burden for getting things into the DID core registries. From a pragmatic technical note, I’ve asked around about this, I haven’t seen anyone shipping DID Documents that are JSON only or CBOR only.
… I understand the desire there but I worry as a developer we are specing things that no one is using.
… I’m eager to ensure that the DID core spec is usable for DID developers and I want to make sure we can do that.

Daniel Burnett: Now is definitely not the time to discuss that but I recognize your concern.
… I’m worried that the queue will grow here. But we do need time to focus on the issues you brought up.

Drummond Reed: +1 to special topic call on the registries.

Manu Sporny: One of the things that we should probably put on the agenda is focusing on the registries stuff because it’s very important work. We should have a special call on the registries because Orie has done fantastic job there and there’s little engagement from the WG and we need a call on that.

Daniel Buchner: Perhaps we can focus on registries after we purge all the random props from the Core spec

Daniel Buchner: Just a general aversion to the registries stuff. I understand extensibility is important to people. There are a bunch of properties in the spec that have zero description. While the doc has absolutely undefined terms it also doesn’t define important terms. The capability delegation stuff has no line of definition in the entire spec. There are recommended places for using them. I want to see those defined or purge them.
… If they can’t be defined I don’t understand why they are there.

Daniel Burnett: Ok, we don’t have time to go into that today, thank you. We need to talk about registries, that’s very clear.

Daniel Buchner: Move all undefined props to a registry of pending props

7. next topic call

Daniel Burnett: The next item on the agenda is the next topic call. Two parts to that: What should it be on? Is registries the next most pressing item.
… For others, btw, we normally have an editors call and we normally discuss this but we didn’t have a call because of IIW.
… Manu, is it registries?

Manu Sporny: Totally up to the group to decide. I think we could have a productive discussion around registries.

Daniel Burnett: Ok.

Brett McDowell: This might just be a newbie question… we just spent the call going over status of various deliverables, their dependencies, and how our roadmap is changing. Is this all documented in a single document somewhere?

Daniel Burnett: The next special topic call will be on registries, and it will be on Thursday. That’s an issue for some of you actually.
… The reason we were going to put it on Thursday is that there wouldn’t be enough notice to do it today, particularly unfair to those in NZ wouldn’t even know that they needed to be awake.

Orie Steele: this thursday is rough

Daniel Burnett: Who would not be able to attend on Thursday at 12 ET/9PT/6PM CE?

Amy Guy: tha’ts fine for me

Jonathan Holt: can’t

Dave Longley: -1 to thursday

Brett McDowell: I postulate that if the chairs wrote this all down in a single document it would have a magical impact on accelerating these deliverables getting done. I could shop that around for resources in my own company, for example. I can’t do much with this IRC chat log.

Daniel Burnett: There are a number of people I just happen to know are unavailable this Thursday this week.
… Chairs will discuss. It’s possible it will be next Tuesday.

Amy Guy: the late tuesday one would be less good :s

Daniel Burnett: We know we have to get onto those calls and but we’d be missing important people on Thursday.

8. Status of Notes: Imp Guide, Rubric, Use Cases

Daniel Burnett: Next, please be as brief as you can here. Phil?

Phil Archer: See latest

Phil Archer: Joe and I had been working on the Use Cases document you may/may not be aware that the latest version was actually pushed just at the end of last month.

Phil Archer: See Issues

Phil Archer: We think that the content is pretty much done except for the small matter of all the issues.
… Various people have been raising issues, Joe and I admit freely, a long time ago. Now we need to work through the issues, some issues transferred from the CCG. We will be working our way through it. Some we can take care of ourselves but we will ask for time to go through them on some of these calls.
… We will race through and try to get those issued knocked off.

Daniel Burnett: So the implementation guide is the last one. That has not been moving.
… I don’t know that we have an update on that.

Manu Sporny: https://w3c.github.io/did-imp-guide/

Manu Sporny: It has not been moving. That is correct. The implementation guide is where text goes to die right now. We don’t want to be in that position. We can say some very useful things about practical implementation considerations.
… The only thing it has in it are the JSON-LD extensibility sections from the DID core spec.
… There are many other things that we probably want to say in there but we need someone with the time to write those sections.
… The idea candidate is probably someone that is an implementer of some kind, has done multiple DID method implementations, what the considerations need to be when implementing. In short, that’s Orie, but he’s crazy overworked, we shouldn’t volunteer him.

Orie Steele: I am in favor of deleting things

Orie Steele: if it can’t be done well, it should not be done.

Manu Sporny: Up to him but we should have a fresh person on this. Someone who has time to talk about what people using DIDs should consider or what to consider when implementing a new DID method/what to consider when using DIDs in their architecture.
… We’re in danger of not shipping the implementation guide at this point. Not enough there and not enough time to fix it.

Daniel Burnett: The implementation guide is really important for the other things we’ve done. It’s the place for things that don’t belong in the spec but you need to know about.
… Please let the chairs know if you want to help there.

Markus Sabadello: There are some new things that should actually go into the implementation guide that are being proposed to go into the DID core spec. I’ve written some comments about that proposing that people contribute to the implementation guide.
… There are some candidate, concrete topics that should go in there.

Ivan Herman: I just want to understand what exactly the scope is or will be for the implementation guide. If I take one of the use cases, any of them, that describes the problem area and where a DID can be used, but if I want to see that not fully implemented but understand how the various features properties, registry items are used together to make an implementation of that use case, where would I find that?
… Is that the implementation guide or for those that want to implement a DID method?

Manu Sporny: The first thing you said is more correct. If we do it correctly the implementation guide tells you how to use DIDs to handle their use case. Step 1, step 2, step 3 for choosing DID method, choosing a resolver, doing create/update, all that stuff.
… We’ve called them primers in the past, but it’s more than that. If I want to implement by use case using DIDs here’s a document that tells me what to do/what other specs to look at. There should also be a section in the guide about what DID method implementers need.

Drummond Reed: +1 to having a separate section for method implementers.

Ivan Herman: All that you said is very useful. But I would expect it to go a bit deeper than that to understand what the spec is talking about. We need one or two examples: You want to prove/check this or that, these are the things you have to do.
… At least you have the feeling that these are the steps you use.

Daniel Buchner: Filed to start the discussion: https://github.com/w3c/did-core/issues/272

Ivan Herman: It’s very difficult to understand when you just read the spec .. how these things will work out in practice .. when you’re the user and you expect these things to happen. I understand that for the full use case you need to know about VCs or something, but so be it.

Markus Sabadello: E.g. this is one DID Core spec issue which in my opinion could be covered by a contribution to the Implementation Guide: https://github.com/w3c/did-core/issues/151 (“Include discussion of eIDAS levels-of-assurance”)

Daniel Burnett: There is a opportunity for those that wish to write informative articles, books, whatever to help in that way.
… There are things that only our group can do. There are things that others outside of our group can do. The things that only we can do are the things that Manu mentioned. Saying “this spec does not live in isolation, you need to know these other things to understand the spec.”
… Others can fill in and add value elsewhere.
… I see Kim volunteering.

Kim Duffy: Thinking about volunteering.

Drummond Reed: +++1 to Kim!!!

Kim Duffy: I’m thinking about it out loud. I’ve not been as involved in the group until recently, this might be a good forcing function and I’ve implemented a few DID methods. I’ll get back shortly.

Daniel Burnett: Thank you, Kim.
… That would be a big help.
… Anyone else that would help that would be incredibly valuable.
… I rushed us through the agenda. We specifically left off the normal issue review and triage. Are there any other major items that we’ve missed as far as the summary?
… I know, Phil, you need regular call time … if you wanted people to focus on one thing, what would it be?

Phil Archer: One of the things, “What does it mean for a DID to be recorded in a registry?” When the original use case document was written, all DIDs were recorded in a registry of some kind and now we’re saying, oh they don’t have to be. There are some terminology bits like relying party and so on need addressing. Use case docs set out the problem space, not the solution, but we don’t want to use a term in the use case doc that means something else in a spec.

Phil Archer: -> https://github.com/w3c/did-use-cases/issues/14

Phil Archer: Please think about issue 14.
… Joe and I can’t answer that, we need some input on that.

Manu Sporny: The other thing that we need to start prioritizing is test suite. So we can go into CR fairly comfortably and come out of CR in one piece. We need someone to lead the test suite effort. Andrew Jones is the person that wrote the DID test suite, the previous version 6-8 months ago.
… We need to bring that up to date, talk about the architecture, how we are testing resolution, all that stuff. We need to start having dedicated call time for that or special calls for it, something so we can put together a test suite and have implementers see how they do against the test suite.

Daniel Burnett: It sounds like one of these calls should be dedicated to getting the testing effort started.
… More than a few seconds of detail. That will be our opportunity to get people involved and then we’ll need to move it off to other calls.
… Everyone that does the testing work knows there’s a group that does that on their own and then they report back to the main group.
… Thank you, Manu.
… The chairs will schedule that in. Anything else for today?
… Thank you everyone! I really do mean that, we’ve made really good progress to get this point and we will see some really nice progress on issues because they stacked up on other major issues.
… Thanks again, talk with you next week!