Should there be a registry? Process to migrate to a W3C Registry?

[decentralgabe]

Please share your ideas.

[ChristopherA]

I would like to see that a method registry has multiple stages, of which the first as "provisional" is easiest to obtain, to the same standards as now: a) does not conflict with another method name, b) has one or more contacts, c)has publicly available a basic spec, and d) has a date this provisional expiration expires as inactive (I propose 2 years), but can be easily renewed. I believe the CCG can continue to maintain this.

Additional stages, would be managed by this working group at higher standard, and the first requirement is that they have a provisional registration. Additional requirements might the DID controller document meets some conformance testing, or another stage works with DID resolver conformance.

I don't know that these additional stages need to be formal "W3C Registries".

[jandrieu]

I'd prefer we call it a "Directory" but the new W3C process is probably the right direction for this work. I'm not convinced the W3C has "solved" how registries work, but we should opt-in and help make it work, IMO, rather than continue this as a NOTE.

The process section on Registry is https://www.w3.org/policies/process/20231103/#registries

[ChristopherA]

Should we refactor the different parts of this registry, in particular the DID method list, into different documents.

[ChristopherA]

Should the DID Resolution registry values be instead moved to the DID Resolution document?

[wip-abramson]

Echoing @iherman from the call yesterday, I am wondering what following the W3C registry process gets us.

I think @jandrieu makes a valid point, that it is a new process and trying to use it means we can help make it work for our needs.

However, I wonder about the optics given issue #567. This is not the official registry for DIDs. But might using the W3C formal process for registries give it a sense of being official?

[iherman]

However, I wonder about the optics given issue #567. This is not the official registry for DIDs. But might using the W3C formal process for registries give it a sense of being official?

I am afraid it may. Publishing a W3C registry means following an official process; whatever the content is, whatever the surrounding "story" is, it does convey the message of being very official.

[ChristopherA]

Are there others that agree with me that the DID Method Registry should have multiple stages? I have no problem with considering the higher stages having a more official process, but I have real reservations about submitting the bottom level "provisional" registration stage to a W3C official process.

[TallTed]

Are there others that agree with me that the DID Method Registry should have multiple stages?

We had the basis for multiple stages a while back. Consensus was that substantial additional work would be required to solidify the stage definitions, and add a lot to the administrative workload (at least, to keep track of transitions, especially on the back-end where the registrant might not be as responsive).

I have real reservations about submitting the bottom level "provisional" registration stage to a W3C official process

I believe the definitions of such stages (as with all aspects of a W3C registry definition) would be subject to normal W3C process rules, as these are considered closer to a REC-track than a NOTE-track document. As I understand things, handling stage transitions and such within the registries would not be subjected to the full W3C process. Which may relieve or intensify your reservations.

[ChristopherA]

For reference, this is the proposal that we discussed at TPAC 24 (slides starting at https://docs.google.com/presentation/d/1s6tf0VOKdIr3Gf_t7ROypyeg07Lk_myoOFby6AL4I7g/edit#slide=id.g477278097e_0_64 and meeting notes at https://www.w3.org/2024/09/23-did-minutes.html#t05 )

We continue to have the CCG volunteers maintain the base “method registry”,

• Primary goal to avoid name collisions
• Continue with minimal spec requirements.
• Have some simple policies to address current problems
• These will be considered “provisional” for period (1-½ years?)
• A new PR each period can renew “provisional” for another period, otherwise removed.

That the DID 1.1 WG maintain additional lists, possibly including:

• Some proof of implementation in code and any deployment status
• Conformance to the DID Resolution test suite
• Supports some minimal web-based API

These additional lists are not W3C registries, more like Notes, and are not required to “be” a DID.

[ChristopherA]

A key question that needs consensus before submitting an initial PR for a proposal to review is @jandrieu's about if the method registry should have as a "Primary goal to avoid name collisions".

#569

[jandrieu]

The directories should work like white pages. Multiple entries are fine. The point is not to exhaustively list the canonical methods, but rather to give people guidance about the did methods that the W3C has been informed about.

[pchampin]

This was discussed during the did meeting on 24 October 2024.

View the transcript

w3c/did-extensions#565

<ChristopherA> I just added w3c/did-extensions#582

ChristopherA: in issue 565, there is some recent discussion about TPAC slides and meeting notes.
… I want to note we didn't formally accept anything from the proposal.
… there was consensus to do some exploration.
… to recap: we want to avoid name collisions; simple spec requirements; we called them provisional, but we need a PR to renew provision.
… some proposal for an official w3c registry.
… Big thing missing: Joe's issue 569. We have a goal to avoid name collisions, but maybe that shouldn't be a requirement.
… Is there anything we want to firm up or get consensus on?
… any action items?

manu: we need to move this forward. most pressing: create a new view for DID methods.
… people say: too many DID methods. can we clean up abandoned ones?
… maybe say after a period of time, we need to see an implementation. No spec-only methods.
… perhaps we need to see a resolver that works? maybe a driver for universal resolver.

<JoeAndrieu> fyi, 200 methods today

manu: we need a higher bar on methods that we show?
… I am concerned about negative thoughts if our registry has different methods for the same DID method name.
… if we allow it, then maybe a duplicate method needs to have a concreate implementation. or at least more concrete than the previous method.

<Zakim> ChristopherA, you wanted to ask if we should just initially add one or more field to the method json.

ChristopherA: do we want to change this all at once? maybe just add a few field to method's JSON entry.
… if you don't update, we will remove your old method.

<Zakim> JoeAndrieu, you wanted to mention white pages semantics

JoeAndrieu: speak to better semantics: let's call it a white pages? no worries there about duplicates.
… I don't care about people who want centralized registries. we are all about decentralization.

KevinDean: +1 to Joe

<manu> Yes, Joe's arguments for why allowing multiple registrations do resonate with me.

<swcurran> -1 to Joe. We want decentralized identifiers primarily, decentralized DID methods secondarily

KevinDean: but it should be ok for developers of methods to not be production ready yet.

Wip: we should encourage method owners to start making implementations.

manu: I'd be fine if we add expiration date on method specs without an implementation

<swcurran> +1 for expiration. Could also have a second list in the registry of deprecated methods.

manu: we could do it automatically. give people six months to reply or submit something.
… maybe we sort results in registry by most recently updated
… but that might not get us to where we want to be.

<swcurran> +1 to manu

manu: let's propose adding expiration date.

<Zakim> ChristopherA, you wanted to ask "can get consensus to just add expiration date"?

<JoeAndrieu> registration/update?

ChristopherA: +1

ChristopherA: however, we need to address larger problem. people need to fix and update their specs.

ivan: we should say more about what update means. do they just have to change the date, or should be make substantial updates?

KevinDean: I am concerned about governance about this. managing expiration dates is out of scope of our group.

<Zakim> manu, you wanted to note that we can discuss that in another proposal :)

manu: unfortunately, we are well down that path.
… (managing dates)
… I tried to keep my draft proposal above to be simple incremental progress.
… does require more discussion.

Wip: let's talk about this next time.

<Zakim> ChristopherA, you wanted to answer Ivan

ChristopherA: two things: we have volunteers to deal with expiratin dates (CCG, manu)
… want to let ivan know that manu is proposing last updated date, not an expiration date.
… we can automate the filtering of the method list.

ivan: I'm not opposed to last updated. however, I'm uneasy about sticking in things without clear semantics.

KevinDean: I don't have problem with how things are today. But I'm worried about long-term. what happens years down the line if methods aren't updated?

---

[decentralgabe]

chair hat off

-1 to multiple methods attempting to use the same method name.

+1 to some sort of liveness test or expiration mechanism. It should not necessarily need to be engaging with the registry itself.