Re: Ideal set of features and DID Methods?

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

Received on Monday, 26 January 2026 02:46:56 UTC