Requirements for DID Method Standardization

[msporny]

In order to determine which DID Methods to focus on incubating in 2025, we'll need some sort of selection criteria that has the broadest consensus within the community. This issue is being raised to do some data collection around what that selection criteria should be; that is -- what requirements are important to you when selecting a DID Method that is to become a global standard?

Once we have a list of requirements, we can do a ranked choice poll on all the criteria to see what the community feels is most important to least important. We might have to separate the criteria by DID Method type (ephemeral, web-based, decentralized) because each might have slightly different requirements.

So, what requirements are important to include in this upcoming ranked choice poll among the various communities involved in this work?

[msporny]

A few that come to mind based on discussions with various community members over the last several months:

• At least one ephemeral DID Method should be identified for standardization. These are useful for short-lived, secure
  communication. Examples include did:key and did:jwk.

• At least one web-based DID Method should be identified for standardization. These are useful for issuers of verifiable
  credentials and other forms of attestations who know how to manage web domains but are not willing to depend on blockchains or DHTs for their root of trust (i.e., governments). Examples include did:web and did:tdw (the incubated at DIF / Province of BC version).

• At least one "fully decentralized" DID Method should be identified for standardization. These are useful because they achieve what the other two classes of DID Method above don't achieve -- the vision for why we created DIDs in the first place. Examples include did:dht.

• "Global government-approved crypto" is important to ensure governments can adopt the DID Method. Examples include ECDSA.

• "Privacy-preserving crypto" is important, even if not government approved, to ensure the privacy of individuals. Examples include BBS.

• A digitally signed cryptographic log of changes to the DID Document is a useful feature to standardize on its own (so that multiple DID Methods could utilize the feature).

• A multi-factor binding to DNS is an important feature to standardize on its own (so that domain owners can provide an extra level of security on their DID Documents).

• A specification with multiple implementers is always preferable to inventing something new unless the community is behind the concept that the "something new" is necessary.

[msporny]

From Steven Capell via the CCG mailing list:

• Long lived VCs need long lived DIDs. Domain names change, ledgers come and go, hosted DID web issuers go bust, … lots of reasons why a business of government agency might need to “move” a DID without invalidating previously issued VCs

[peacekeeper]

I think this is a great list @msporny. The WG's Operating Addendum also contains a few possible (high-level) criteria for the selection process (in section 4.4 "Evaluation Criteria for DID Methods"), which I am copying here:

• Alignment with DID Core specification
• Interoperability with other DID methods
• Security and privacy features
• Scalability and performance
• Ease of implementation and use
• Community adoption and support
• Compliance with relevant regulations and best practices
• Diversity of the set of selected methods

Others, please also feel free to share your thoughts on selection criteria!

[msporny]

From Adrian Gropper via the CCG mailing list:

• Addresses the role of biometrics relative to DIDs as a primary or foundational concern.

[mccown]

@msporny, @peacekeeper this is a great requirements list. Given the trademark issues that have come up lately, I propose that we add a step that will address trademarks as a quick ad hoc check during registration.

Reading the other issues / comments, I reflected on the fact that this is an international body and that copyrights, trademarks, & patents are national issues that don't apply internationally. For example, someone could get a copyright in the US, which would apply only within the US and nowhere else. Similarly, a European copyright would be enforceable within Europe, but not enforceable within Asia (unless nations have additional treaties).

This leads to the recent dilemma -- should this WG approve a DID Method request in light of potential copyright, trademark, or patent issues?

I don't think this is the right place for such a debate, because those rights / limitations are only valid within the country of issuance. For example, if a patent holder receives a US patent, but not a EU patent, then the invention is legally implementable in Europe without patent restrictions. That may cause hard feelings, but that is how the laws are written.

So, what should we do?

The ICANN Uniform Domain Name Dispute Resolution Policy has some very interesting requirements. Two items stood out to me:

1. Paragraph 2: the submitter warrants that they are not knowingly infringing on someone else's rights

2. Paragraph 3: "We will cancel, transfer or otherwise make changes to domain name registrations under the following circumstances:" "... our receipt of an order from a court or arbitral tribunal, in each case of competent jurisdiction, requiring such action; and/or"

What that means is that ICANN deferred the initial due diligence back to the submitter and instructed any parties claiming infringement to have their claim adjudicated by their governing legal authority. This keeps ICANN out of the debate while processing and complying with official legal rulings.

Does that process sound reasonable for our purposes?

[agropper]

Thanks, Manu. I started a separate issue #12 to focus on the biometrics.

[mwherman2000]

#10 (comment) is a W3C issue - not a DIF WG issue based on discussions from earlier this week.

This topic is being tracked here: w3c/did-extensions#597

@kimdhamilton @mccown

[mwherman2000]

@manu why are you subsuming other people's contributions into your list? What do you think your role is wrt this WG?

Wirt our WG processes we're still at the STRAWMAN stage in terms of process and organization proposals, discussion, and decision making. Feels a bit rogue.

@peacekeeper @kimdhamilton

[TallTed]

It seems worth putting the substantial time and energy invested in the DID Rubric (see DID Method Rubric v1.0, latest Editor's Draft) to work in this process.

If there are considerations/criteria above which are not yet part of the Rubric, it seems they should be added.

It seems likely that the ranked-choice poll described above might be satisfactorily run then, targeting the Rubric's criteria for ranking.

Theoretically, a long-ish list of candidate DID Methods could then be assessed, based on the Rubric, which results could then lead to a short list of candidate DID Methods based on how they fit with the ranked-choice poll above...

There's nothing easy about this. Much of it is more subjective than not, so applying the Rubric to the candidate DID Methods might require setting up (something like) a spreadsheet into which multiple people could put their Rubric assessments, which could then be averaged to arrive at our "working" (i.e., not carved in stone, not meant to be inherited for use elsewhere, meant only for purposes of this standardization effort) Rubric assessment....

Just some thoughts.

[Olvisgil]

This is a great discussion! A few additional points I think we should consider to ensure robust and inclusive DID Methods:

Governance: Clear frameworks for updates, dispute resolution, and decision-making are essential for trust and longevity.
Usability: Simple implementation for developers and intuitive UX for end users will drive adoption.
Sustainability: Environmental impact matters—methods should prioritize energy efficiency and eco-friendly infrastructure.
Economic Feasibility: DIDs costs of use must be reasonable for individuals, small businesses, and governments, especially in developing regions.
Legal Recognition: Cross-border frameworks for DID acceptance are critical for government and enterprise adoption.
Revocation and Recovery: Decentralized mechanisms for key rotation and DID recovery should be a standard.
Emerging Markets: Offline-friendly, low-bandwidth solutions are key for inclusivity.

I strongly believe that if we address these points, it will make DIDs more impactful globally.

[mwherman2000]

Once we have a list of requirements, we can do a ranked choice poll on all the criteria to see what the community feels is most important to least important.

So, what requirements are important to include in this upcoming ranked choice poll among the various communities involved in this work?

@manu At this time, it's presumptuous to assume (let alone suggest it advertise) that there will even be a upcoming ranked choice poll. Please don't do this.

@peacekeeper @kimdhamilton

[mwherman2000]

So, what requirements are important to include in this upcoming ranked choice poll among the various communities involved in this work?

@manu At this time, it's presumptuous to assume (let alone suggest or advertise) that there will even be a upcoming ranked choice poll. Please don't do this.

@peacekeeper @kimdhamilton

[msporny]

Input from Bryan Newbold of BlueSky on requirements that would be useful from a BlueSky perspective:

• Low and predictable marginal cost at scale (millions of accounts): as an example, SMS verification of user accounts can be prohibitively expensive for service providers, even when costing well under a US dollar per account
• Ability to create and update identifiers rapidly (within seconds, ideally under a second)
• Key rotation is a must
• Reliable and predictable-latency operation, both for updating identifiers and resolving them (the "tail latency" of resolution is important)
• Identifiers are long-lived and continue to function after periods of inactivity
• Resolution should not require additional state or context, and "new" resolvers can independently resolve all "old" identifiers
• DIDs are permanent and immutable account identifiers