Re: Ideal set of features and DID Methods?

Manu, Kyle, all,

Thank you for this excellent discussion that has clarified the exact
tension we need to resolve. Let me synthesize a concrete path forward that
addresses both sets of concerns.

Manu is right: We need specialized DID methods optimized for different use
cases - DNS-based for organizations, fully decentralized for individuals,
ephemeral for capabilities.

Kyle is right: Browsers and applications can't maintain endless
method-specific code paths without harming adoption.

The bridge between them: A Verified Encoder Model (VEM) that treats DID
methods like database drivers - each with its own implementation, but all
presenting a standardized interface.
1. Three Canonical Methods (Preserving Manu's Vision)

   -

   did:web+ - DNS-based with CEL + DNS TXT
   -

   did:cel - Fully decentralized with witnesses
   -

   did:key - Ephemeral

Each method innovates within its domain without compromise.
2. The VEM Layer (Solving Kyle's Concerns)

Each method ships with a Verified Encoder Module - a WebAssembly bundle
containing:
yaml

# VEM Header (Machine-readable method properties)encoder_version:
"1.0"did_method: "cel"formal_proof_cid: "QmProofHash..."  #
Decentralized proof storagedeclared_capabilities:               # What
resources it needs
  - "p2p_witness_network"
  - "ipfs_storage"
  - "http_gateway_fallback"proven_properties:                   #
Mathematically verified
  dns_dependent: false
  min_witnesses: 15
  fork_protected: true
  recovery_mechanism: "key_rotation"
  quantum_resilient: falsederived_metrics:                    # Auto-calculated
  security_score: 0.92
  availability_score: 0.88
  trust_anchor_count: 3

3. Browser Integration (One Integration Point)

Browsers implement a single sandboxed resolver:
javascript

// Unified API for ALL methodsconst result = await
navigator.credentials.resolveDID(did, {
  policy: {
    min_security_score: 0.85,
    require_fork_protection: true,
    allow_dns_dependent: false,
    max_fuel: 50000  // Resource limits per request
  }});
// All methods return identical structureif (result.meets_policy) {
  useDID(result.normalized_document);}

On the "Oracle Problem" (Who verifies the proofs?):

   -

   No central authority required. VEMs include formal mathematical proofs (in
   languages like Dafny or Lean)
   -

   Browsers/resolvers locally verify these proofs before execution
   -

   W3C registry becomes a distribution point, not an approval authority
   -

   Similar to how TLS cipher suites work - implementations verify, not trust

On Network Access (Method-specific requirements):

   -

   Capability-based security model: Each VEM declares what it needs
   -

   did:web+ gets HTTPS + DNS capabilities
   -

   did:cel gets P2P + IPFS capabilities
   -

   Sandbox enforces boundaries - no overreach possible

On Schema Evolution:

   -

   Properties registry evolves decentralized-ly
   -

   New properties emerge as methods innovate
   -

   Auto-promotion to "standard" when adoption threshold reached
   -

   Backward compatibility through versioning

Concrete BenefitsFor Method Authors (Manu's perspective):

   -

   Freedom to innovate within method constraints
   -

   Clear differentiation through proven properties
   -

   No "lowest common denominator" compromise
   -

   Formal verification ensures claims are credible

For Browser Teams (Kyle's perspective):

   -

   One code path to maintain - the sandbox
   -

   Dynamic loading - no need to ship all encoders
   -

   Policy-based evaluation - no method-specific logic
   -

   Resource control - prevent DoS via fuel limits

For Application Developers:

   -

   Single, simple API to learn
   -

   Policy-based DID acceptance
   -

   No need to understand method internals
   -

   Future-proof against new methods

For Verifiers:

   -

   Set security policies, not method whitelists
   -

   Risk assessment based on proven properties
   -

   Consistent evaluation across all methods

What This Enables

   1.

   A bank can require: security_score > 0.9 AND fork_protected = true
   2.

   A social app can accept: availability_score > 0.5
   3.

   A government can mandate: dns_dependent = true AND witness_count >= 5
   4.

   A P2P system can require: dns_dependent = false

All without knowing or caring about the specific DID method used.
Next Steps We Could Take

   1.

   Quarter 2 2026: Define the VEM header specification (what properties
   matter?)
   2.

   Quarter 3 2026: Build reference implementation (sandbox + 2 VEMs)
   3.

   Quarter 4 2026: Browser vendor testing (Chrome, Brave, Firefox)
   4.

   Quarter 1 2027: Formal standardization through W3C

The hardest part isn't the technology - WebAssembly, capability security,
and formal verification are all mature. The challenge is agreeing on the
property taxonomy: What absolutely must be communicated about a DID
method's security model?

So my concrete ask to this group:

   -

   What properties should be in the VEM header?
   -

   What distinguishes did:web+ from did:cel in machine-readable terms?
   -

   What minimum metadata do verifiers need to make policy decisions?

If we can answer these questions, we get the best of both worlds:
specialized methods below, unified interface above, with mathematical proof
as the bridge instead of committee consensus.

Best regards,

Amir Hameed

On Sun, 25 Jan 2026 at 18:49, Kyle Den Hartog <kyle@pryvit.tech> wrote:

> > I'm taking "cohesive" to mean "effectively the same security model
> across various methods", and for that definition, no, I don't expect them
> to be entirely cohesive. I expect the resolution model to be "cohesive
> enough" and "good enough" for the use cases for each DID Method, but I
> don't think it's possible for them to be close enough for one to presume
> effectively similar security models.
>
> Yeah, I'm pragmatic about this, but also believe that DID Core should
> encapsulate as much as it can from the Method layer. Otherwise, the
> complexity leaks to the caller of the resolver to deal with and if this
> becomes overly difficult then it will hamper adoption. Something to note is
> that most people don't deal with TCP/UDP directly today. They're low level
> primitives that have been abstracted by layers of encapsulation above like
> HTTP.
>
> > Hmm, define "non-interop"... I'm taking that to mean that you can drop
> and replace one DID Method with another and not think about the security
> ramifications of doing so, and I don't think that's the case with any DID
> Method. If you're a verifier, you need to figure out which DID Methods meet
> your use case requirements. For example, as a verifier, you might only
> allow issuers to to be did:web-based.
>
> Again, I'm pragmatic here, but if Hyrum's law becomes a bug within the
> system due to over optionality it will introduce unnecessary complexity.
> Speaking as someone who has to deal with this already within a browser
> environment, that's a time and cost to maintain the feature. As an example,
> each time we choose to rely on ENS/UD TLDs we have to think about how the
> records are resolved, how their resolution behavior is potentially
> different from normal browser behavior, how it will be abused, and how we
> communicate these differences to the user. A great example of this is that
> we've opted to not support .888 as a Web3TLD simply because when you put
> http://127.888 into the omnibox it maps that to http://127.0.3.120/ which
> means there's a potential for namespace conflict with current browser
> behavior. So, it's easier to just not adopt that Web3 TLD. Similar issues
> occurred when we tried to support ipfs:// scheme which conflicted with the
> secure contexts specs. Ultimately we had to deprecate support of it
> (mostly) because adoption lacked and the cost to maintain the
> differentiating points was too high.
>
> > Yes, those are all realities that we need to design for. That is, we
> need to warn verifiers that those things are possible (depending on the DID
> Method)... probably via the security considerations and threat model
> documents.
>
> I'd argue these are issues that need to be designed away, not warned
> against as much as possible. Over reliance of the privacy and security
> considerations sections kicks the complexity onto the implementers to
> resolve. That's a cost to maintain which will limit adoption.
>
> > Can you elaborate on this one a bit more? I know you're making a good
> point, but the Route53 internal network router / encryped IPFS record threw
> me -- I don't know how those two things are interacting and I don't know
> how they fit into the categories I mentioned.
>
> Essentially, it's just leveraging access control constraints from the VDR
> to make denial of service a feature of privacy not a bug. So say for
> example, my resolver can identify the DID Document, but it's encrypted then
> it can't comprehend it and resolution fails unless I have the key to
> decrypt the did document. The reason someone might want this is because
> they want the security properties of a globally unique identifier, but they
> want to limit which verifiers can rely upon it. This is a very niche case,
> that I'm not convinced there's a need for. The more common constraint would
> be an ephemeral did that acts more like an object capability link where you
> can only resolve a did:key method if you possess the identifier first.
>
> > Yes, excellent point, we should strongly suggest Oblivous DNS over HTTP
> (ODoH)
>
> I'd love to see this, but I fully expect that ODoH would end up as a
> "SHOULD" rather than a "MUST" (if it's even normatively defined) just do to
> lack of adoption. That's a place where the WG will need to decide what
> level of optionality it wants to place at this tradeoff point. That's all I
> really wanted to call out with that.
>
> > What would it take for a browser to realistically want to resolve these?
> Ideally, we'd work those into the requirements for each DID Method.
>
> Realistically, there needs to be demand for one and low cost of
> maintenance for us to adopt it. The reason we're able to keep ENS/UD around
> is because it basically just calls out to an RPC service for resolution
> which abstracts a fair amount of the complexity from us and then we just
> need to care about our integration points. There are still cases where odd
> behavior occurs. For example, if the ETH burn address is returned by an ENS
> address mapping, should we error, warn the user, or let them blindly burn
> money in the wallet? We've not yet crossed the bridge of dealing with
> contentious forks of ETH since our ENS support was added, but if another
> were to occur that also comes into play here.
>
> > I presume by "us", you mean Brave? You're right, we do need to think
> about how commercial competition might destabilize the ecosystem... the
> unintended consequences of capitalism on each system. I expect we know more
> about how DNS is affected (because there's decades of history there) vs.
> how a cryptographic log/witnessed/etc. system would be impacted by market
> forces.
>
> This could easily turn into a red herring debate that I don't think the WG
> can specify away much. The main reason I brought it up though is that it
> goes back to the encapsulation point. As an example, Anytime a TLD can
> potentially collide we have to evaluate how to handle it. As one example,
> .eth cannot be registered with ICANN because it conflicts with their
> reserved status of Ethiopia via 3 letter ISO country codes. Luckily for us
> ICANN hasn't released any of these, but if they did it would mean we'd need
> to drop support of ENS to prevent this namespace conflict and the
> downstream effects it would have on the origin security model in the
> browser. These same sorts of issues will occur on implementers and users of
> DIDs (either resolvers or their callers) due to the lack of
> decentralization of method names within the identifier syntax. This is why
> I was so incredibly pedantic when the did:keri split[1] was being discussed
> was that we had to rely on governance mechanisms of the registry to
> encapsulate the problem from implementers having to deal with it instead.
> Had we just let implementers decide it would've invalidated the global
> uniqueness of that method like what Brave is doing by acting as the
> technical adjudicator of which Web3 TLDs it supports. If the spec doesn't
> do this for us, or a resolver doesn't do it for us, then we'd have to do it
> and that's going to make it significantly more complex to implement and
> maintain.
>
> [1]: https://github.com/w3c/did-extensions/pull/395
>
> On Monday, January 26th, 2026 at 1:15 PM, Manu Sporny <
> msporny@digitalbazaar.com> wrote:
>
> >
> >
> > On Sun, Jan 25, 2026 at 6:48 PM Kyle Den Hartog kyle@pryvit.tech wrote:
> >
> > > Are you expecting a cohesive resolution security model across these
> various methods?
> >
> >
> > Hmm, define "cohesive"... :)
> >
> > I'm taking "cohesive" to mean "effectively the same security model
> > across various methods", and for that definition, no, I don't expect
> > them to be entirely cohesive. I expect the resolution model to be
> > "cohesive enough" and "good enough" for the use cases for each DID
> > Method, but I don't think it's possible for them to be close enough
> > for one to presume effectively similar security models.
> >
> > For example, TCP and UDP get data from point A to point B, but they do
> > it in ways that implementers need to understand the differences. I
> > expect the same for DID Methods -- you do need to read the Privacy and
> > Security Consideration sections to understand the sort of beast you're
> > dealing with.
> >
> > > The weird edge cases that won’t account for variations at the VDR
> layer that the resolver needs to handle seem like it could leads to
> non-interop between these 3 classes of DID methods
> >
> >
> > Hmm, define "non-interop"... I'm taking that to mean that you can drop
> > and replace one DID Method with another and not think about the
> > security ramifications of doing so, and I don't think that's the case
> > with any DID Method. If you're a verifier, you need to figure out
> > which DID Methods meet your use case requirements. For example, as a
> > verifier, you might only allow issuers to to be did:web-based.
> >
> > > For example:
> > > 1. Authoritative Forks of VDRs and Methods (precedence’s exist here)
> > > 2. VDR shutdowns (Sovrin network is down to a single archive node)
> > > 3. Differences in availability
> >
> >
> > Yes, those are all realities that we need to design for. That is, we
> > need to warn verifiers that those things are possible (depending on
> > the DID Method)... probably via the security considerations and threat
> > model documents.
> >
> > > Additionally, what is the expected shared and differentiated privacy
> model between various methods?
> >
> >
> > Yes, this also needs to be documented in the Privacy Considerations
> > sections for each spec.
> >
> > > For example:
> > > 1. Record request authorization gates (e.g. DNS record is stored only
> on my Route53 internal network router / IPFS record is encrypted)
> >
> >
> > Can you elaborate on this one a bit more? I know you're making a good
> > point, but the Route53 internal network router / encryped IPFS record
> > threw me -- I don't know how those two things are interacting and I
> > don't know how they fit into the categories I mentioned.
> >
> > > 2. Resolution lookups should account for best practices of private
> resolutions with DoH if not ODoH
> >
> >
> > Yes, excellent point, we should strongly suggest Oblivous DNS over HTTP
> (ODoH).
> >
> > > These are a bit more advanced than probably the initial feature set,
> but something that should be drawn into the baseline in order for a browser
> to realistically want to resolve these.
> >
> >
> > What would it take for a browser to realistically want to resolve
> > these? Ideally, we'd work those into the requirements for each DID
> > Method.
> >
> > > Even with less optionality I’ve got to account for things like this in
> Web3 TLDs like ENS and UD domains where there’s commercial competition and
> no authority over the namespace like ICANN. This has left us as the
> resolver to act as the namespace authority rather than deferring it to an
> external party like we do with traditional DNS.
> >
> >
> > I presume by "us", you mean Brave? You're right, we do need to think
> > about how commercial competition might destabilize the ecosystem...
> > the unintended consequences of capitalism on each system. I expect we
> > know more about how DNS is affected (because there's decades of
> > history there) vs. how a cryptographic log/witnessed/etc. system would
> > be impacted by market forces.
> >
> > All good stuff, Kyle -- thanks for the food for thought -- looking
> > forward to your responses.
> >
> > -- manu
> >
> > --
> > Manu Sporny - https://www.linkedin.com/in/manusporny/
> > Founder/CEO - Digital Bazaar, Inc.
> > https://www.digitalbazaar.com/
>
>