Re: Ideal set of features and DID Methods?

On Mon, 26 Jan 2026 at 05:17, Amir Hameed <amsaalegal@gmail.com> wrote:

> 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/
>>
>>