w3c
Add did:tdw, did:keys, did:svc, and did:proof plus DID Categories (13x) (Trusted Digital Web / Web 7.0). Remove bluetoque*.json (4x)
----- DID METHOD REGISTRATION FORM: DELETE EVERYTHING ABOVE THIS LINE ------
DID Method Registration
As a DID method registrant, I have ensured that my DID method registration complies with the following statements:
- [ x] The DID Method specification defines the DID Method Syntax.
- [ x] The DID Method specification defines the Create, Read, Update, and Deactivate DID Method Operations.
- [ x] The DID Method specification contains a Security Considerations section.
- [ x] The DID Method specification contains a Privacy Considerations section.
- [ x] The JSON file I am submitting has passed all automated validation tests below.
- [ x] The JSON file contains a
contactEmailaddress [OPTIONAL]. - [ x] The JSON file contains a
verifiableDataRegistryentry [OPTIONAL].
In his last Zoom call, @swcurran and I agreed that, to avoid confusion for the next several months, Web 7.0 Ultraweb/Trusted Digital Web (TDW) would postpone using did:tdw until Dec. 1, 2025.
Reference: Nov. 21, 2024 DIF Call: Timecode 20:00 in https://us02web.zoom.us/rec/share/UsNpfqags9z3oprz-DbXQZQX-xPEnJlBZhTn8AWfY-35hNdFkBk9QJQfVKXmU867.mbd57z9owlBoP-oi
UPDATE: Related, I've proposed a future solution to the "attestation of unique DID Method names" problem here: https://github.com/w3c/did-extensions/issues/597
your specification links return a 404 error
Copy and paste error. Fixed. Thank you.
DID methods are NOT meant to be used to identify certain types or classes of subjects. This can be done in DID documents or (better) in Verifiable Credentials or other places.
@peacekeeper Can you provide a specific reference or link for your above assertion?
DID Methods are a classification or naming convention for grouping and naming related subjects together as flat collections or as hierarchical-structured collections:
did:svc:1234
did:svc:dns:5678
did:svc:authentication:basic:abcdefg
[DID CORE] A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID.
Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID. In contrast to typical, federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities
[DID CORE] Anything can be a DID subject: person, group, organization, physical thing, digital thing, logical thing, etc.
DID subject The entity identified by a DID and described by a DID document. Anything can be a DID subject: person, group, organization, physical thing, digital thing, logical thing, etc.
I believe it is outside the pervue of the W3C to mandate how software architects/developers can or should use DID Methods from the perspective of being a naming convention for every little thing (ELT) on the planet. This is established in the opening paragraphs of the [DID CORE] (see above).
Anything can be a DID subject
Yes, but this doesn't mean that DID method names should be used to identify certain types or classes of subjects. I'm not aware of any DID method today which does this.
DID Methods are a classification or naming convention for grouping and naming related subjects together
No they are not.
Can you provide a specific reference or link
https://www.w3.org/TR/did-core/#methods
A DID method defines how implementers can realize the features described by this specification.
In addition to defining a specific DID scheme, a DID method specification also defines the mechanisms for creating, resolving, updating, and deactivating DIDs and DID documents using a specific type of verifiable data registry.
https://www.w3.org/TR/did-extensions/#the-registration-process
Any method name SHOULD avoid generic terms such as "mymethod" or "registry".
This approach would also violate rule 1 in https://www.w3.org/TR/did-core/#method-syntax:
A DID method specification MUST define exactly one method-specific DID scheme that is identified by exactly one method name
In my opinion this would still apply if e.g. the same document was copied&pasted multiple times, and if there was no technical difference between the copies.
Also, it's not clear to me what the verifiable data registry would be in this case? The specification seems to show abstract API interfaces that can be called, but there is no information about how the DID is created/resolved/etc. in the verifiable data registry?
@peacekeeper There needs to be provision and protection for public DID Method names as well as internal/private DID Method names.
svc, keys, and proof are internal DID Method names that need to be protected. did:object is the public facing DID Method name.
I guess I can create 3 stub specs that contain a single link to the common spec. Absurd as this sounds, here it comes...
@peacekeeper
this doesn't mean that DID method names should be used to identify certain types or classes of subjects
Again, an assertion with no justification/no backup Markus.
I'm not aware of any DID method today which does this.
This is irrelevant to the current discussion.
https://www.w3.org/TR/did-core/#methods
A DID method defines how implementers can realize the features described by this specification.
In addition to defining a specific DID scheme, a DID method specification also defines the mechanisms for creating, resolving, updating, and deactivating DIDs and DID documents using a specific type of verifiable data registry.
https://www.w3.org/TR/did-extensions/#the-registration-process
Any method name SHOULD avoid generic terms such as "mymethod" or "registry".
My DID Method registry applications meet all of the criteria.
there is no information about how the DID is created/resolved/etc. in the verifiable data registry?
@peacekeeper Again, do you have a link where this requirement stated?
I have a large number of previously approved registrations and they all use the same text. The elaboration of DID Specifcations is being handled by the DIF did-methods working group. I look forward to seeing that that WG produces. These registrations are solely for the purpose of registration - that's all.
As an aside, all Web 7.0 Sharded DID Registry hosted methods are implemented the same way at both the logical architecture and physical deployment layers of the Web 7.0 decentralized operating system architecture. One single specification will be needed to describe these 2 layers - but this latter specification is not required for registration.
(Hopefully) lastly, the Web 7.0 Sharded DID Registry supports a DID CORE compliant data model - that's the most important requirement as one starts this journey.
Again, do you have a link where this requirement stated?
I already provided the relevant links and references in an earlier comment. Your specifications do NOT meet the requirements. Please see the section of DID Core that defines requirements for DID methods.
all Web 7.0 Sharded DID Registry hosted methods are implemented the same way at both the logical architecture and physical deployment layers
One single specification will be needed
In this case, I would really urge you to just register a single DID method. If you really want to use the identifier itself to identify specific classes or types of subjects - which I think is not a good idea - consider using the method-specific identifier for these sub-divisions, e.g.:
did:web7:religion:1234
did:web7:philosophy:1234
....
We've been designing the Web 7.0 DOS based on what we think is best based on several decades of experience working for some of the largest software organizations on the planet, actual app developer feedback, and living through the births and maturation of BSD Unix, AIX, Thoth, Port, Linux, every version of Windows, Groove, SharePoint, .NET, Java, ARPANET, Internet, Browser Wars, and Web 1/2/3. ...and we'll continue to do so based on this legacy of experience.
... Any method name SHOULD avoid generic terms such as "mymethod" or "registry".
My DID Method registry applications meet all of the criteria.
Do you think 'religion', 'geography', 'history' and many others aren't generic enough to meet this criteria?
I agree with @peacekeeper's proposed solution to achieve a classification using method-specific identifier rather than using the method name itself.
It is good to push to make specifications as clear as possible and remove any ambiguity on them. But sometimes we just need to use common sense. And unfortunately it's hard to put that common sense into words.
SDOs need to do their work (develop and publish standards) and then get out of the way - no running interference.
That is, follow the Open To Innovation principle: https://hyperonomy.com/2019/03/12/internet-protocols-and-standards-not-only-need-to-be-open-but-more-importantly-open-to-innovation/
RE: Any method name SHOULD avoid generic terms such as "mymethod" or "registry".
Do you think 'religion', 'geography', 'history' and many others aren't generic enough to meet this criteria?
@genaris SHOULD avoid is not a requirement.
I object to the registration of did:tdw as this will cause confusion with the did:tdw method that is now known as did:webvh.
I will withhold further comment on the rest of these registrations which are quite clearly a bad idea.
@brianorwhatever Two wrongs don't make it right.
W3C has no basis for interfering with my rights as the trademark holder. @swcurran and I made an arrangement documented at the top of this thread.
@brianorwhatever what is your stake in this issue? ...any further grievances? @swcurran and I resolved this issue weeks ago: https://github.com/w3c/did-extensions/pull/603#issuecomment-2504713612
an arrangement
Actually I remember that arrangement differently than it is expressed in this thread.
Actually I remember that arrangement differently than it is expressed in this thread.
@peacekeeper What is your evidence?
Please don't make assertions based on what someone does or does not remember - the truth is what's recorded in the call: https://us02web.zoom.us/rec/share/gllobsEiHYk_fsSjoaOQA3b3WQjl_MbFcw1m3XeuXhKfZqL9rKmTUUyNh9IqMAZL.wbw7Bla6LkMzA6d3
@mwherman2000 I can't speak for others, but my thoughts on this:
- I also think the direction of this request is asking for too much as is. It appears to be a sort of "land grab" of high level concept names without a clear explanation of why that construct is used. My first though also aligns with comments above about using one spec and URLs like
did:[name]:[all the sub method things]:.... There will be far less push back on a simplified scoped style. - I believe this group wants to see innovation and exploration of DIDs and related technology. That's partly why it was created.
- When there is immediate push back to a request like this, it's a good indication to look at why there is a misalignment of expectations. People do want to help make this technology successful. Part of that process is to help guide potential use cases in a direction that aligns with a rough shared vision of the tech, which may not be documented.
- It is not productive to ask the group to "get out of the way" and be so confrontational. Arguing what specific spec text strictly allows with the group that wrote that text is not looking like fun for anyone.
- I would highly suggest a different approach in this case. Add a summary explanation of what you are try to accomplish, perhaps with example use cases, and ask for feedback about the solution you are proposing. Then iterate.
- There isn't a requirement to explain what you are doing, but some additional text would greatly help others to help you. It's also good to use an ELI5 approach vs a Rockwell Retro Encabulator one. Leave out the proprietary buzzwords and lingo. I, for one, do not have the time to dig deep into your tech stack and writings to learn what is going on otherwise. It's difficult to help without some shared understanding.
- Ideally such a discussion and process would result in methods that are considered well designed and aligned with the intended DID principles. And hopefully some improvements to the DID documentation would be suggested along the way to improve clarify and help future method developers along the same path.
- It's a tough sell to "protect" "internal" DID method names with global registrations. Namespaces are one honking great idea and at first glance it seems like that's what should be used here for those methods. If they later turn out to be generally useful beyond internal details, then promote them later with a full spec.
- The contact websites appear to be new empty landing pages. I note they are using the domain naming scheme proposed elsewhere as a means to register methods. I suspect nearly everyone will solidly reject that idea. It would be more affordable to point at an existing single website contact page.
@davidlehn I appreciate the time you invested to write the above reply. It is thoughtful. That being said, it is suffering from a Circle of Competence problem: the difference between what you know to be true and is true and what you believe to be true that is not true. This is a disease that is pervasive in all of these discussions: too many people articulating what they believe to be true that simply isn't. They are outside their Circle of Competence. Reference: https://github.com/w3c/did-extensions/issues/599
I simply don't have the time, energy, or resources to correct every untrue statement that is made. Tomorrow, I leave for a month in France and Malta. Friday, I'm a member of The Digitial Economist Fractured Futures panel. In January, I've been invited to the World Economic Forum in Davos, Switzerland to discuss decentralized systems architectures and futures - followed my some time off in Barcelona, Malaga, and Frankfurt.
Here's a couple corrections:
I also think the direction of this request is asking for too much as is. It appears to be a sort of "land grab" of high level concept names without a clear explanation of why that construct is used. My first though also aligns with comments above about using one spec and URLs like did:[name]:[all the sub method things]:.... There will be far less push back on a simplified scoped style.
- I'm not asking for too much. I'm simply requesting to have a number of DID Method names registered - plain and simple. Any further speculation is outside of one's Circle of Competence.
- It's not a "land grab". It is outside your Circle of Competence to claim this. It's an integral part of an effort I'm making to provide a categoration framework for DID Methods (https://github.com/decentralized-identity/did-methods/issues/14#issuecomment-2504391504). A new matrix will be posted shortly.
- We're also implementing a novel concept called a Web 7.0 Sharded DID Registry where we need additional DID Methods. As you point out, I'm not under any obligation to explain what this is nor do I need any "help" ...although I do appreciate the offer. This isn't my first rodeo as my neighbors say.
Ideally such a discussion and process would result in methods that are considered well designed and aligned with the intended DID principles.
I've been a named Contributor to DID CORE since the first drafts of the specification. I believe I've driven over 75+ changes in the spec - most notably the inclusion of Things as a first-class subject class in both the DID CORE as well as the Sovrin Glossary (this was done in parallel with @talltree). I am extraordinary passionate about Things and will continue to be. I've been doing it for longer that most community members have been alive (a software career spanning ~50 years).
As a First Principles Thinker (https://hyperonomy.com/2021/03/10/first-principles-thinking/), I know and understand the DID CORE Principles and contributed to them. Although my view may be different from others, I am aligned with the original and current ideals related to Decentralized Identifiers.
It's a tough sell to "protect" "internal" DID method names with global registrations.
There is no need to. Currently, there is no specific support for private, internal DID Methods in DID CORE. That being said, they are core to the design of Web 7.0 Sharded DID Registries and in fact, the DID Methods are public facing even though they are conceptually private and internal to the implementation.
The contact websites appear to be new empty landing pages.
Of course, they are! When do you register a domain for a web site? ...before you create the website? ...or after, hoping the domain is still available? These domains were acquired earlier today on schedule and on plan. If you are truly interested in wanting to see a working example, here's an early implementation:
- https://didns.directory
- Browse to this URL.
- Click on the link to the DIDNS specification.
- Click on the first link at the top of the spec page.
Over & out.
What is your evidence?
Please don't make assertions based on what someone does or does not remember - the truth is what's recorded in the call: https://us02web.zoom.us/rec/share/gllobsEiHYk_fsSjoaOQA3b3WQjl_MbFcw1m3XeuXhKfZqL9rKmTUUyNh9IqMAZL.wbw7Bla6LkMzA6d3
@mwherman2000 It is not nice to ask people for evidence if you can't produce evidence yourself. Your link points to the 5th December 2024 meeting of the did:webvh Method work item at DIF. As far as I can tell, you were not even on this call!
Perhaps you meant to share the link to the 21st November 2024 meeting of this work item at DIF, which is here: https://us02web.zoom.us/rec/share/mh3dI2YQe9p9Y4KJZDmFw57nPU_kHTEkJbXJ66ERzCpn7qyMj5Bn0TTvt4MyHrEQ.PNLEb9WVXUWU8sva
The agreement on this call was that your PR would not be accepted until 1st December 2025, whereas now you are claiming that the agreement was that you would postpone using did:tdw until Nov. 1, 2025. Clear difference.
The agreement on this call was that your PR would not be accepted until 21st December 2025, whereas now you are claiming that the agreement was that you would postpone using did:tdw until Nov. 1, 2025. Clear difference.
@peacekeeper The above statement is inaccurate/untrue - this is why evidence is needed.
The final date that @swcurran and I agreed to was Dec. 1, 2025.
Reference: Nov. 21, 2024 DIF Call: Timecode 20:00 in https://us02web.zoom.us/rec/share/UsNpfqags9z3oprz-DbXQZQX-xPEnJlBZhTn8AWfY-35hNdFkBk9QJQfVKXmU867.mbd57z9owlBoP-oi
@swcurran initiated the conversation at timecode 18:00 and suggested a delay of 12 months/1 year. I rounded it up to Dec. 1, 2025 and that's the date we agreed upon. End of story.
@mwherman2000 We both had typos in our comments above, and we both fixed them now, which is visible in the comment edits. You wrote 1st Nov 2025 and meant 1st Dec 2025. I wrote 21st Dec 2025 and meant 1st Dec 2025. So there is agreement on the date being 1st Dec 2025.
I hope there is also still agreement that this date is for accepting the registration.
This is an interesting PR. It brings into focus some challenges that the WG has been grappling about the purpose of maintaining a list of DID methods and the processes around how we maintain this list over time.
- Is this list about providing "protection" over DID method names through a process of registration and a first come first serve basis?
Chair hat off - that feels really problematic to me. I think this PR highlights why. @mwherman2000 has arguably met the very low bar required to register a method in this list. Does that mean he get "protection" over all of these method names he wishes to register.
To me this is a good argument for why we need to double down on emphasizing that this is just a informative list of known DID methods and their specifications. It provides no protection or any W3C stamp of approval whatsoever. It feels like what we should be doing is encouraging other authorities, who are motivated to, to manage their own lists/registries/whatever with the registration rules and governance processes they deem fit for their needs.
The overhead of maintaining this list as anything other than informative feels too great. I also believe strongly it is not our place, as a W3C WG, to fill any other role.
If anything, I would be in favor of publishing a point in time WG Note that contains a set of DID methods with implementations that have passed some to be defined set of conformance/interop tests.
- What is the bar for entry in this list?
This PR contains multiple DID methods each with a different specification, accept these specifications are equivalent apart from the method name. As @mwherman2000 points out, he has already registered a number of DID methods in this list in a similar manner.
I too share @peacekeeper's opinion that these do not meet the requirement:
A DID method specification MUST define exactly one method-specific DID scheme that is identified by exactly one method name
Regardless, I think this issue demonstrates the challenges of maintaining a list. We, the working group, do not have the time to properly evaluate DID method registrations against anything but the most minimal of criteria for entry in this list. I am confident there are numerous entries in the current list that are non-conformant. The fact that they are in this list gives them a sense of legitimacy, whether we like it or not.
We need to spend more time as a group discussing these issues to find a path forward.
@wip-abramson @peacekeeper @talltree
How does the concept of a purpose-built Glossary of DID Methods sound/meet the bill?
The ToIP CTWC* WG has built some simple and very easy to use GitHub-based tooling I believe they would like to share for this purpose.
Checkout https://github.com/trustoverip/ctwg-main-glossary/tree/main/spec%2Fterms-definitions for an example of the "production" ToIP Glossary.
Here is a link to the high-function published version of the ToIP Glossary: https://glossary.trustoverip.org/
Is this an answer?
*Mnemonic: Colonial Turkey With Cranberries (CTWC)
Glossary of abbreviations used above:
- ToIP — @TrustOverIP or Trust Over IP Foundation
- CTWG — Concepts and Terminology Working Group
- CTWC — I couldn't find its expansion, unless it's Classic Tetris World Championship, but that makes no sense in this context.
- CTWC — I couldn't find its expansion, unless it's Classic Tetris World Championship, but that makes no sense in this context.
Well, it could make sense if we add a did:ctwc to this PR.
Well, it could make sense if we add a did:ctwc to this PR
1.4 million + 1 ...pas problem
Reference: List of 1.4 million candidate DID Methods: https://github.com/jbarrasa/datasets/blob/master/wikipedia/data/cats.csv?raw=true (long list)
Reference: https://github.com/decentralized-identity/did-methods/issues/14#issuecomment-2547296157
As this year comes to close, I want to wish everyone a did:hohoho:mwherman2000 (to be personally and technically correct) 🙂
What percentage of the ~1.5 million potential basic DID methods (~4.1 million total potential DID Methods) do you think we can knock off in 2025? Here's a very small sample...
#iDIDit
Each DID method now has its own separate specification document. I believe there are no more open issues.
-1 to merging this, for reasons already explained earlier in this thread.