Decentralized Identifier Working Group — Minutes

Date: 2024-08-01

See also the Agenda and the IRC Log

Attendees

Present: Daniel Burnett, Gabe Cohen, Ted Thibodeau Jr., Will Abramson, Kevin Dean, Benjamin Young, Markus Sabadello, Phil Archer, Manu Sporny, andres, Joe Andrieu, Daniel Pape, Jennie Meier, Steve McCown

Regrets:

Guests:

Chair: Dan Burnett

Scribe(s): Kevin Dean, Gabe Cohen

Content:

1. Agenda Review, Introductions.

Daniel Burnett: 10 minutes of work item status updates, major topic splitting the DID spec registry.

2. DID Method Standardization Announcement.

Gabe Cohen: https://blog.identity.foundation/decentralized-identity-leaders-partner-to-accelerate-did-method-standardization.

3. APAC Meeting Time.

Gabe Cohen: A number of us across different organizations have talked about a way to standardize DID methods. We have started a letter of intent that communicates this intent. Letter to be provided in chat including link to register interest in participating in this effort. More to come.

Daniel Burnett: - Thursday 5-6 pm US Pacific Time.

Daniel Burnett: - Thursday 8-9 pm US Eastern Time.

Daniel Burnett: - Friday 0200-0300 Central European Time.

Daniel Burnett: - Friday 8-9 am Hong Kong.

Daniel Burnett: We have chosen a meeting time and day that is more convenient for those in Asia.

Daniel Burnett: The time in Asia will change by one hour when we go off of Daylight Savings Time.

Daniel Burnett: All of these you are seeing are all the same time in different time zones.
… Anyone who doesn’t do Daylight Savings Time will notice an hour change.
… Not yet decided which weeks we will do this. We may do it the fourth and fifth Thursday, or only the fifth Thursday, yet to be decided.
… Once decided, it will be added to the W3C calendar, which will be updated automatically.

4. Reminder: Special topic call 7 Aug.

Daniel Burnett: Our first special topic call is going to be August 7.
… It will be on the Abstract data model.

5. Work Item Status Updates.

Daniel Burnett: We’d like each of the primary document editors to get on the queue.

Manu Sporny: For the DID Core specification, we’ve gone through and classified all issues as class 1, 2, or 3. Many have not yet been assigned.
… Not much to change until we’ve had further discussion.
… We do have some pull requests that I can’t process either because the submitter didn’t respond or they changed our recommendation document, things like that.
… Those PRs are probably not going to go anywhere and will be closed.
… For DID Spec Registries, the good news is that the volunteers and I have been able to process every open PR. Some new ones as of yesterday.
… Merged if acceptable, or requested changes if appropriate.
… There are a number of issues on DID Spec Registries that have not gone in the process yet, could use some help there. Will have discussion today.

Joe Andrieu: What do we need to do to get the DID Method Rubric transformation going?
… There are things we need to specify and we need a method to do so.

Daniel Burnett: Yes, let’s include that in the discussion about the DID Spec Registries.

Markus Sabadello: Regarding DID Resolution and DID URL Dereferencing, I sent an email to the list sharing the slides and created issues in the repository for what I considered major topics that the specification should cover.
… Four in total.
… What I would be most interested in is if the WG agrees with the scope and content and in particular with the topics at a high level.
… In general, want to know if this going in the right direction.
… I raised an issue on the DID Core Specification to move some to the DID Registries Specification.
… One thing I haven’t done yet is gone through the open issues on DID Resolution and categorize them but I’ve had a call with Christopher Allen who has offered to help.

6. Splitting the DID Spec Registries.

Markus Sabadello: Email and slides from last week’s presentation about DID Resolution: https://lists.w3.org/Archives/Public/public-did-wg/2024Jul/0033.html.

Daniel Burnett: Should have been called “What to do with the various registries” document.
… 25-30 minutes before I start pushing people to wrap up.

Manu Sporny: At first glance, splitting out every section into a separate registry document probably overkill. One possible organization is to split into 5 portions:.

Manu Sporny: DID Properties (current §5: Property Names, §6 Property Values).

Manu Sporny: DID Representations (current §7: Representations, §8 Representation Specific Entries).

Manu Sporny: DID Metadata (current §12: DID Document Metadata, §13 Parameters).

Manu Sporny: I want to start with Christopher’s proposal, which I think was pretty solid.

Manu Sporny: DID Resolver (current §9: DID Resolution Options, §10: DID Resolution Metadata, §11: DID Dereferencing Metadata).

Manu Sporny: DID Methods (current §14).

Manu Sporny: Christopher is saying why not take the current document and split into these sections.
… Each would become a separate document. Let’s keep the repository so we can track all the issues for these documents, create subdirectories to manage each of them.
… That would be the first major cut at an update. It feels fairly mechanical and easy to do that.

Manu Sporny: https://github.com/w3c/did-spec-registries/issues/568#issuecomment-2239510427.

Manu Sporny: I did in this comment suggest mechanically how we would do that.
… There are a couple of details we need to figure out, like where do we state what the process is, do we state it in every document. I suggest a top-level document that says we have these different parts and the process for registering in every one of them is the same.
… I’m wondering if we want to rename the technical report to DID specifications. This is a collection of different DID specifications broken down by category.

Manu Sporny: /TR/did-specifications/.

Manu Sporny: Pretty easy to do and redirect.
… The other thing, and maybe the controversial thing, I think it’s fine to run it under the W3C registry process. I don’t that’s an issue. However, I think we do need to clearly communicate that we are not the DID police, we’re not going to say what’s good and what’s not.
… I think some of the responses of some of the people outside the community about centralizing the registry shows that there’s a problem.
… People in this community know that’s not what we’re doing. We need to be clear that this is a set of specifications, not the end-all and be-all, we’re just providing documentation, whereas sometimes registries are used as enforcement mechanisms.
… I think we should strip the word “Registries” off of what we are doing.

Daniel Burnett: I’m just concerned that “DID specifications” for registries when there are already DID specifications will confuse people.
… Clarification: will we have separate documents vs. separate sections.

Manu Sporny: It is separate documents. I think we’ll have each one in TR space.
… Here is a central document that talks about all the extensions. Each directory will be about properties, extensions, etc.
… One place in TR, multiple documents underneath.
… I strongly argued against did-registries, we probably don’t want did-specifications. We could use did-extensions, but it also includes the stuff in did-core. Naming stuff is really difficult.

Markus Sabadello: I agree that if it’s called did-specifications it would be really confusing. I never felt that did-registries was too bad because we were always clear that registration was not mandatory. I like something about extensions.

Daniel Burnett: Is there anyone who disagrees with that proposed approach?

Joe Andrieu: My questions is related to DID Method Rubric. The first step in the writeup of the new registries stuff is that we get formal definitions that the group agrees to.

Gabe Cohen: Speaking as an individual, not a chair, I always thought it was a little confusing that methods were always co-located with properties.
… I see value in separating them.

Manu Sporny: +1 to that, Gabe. The proposal is to separate them.

Joe Andrieu: +1 to separate methods from extensions.

Manu Sporny: Responding to Joe, we have a table format that I agree we need to formalize.
… I think we also need to revisit and reformalize the process. There are some weird things we say from the early days that we may want to clarify.
… There are things that need to be cleaned up.
… I don’t know when the best time to do that would be.
… There’s an interesting proposal entirely to split out DID methods entirely from what we are discussing.
… The did-extensions document may include some of the material in the did-core document so we have to be careful.
… Interested to hear if we wholly want to separate DID methods and DID extensions.

Daniel Burnett: It’s a nuisance to move things from one TR space to another after we started.

Manu Sporny: It is annoying to move things :).

Joe Andrieu: I like the different namespaces. We have a different dynamic about name squatting between DID methods and DID extensions.

Daniel Burnett: Personally, +1 to separate top-levels for methods and extensions.

Joe Andrieu: Maybe a DID method needs to be conformant to be in the registry.
… We are the point of centralization, we just need to minimize it to the spec as much as possible.

Daniel Burnett: What I’m definitely not seeing is concerned. Manu, would you be willing to put together a draft proposal to get approval on a direction?

Joe Andrieu: Where are we going to iterate on the definition of these registries?
… I don’t know where I should do it now.

Daniel Burnett: I don’t have a strong opinion.

Gabe Cohen: Folder seems reasonable.

Daniel Burnett: Joe, do you need an answer before Manu submits the proposal?

Joe Andrieu: No, so I’ll wait.

Daniel Burnett: are we doing 2 registries or 5?

Will Abramson: W3C registry path is a separate question. We want to split these up, but do we also want to follow the W3C process?

Manu Sporny: I agree with Will, I think it’s orthogonal, too.

Kevin Dean: Lost connectivity. I can resume scribing.

Ted Thibodeau Jr.: Maybe change using one directory/file per section to using one directory/file/namespace per section?

Ted Thibodeau Jr.: Also note that each “W3C Registry” is one table, where these would seem to be one table per section.

Joe Andrieu: Good point, Will. I don’t want us to do this twice. We should follow the process before we start moving repos around.

Joe Andrieu: +1 to TallTed.

Ted Thibodeau Jr.: Each W3C registry is one table, so this would seem to be one registry per section. I suggest changing “one directory.

Daniel Burnett: I think what is important here is that we establish the structure. What goes into that particular structure, whether it is a W3C registries document, is up to us.
… Doing it properly now will have us a lot of work down the road.

Manu Sporny: I wasn’t clear if people wanted me to remove the “W3C registries” sentence.

Joe Andrieu: +1 to keep it in.

Gabe Cohen: I think it’s best to keep the registries bit for now and we could later determine if we want to issue another patch, but I would keep it.

Daniel Burnett: This is going beyond what we originally discussed, which was that we would leave that decision until later.

Joe Andrieu: Is there anyone that we know of that expressed concern that isn’t here?
… It wasn’t in the agenda.

Ted Thibodeau Jr.: “repositories will” -> “repositories are currently likely to”.

Gabe Cohen: I don’t think the proposal is considered adopted by the group until after the minutes are published.

Daniel Burnett: Yes, one week after minutes are published.
… Ted has proposed some additional wording change, want Manu to note that.

Joe Andrieu: no concerns. thanks.

Daniel Burnett: Joe, if you still have concerns, a week’s notice might not be sufficient.

Manu Sporny: DRAFT PROPOSAL: Split the did-spec-registries into two repositories: did-extensions and did-methods. Place DID Properties, DID Representations, DID Metadata, and DID Resolution into did-extensions using one directory/file/namespace per section. Place DID Methods into did-methods. The two repositories are likely to be managed as W3C Registries.

Daniel Burnett: I will note for the chairs, this is the first time that we are making contentful decisions. The chairs will send out a note pointing out that there were decisions made in the group that will be assumed to be agreed upon if no objections within a week.
… Any concerns with this draft proposal before we vote?

Proposed resolution: Split the did-spec-registries into two repositories: did-extensions and did-methods. Place DID Properties, DID Representations, DID Metadata, and DID Resolution into did-extensions using one directory/file/namespace per section. Place DID Methods into did-methods. The two repositories are likely to be managed as W3C Registries. (Manu Sporny)

Manu Sporny: +1.

Ted Thibodeau Jr.: +1.

Joe Andrieu: +1.

Will Abramson: +1.

Markus Sabadello: +1.

Gabe Cohen: +1.

Steve McCown: +1.

Daniel Burnett: In IRC, +1/-1.

Kevin Dean: +1.

Daniel Pape: +1.

Jennie Meier: +1.

stephan: +1.

Resolution #1: Split the did-spec-registries into two repositories: did-extensions and did-methods. Place DID Properties, DID Representations, DID Metadata, and DID Resolution into did-extensions using one directory/file/namespace per section. Place DID Methods into did-methods. The two repositories are likely to be managed as W3C Registries.

Daniel Burnett: I declare this to be resolved.
… Clearly that’s not everything we need to discuss in respect to registries.
… On to Joe’s question.

Joe Andrieu: What do I need to do next for the DID Method Rubric. I need to put forward a formal definition of the group to review.

Manu Sporny: +1 to that path forward ^.

Steve McCown: +1.

Manu Sporny: Joe, have you put thought into how the rubric is going to be managed over time? One mechanism we can use is that lots of different items can go in, I don’t know how people can propose them.
… I’m concerned that many will be proposed. Do we want it in one big document or lots of little pieces?

Joe Andrieu: One thing I think we should do is switch to a JSON preprocess loop to make it easier to fit into the HTML.

Manu Sporny: Good, that’s what I was hoping Joe would say :) ^.

Joe Andrieu: The rubric is structured by category. I’m not sure what you mean about people wanting to put things in there. Right now, it’s all about methods.
… Opening the aperture to discuss things like security suites may be interesting but a lot of work.

Manu Sporny: I don’t know how much exposition we want to do in the rubric document. I’m fine with us keeping it simple.
… I was wondering what goes with some of these rubrics. There are some evaluations, but I heard Gabe say that we will do them.

Joe Andrieu: Evaluations are one of the biggest flaws in the current rubric. What we found was that even though there were six of us in a room together, we ended up talking past each other.
… The current DID Method Rubric is dominated by the six methods that were top of mind at the time.
… Once we start publishing evaluations, we may have political problems.

Gabe Cohen: I think something like the evolved version of the rubric is something we could have alongside DID methods.

Joe Andrieu: My summary is that we have clear marching orders to come up with a formal definition. We have marching orders to move forward with DID method rubric.
… We need to kick it around some more.

Daniel Burnett: We have these two primary documents. Please ping the chairs if you would like time to discuss something.

7. Next week: Issue and PR Processing.

Daniel Burnett: We’re trying to predict what the topics will be for the upcoming weeks. It can change if there’s something really urgent. What we really want to do is get into regular issue and PR processing.
… What this means is that we will be asking the editors which of the issues and PRs will benefit from call time to discuss.
… The chairs will endeavour to have them sent out in the agenda, but that may not always happen.
… Keep an eye on issues and PRs.

8. Resolutions