Decentralized Identifier Working Group — Minutes

Date: 2024-07-18

See also the Agenda and the IRC Log

Attendees

Present: Daniel Burnett, Ivan Herman, Christopher Allen, tminard, Benjamin Young, Manu Sporny, Will Abramson, Kevin Dean, andres, Daniel Pape, Joe Andrieu, Ted Thibodeau Jr., David Lehn, Steve McCown, Jennie Meier

Regrets: Pierre-Antoine Champin, Kim Duffy

Guests:

Chair: Dan Burnett

Scribe(s): Benjamin Young, Manu Sporny

Content:

1. Agenda Review, Introductions.

Christopher Allen: Summertime!

Daniel Burnett: is there anyone here who has not introduced themselves in an earlier call?

Christopher Allen: technically, I haven’t introduced myself for this revised group.
… I’m founder and chairman of the Rebooting the Web of Trust group.
… and co-authored many specs.
… I currently run Blockchain Commons.
… focusing on “layer zero” of the stack.
… trying to get more higher reviewed code in Rust.

Daniel Burnett: I have a special announcement about the special topic call.
… is there anything else that needs adding to the agenda?

2. Special topic call: Time announcement.

Daniel Burnett: even if you have something to propose, we’ll likely put it on a future call to keep things focused.
… so, the special topic call time.
… we look for a time that can accommodate the most people possible.
… especially editors for the docs being discussed.
… The special topic call will be Wednesdays: 7am PT.

Christopher Allen: 0700 PDT until November.

Daniel Burnett: 10am ET.
… I’d like to ask that we keep that day and time reserved for these calls.
… we’ll use them as needed.
… any questions?

Ted Thibodeau Jr.: please add these to the W3C Calendar.

Daniel Burnett: can we schedule them, they will be.

Ted Thibodeau Jr.: could you put the pending ones in?
… that way I’ll keep it blocked out just in case.

Christopher Allen: (For me, not only it is really early PDT, but also conflicts with IETF CBOR meeting).

Daniel Burnett: sorry for the conflicts with other groups.

3. DID Registries.

Daniel Burnett: main topic is DID Registries.

Daniel Burnett: https://lists.w3.org/Archives/Public/public-did-wg/2024Jul/att-0016/2024_DID_Specification_Registries_v1.1_Roadmap.pdf.

See github issue did-spec-registries#565.

Daniel Burnett: https://github.com/w3c/did-spec-registries/.

Daniel Burnett: Manu will be giving the above presentation.
… and then we’ll open up the floor to discussion.

Manu Sporny: this one should be shorter than last time.
… DID specification registries is something we’re chartered to build.
… I’ll go over what it is by way of reminder.
… then point to what we need to discuss.
… The DID Spec Registries are official registries for the DID ecosystem.
… including: the registration process, the list of DID methods, property names and values, service types, etc.
… There are several formats that we support–which should be kept in mind.
… we also have metadata for DID URLs.
… as well as resolution.
… They contain quite a bit of material.
… The registration process gets asked about often.
… it does exist and we do follow it.

Christopher Allen: I can wait.

Daniel Burnett: let’s keep going and hold questions until the end.

Manu Sporny: we have a registration process, we follow it. We could change it…it’s a bit long in the tooth.
… we could modify, update, or remove some parts.
… there are 11 maintainers.
… we organized that group less than a year ago.
… our previous maintainers dropped out, I was the only one left, so we needed more editors.
… Thankfully, people stepped forward to participate.
… we asked for volunteers, we got some, we onboarded them.
… we had no objections to the volunteers.
… some are participants in the group, others are from the wider community who just care about DIDs.
… I continue to be the one to do the final merge after reviews are done.
… the reason we’re behind is because I’m behind. The volunteers have been great, very communicative.
… We’re very lucky to have this many participants.
… The 190+ DID methods can feel great to some and terrible to others.
… there are proposals for doing some cleanup.
… it’s not a free for all–even if it can look like it from such a long list.
… they’ve all met the minimum criteria.
… Let’s look through the DID Spec Registries note.
… Labeling needs improving.
… Property names includes several defined terms.
… linkedResource is something other people added, so that’s working for the community to extend.
… Verification Methods is being handled elsewhere, so that may come out.
… we have several properties related to Verification Method that we should also discuss.
… There’s also a Service Properties section we should reconsider.
… There’s another set of Verification Method types which also need reconsideration–some of it is ancient.
… and there are new values to add if Verification Methods stay in.
… Service Types is a growing list.
… Representation types will need discussion. Currently it’s JSON, JSON-LD, and CBOR.
… We also now have a DID Resolution spec, so we may want to refactor the DID Resolution Metadata contained in this registry note.
… DID Document Metadata comes back from the resolver, or it’s something the resolver can report back to the user.
… There are also parameters such as hl (hashlink), service, relativeRef, etc.
… and DID Methods.
… That list references the Registry and Contact info…however some of these are so old we don’t have contact information for them.
… Despite the size of the list, very few have had registration time issues.
… we can continue to garden this group note.
… we could also consider making it a W3C specification.
… and do we want to align things more closely with other groups, such as the VCWG?
… and do we add/remove categories.
… there’s also interest in raising the bar a bit for DID methods.
… the registration process generally works, but we can discuss if we want to add/remove requirements.
… anyone’s welcome to file issues.
… there are currently 40 open issues…some of which are very old.
… processing these would be a good place to start now that we have a WG to do that work.
… we also have pending registrations.
… some of them are nearly a year old and need to be merged.
… that’s the summary.

Daniel Burnett: admin content: bigbluehat is scribing today. Someday, it will be your turn.
… don’t panic. it’s not hard.
… watch what the scribe does.
… capture the essence of the conversation.
… it’s very important and I personally have referenced minutes from over 3 years ago.
… it’s very valuable to return to these logs.
… DID spec registries is currently pretty much an open discussion.
… the chairs are keen to understand what folks want to focus on.
… especially as we get close to TPAC in September.

Christopher Allen: there’s basically 3 maybe 4 things.
… I’d like to be able to list SSH keys–which is an IETF standard.
… it’s not always clear how to add those.
… same is probably also true for some existing optional items.
… I’m also concerned that if this gets tangled with the VC Controller Document, there might be some interesting challenges.
… the big politically hard one is the DID list itself.
… my suggestion is put a column to state status, put everyone in “provisional”, and give people time to validate that they’re still around, interested, and able.
… there is also a JSON-LD context out there. I don’t plan to use that, but other people need it, so do we maintain that? what else is out there like that which we also need to maintain?

Manu Sporny: couple responses.
… SSH keys could go in key types possibly.

Christopher Allen: so, that list isn’t up-to-date. What’s the status?

Manu Sporny: I agree. It comes down to who’s maintaining that content–it’s as up-to-date as they keep it.
… the SSH keys could have a place in that section though.
… the Controller Document could be put into the purview of this group. Chartering challenges, though, put it into the VCWG.
… but I think moving it now would cause a lot of churn.
… with not much reward.
… maybe eventually, but given the heavy overlap, I think it can stay in VCWG until a later rechartering date.
… concerning timeouts.
… We could put in a registration date and submitters could need to keep bumping their registration or robots would remove expired ones.
… creating a sort of natural timeout.

Joe Andrieu: there are two big rocks we need to request.
… abandonment and squatting.
… we also talked about test suites.
… and a complete proposal for some of these ideas from manu.
… the real gorilla, though, is name ownership.
… the DID spec doesn’t actually require that the name exist singularly in the registry.
… and that’s a tricky problem to solve now.

Christopher Allen: so, there was a forth question about other documents such as the JSON-LD context.
… is that part of the registry? are there other docs like that?
… also what are our refactoring limitations.

Manu Sporny: the JSON-LD context is maintained by the WG.
… it is not part of the registry per se.
… however, there are contexts associated with each property.
… so, previously, we’d decided that registrants needed to provide vocabularies and contexts with their registration.
… that was part of keeping the goal of decentralization.
… In the past that took a great deal of discussion time, so I’d rather not reopen that can of worms.
… there was also a question in the Zoom chat about the controller document.
… The VCWG’s controller document was asked for by a subset of participants who did not want to use DIDs, but did want to use the Controller Document approach but with other URLs.
… The Controller Document spec could layer into the future DID spec changes.
… The question of what goes into the registry is a big rock indeed.
… and one we should try to address.
… There are people now passive aggressively suggesting that we have a registry is proof that it’s not decentralized at all.
… there’s a more real concern that these registries were not meant to inhibit innovation.
… which is why the naming conflicts are allowed…though discouraged.
… At this point, there are many things in here worked on by others, and we include them here by design.
… but that’s concerning to some folks.

Daniel Burnett: I haven’t been able to follow things closely.
… but if we look at a W3C registry, there may be more than one registries.
… this document includes several registries.

Joe Andrieu: +1 for splitting the current registry into multiple resources.

Christopher Allen: I wanted to point people to the spec registries issue.
… my response there is more about the DID method name portion.
… but I was really hoping there’d be more ideas on that topic.
… there are lots of these suggestions.
… whatever your particular “thing” is, it’d be helpful to learn more about them.

Benjamin Young: .

Christopher Allen: that issue is currently the best place to chat.

Benjamin Young: We should pull that issue apart into multiple topics, there’s a growing list, cramming into that one issue might be difficult.

Manu Sporny: +1 to bigbluehat’s suggestion.
… we need to make a decision on if we’re keeping Verification Methods in the DID Registry or moving it to the VC Spec Registry.
… it’s arguable it should be in neither place…but in a Data Integrity Registry.
… that one sticks out like a sore thumb.
… DID resolution is another one.
… there are arguments for and against.
… we might want a DID methods reg, DID resolutions, and potentially a Data Integrity registry.
… that should give clearer lines around this document.
… concerning Joe’s suggestion to rename it to a “directory”.
… I didn’t originally think it was needed, but the ongoing sniping about the “centralization” that the word “registry” applies to some.
… using “directory” may clear the air.
… it’s useful to have this, but maybe there’s a way to alleviate that concern.
… I do have concerns about multiple documents.

Christopher Allen: +1 to a single GitHub repo.

Manu Sporny: but we could make that work with a single repo, perhaps.

Benjamin Young: +1 to single repo.

Manu Sporny: I’m still on the fence about the W3C registry process. I think it should be one, but we need a way to signal this is not a police file.
… It’s documentation to help implementers. We can say that in the doc and that should make it clearer.

Joe Andrieu: +1 to pretty much everything Manu said.
… I still like “directory”.
… but I do think we should use the W3C registry process.
… to be part of how that works and gets on its feet.
… I do think multiple registries would be helpful.

Manu Sporny: +1 to what JoeAndrieu said.

Christopher Allen: I’ve been calling these “provisional”.
… simply reserving the space.
… maybe call that one the directory.
… but then have a separate one that says “here is a registry of methods that pass some tests around the DID resolution spec”.
… we can say you can still work with whatever.
… but the onramp would be through the “provisional” spec (what we have now) and then into this test-based registry.
… then other groups could have their own registries.
… but to keep that entirely independent of the directory.

Manu Sporny: Note that we do have status info for each entry: https://github.com/w3c/did-spec-registries/blob/main/tooling/did-method-registry-entry.yml#L15-L21.

Daniel Burnett: there are different kinds of registries.
… some are first come; first served.

Manu Sporny: We don’t have “provisional”, but we do have “registered” (which means the same thing)… we also have “withdrawn” and “deprecated”.

Daniel Burnett: others require review.

Ivan Herman: we need to understand what the W3C registry gives us.
… I can’t say much about its value other than it comes with the W3C stamp on it.
… the registry policy has to be voted on by the AC.
… is this helpful or not?
… we should discuss.
… but I don’t take using the W3C process as a “given”.

Manu Sporny: a few things we may already have consensus around.
… splitting the registry into multiple docs.
… we do need to discuss whether to use the W3C process.
… deciding that may help with other concerns like the word “provisional”.
… many are easy search and replace.
… we just need to confirm consensus.
… we can put timeouts on the registrations easily.
… and if we go with the W3C registration process, it’ll just be more process–so we should discuss.

4. Up Next: DID Resolution.

Daniel Burnett: this is just the beginning.
… please feel free to file more issues.
… Markus is going to be presenting more background next week.
… This is the beginning, not the end. Please contribute.
… any final questions?
… ok. Thank you manu for presenting and bigbluehat for scribing.
… look forward to speaking with you all again soon!
… my pleasure. :).