Meeting minutes
Agenda Review, Introductions
burn: 10 minutes of work item status updates, major topic splitting the DID spec registry.
DID Method Standardization Announcement
<decentralgabe> https://
APAC Meeting Time
decentralgabe: 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.
<burn> - Thursday 5-6 pm US Pacific Time
<burn> - Thursday 8-9 pm US Eastern Time
<burn> - Friday 0200-0300 Central European Time
<burn> - Friday 8-9 am Hong Kong
burn: We have chosen a meeting time and day that is more convenient for those in Asia.
<burn> The time in Asia will change by one hour when we go off of Daylight Savings Time.
burn: 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.
Reminder: Special topic call 7 Aug
burn: Our first special topic call is going to be August 7.
… It will be on the Abstract data model.
Work Item Status Updates
burn: We'd like each of the primary document editors to get on the queue.
manu: 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.
<Zakim> JoeAndrieu, you wanted to ask about process to start the DID Method Rubric registry transformation. What's the next step?
JoeAndrieu: 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.
burn: 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.
Splitting the DID Spec Registries
<markus_sabadello> Email and slides from last week's presentation about DID Resolution: https://
burn: Should have been called "What to do with the various registries" document.
… 25-30 minutes before I start pushing people to wrap up.
<manu> At first glance, splitting out every section into a separate registry document probably overkill. One possible organization is to split into 5 portions:
<manu> DID Properties (current §5: Property Names, §6 Property Values)
<manu> DID Representations (current §7: Representations, §8 Representation Specific Entries)
<manu> DID Metadata (current §12: DID Document Metadata, §13 Parameters)
manu: I want to start with Christopher's proposal, which I think was pretty solid.
<manu> DID Resolver (current §9: DID Resolution Options, §10: DID Resolution Metadata, §11: DID Dereferencing Metadata)
<manu> DID Methods (current §14)
manu: 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> w3c/
manu: 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> /TR/did-specifications/
manu: 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.
<Zakim> burn, you wanted to ask whether "did-registries" would be better than "did-specifications" and to confirm whether separate documents or just separate sections
burn: I'm just concerned that "DID specifications" for registries when there are already DID specifications will confuse people.
burn: Clarification: will we have separate documents vs. separate sections.
manu: 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
<Zakim> burn, you wanted to ask if anyone disagrees with the proposed approach?
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.
burn: Is there anyone who disagrees with that proposed approach?
<Zakim> JoeAndrieu, you wanted to ask about process
JoeAndrieu: 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.
decentralgabe: 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: +1 to that, Gabe. The proposal is to separate them.
<JoeAndrieu> +1 to separate methods from extensions
manu: 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.
burn: It's a nuisance to move things from one TR space to another after we started.
<manu> It is annoying to move things :)
<Zakim> JoeAndrieu, you wanted to support two namespaces
JoeAndrieu: I like the different namespaces. We have a different dynamic about name squatting between DID methods and DID extensions.
<burn> Personally, +1 to separate top-levels for methods and extensions
JoeAndrieu: 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.
burn: 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?
JoeAndrieu: Where are we going to iterate on the definition of these registries?
… I don't know where I should do it now.
burn: I don't have a strong opinion.
decentralgabe: Folder seems reasonable.
burn: Joe, do you need an answer before Manu submits the proposal?
JoeAndrieu: No, so I'll wait.
<Zakim> JoeAndrieu, you wanted to upgrade to authorizing two "registries"
burn: are we doing 2 registries or 5?
Wip: W3C registry path is a separate question. We want to split these up, but do we also want to follow the W3C process?
<manu> I agree with Will, I think it's orthogonal, too.
Lost connectivity. I can resume scribing.
<TallTed> Maybe change `using one directory/file per section` to `using one directory/file/namespace per section`?
<TallTed> Also note that each "W3C Registry" is *one* table, where these would seem to be one table per section
JoeAndrieu: Good point, Will. I don't want us to do this twice. We should follow the process before we start moving repos around.
<JoeAndrieu> +1 to TallTed
TallTed: Each W3C registry is one table, so this would seem to be one registry per section. I suggest changing "one directory/file" to "one directory/file/namespace".
<Zakim> burn, you wanted to opine on TR structure being important to define now
burn: 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: I wasn't clear if people wanted me to remove the "W3C registries" sentence.
<JoeAndrieu> +1 to keep it in
decentralgabe: 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.
burn: This is going beyond what we originally discussed, which was that we would leave that decision until later.
JoeAndrieu: Is there anyone that we know of that expressed concern that isn't here?
… It wasn't in the agenda.
<TallTed> "repositories will" -> "repositories are currently likely to"
decentralgabe: I don't think the proposal is considered adopted by the group until after the minutes are published.
burn: Yes, one week after minutes are published.
burn: Ted has proposed some additional wording change, want Manu to note that.
<JoeAndrieu> no concerns. thanks
burn: Joe, if you still have concerns, a week's notice might not be sufficient.
<manu> 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.
burn: 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?
<manu> PROPOSED: 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> +1
<TallTed> +1
<JoeAndrieu> +1
<Wip> +1
<markus_sabadello> +1
<decentralgabe> +1
<smccown> +1
burn: In IRC, +1/-1.
<KevinDean> +1
<danpape> +1
<JennieM> +1
<stephan> +1
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.
burn: I declare this to be resolved.
… Clearly that's not everything we need to discuss in respect to registries.
… On to Joe's question.
JoeAndrieu: 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> +1 to that path forward ^
<smccown> +1
manu: 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?
JoeAndrieu: One thing I think we should do is switch to a JSON preprocess loop to make it easier to fit into the HTML.
<manu> Good, that's what I was hoping Joe would say :) ^
JoeAndrieu: 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: 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.
<Zakim> JoeAndrieu, you wanted to bemoan evaluations
JoeAndrieu: 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.
<Zakim> decentralgabe, you wanted to clarify
JoeAndrieu: Once we start publishing evaluations, we may have political problems.
decentralgabe: I think something like the evolved version of the rubric is something we could have alongside DID methods.
JoeAndrieu: 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.
burn: We have these two primary documents. Please ping the chairs if you would like time to discuss something.
Next week: Issue and PR Processing
burn: 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.