Re: Ideal set of features and DID Methods?

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 00:14:54 UTC