If you really must use did:webvh

did:webvh is a decentrilzed identified method that is positioned as a more secure replacement for did:web.

It is gaining popularity as it's easy to understand, well specified and offers a few improvements over just serving your current did document, i.e. the metadata needed to verify transactions involving your identifier, from a web server.

Specifically, webhv stands for "verifiable history", which means that the identifier resolves to a did document that contains not only the current metadata ( public keys, signatures, endpoints, etc.) but also the changes. The latter is very important for a number of security related measures, such as key rotation (as to why see "cryptoperiods" e.g. here).

What's important, these changes are packaged into a "tamper proof", verifiable data structure, ensuring that the initial data that was used to create the identifier is at the root of the history. This way one can always continue to refer to the same identifier, even though its underlying data might have evolved over time. For a quick comparison to some other did methods see "did traits" document.

Overall, it's a reasonable effort to create something that is both securely and promotes "decentralization", while making it easy to understand and implement.

So what are the potential issues with it?

For starters, one needs to understand how this method was born.

Initially, as part of the ToIP's push for a new security layer (!) for the internet, a method called did:webs was proposed. This method is based on KERI (Key Event Receipt Infrastructure) - a new, bottoms-up, systems-thinking based approach to Decentralized Public Key Infrastructure (DPKI), which also goes hand in hand with verifiable data exchange tech excitingly named ACDC (Authentic Chained Data Containers - spec). ACDC is notoriously used for Verifiable Credentials, e.g. vLEI but can be used to exchange other data in a verifiable, step-by-step way, while ensuring very solid security (e.g. key usage transparency, among other things).

Just by reading this very brief description, you might be getting an impression that KERI/ACDC is complex.

Yes, it is! In fact, even most experts already familiar with the domain usually require a few attempts to appreciate its elegance (I use the word sincerely here) and get excited about its prospects.

Because of this (comparative!) complexity and uncompromising commitment to zero-trust security combined with unfortunate choice of terminology (IMHO), implementing did:webs is not easy. People wonder if there's an easier way to achieve everything that KERI/ACDC has set out to achieve.

So the effort splits-off, picks many of the good ideas (e.g. verifiable history, key pre-rotation, etc), de-prioritizes some important features (e.g. witnesses ), sets on "tried and true" tech choices such as reliance on web servers, DNS, pure JSON, etc.

As to why it might be problematic from a privacy perspective, Georg Greve offers a good analysis in his blog post.

I largely agree.

However, I understand that we can't wait for a perfect technology to become available and need to start somewhere and iterate, this is how most of the current progress has been achieved. It's even more important to innovate and iterate quickly in the field of Digital Identity and Verifiable Credentials, if we want to avoid the usual suspects (the internet giants) simply monopolizing the space by pushing their proprietary solutions, closed ecosystems, retaining and strengthening control of the personal and business data as a result.

So I'd like to offer some thoughts on how something like "did:webvh" can be used with a bit more certainty, avoiding false security assumptions.

Why false?

Well, as the tech gets used more and more outside of centrally controlled environments (e.g. SWIYU, British Columbia, etc) inevitably the Standard Operating Procedures (SOPs) that have to be in place to make underlying infrastructure reasonably secure will likely be less followed. As a result, assumptions about security posture of "did:webvh" will no longer be correct leading to a heightened possibility of high impact cyber attacks.

It's actually amazing how brittle our current Internet infrastructure is. For discussion on non obvious DNS attack vectors and false assumptions see my article on the topic.

There are some measure, the SOPs, that can be followed to make it reasonably secure, which I'll lit out later.

First, I'd like to revisit the topic of "witnesses".

What are these and why are they needed?

Again, consider a situation where KERI or did:wenvh are being used widely. Which means that not only trustworthy actors ( by mandate, e.g. governmental agencies, or by the risk of losing reputation) are starting to use the technology. Can they cheat? Even for a shot term gain? Or maybe just by a honest mistake?

Yes! As an example, consider that one can publish alternative versions of the key(s) history and serve it selectively. Which enables one to then refute signatures, etc. This is called "duplicity". Can also arise due hacker actions, if they get hold of the current key somehow.

If the only source of truth is the did document (a log of key events), the counter-party has no way of verifying if the presented history (newer events compared to the cached version) are committed to and spot inconsistencies. The counter-party has to explicitly trust. Not a good situation to be in!

Very simply, witnesses are third party services that collect key/identifier events signed by the controller, counter sign them, store the consistent version of the history and enable relying parties to make sure that a single and coherent version of key/identifier event history is verifiably and equivocally committed to by the controller. One can think of it as a way to replace the need for a single ledger/blockchain. There are subtle details on how it should all be organized to be dependable, but the above description should provide a meaningful intuition, I hope.

So my first recommendation, is to make witnesses mandatory.

Now back to protecting the underlying infrastructure. Here are some basic measures to put in place to avoid obvious attack vectors and build a base for technical trust.

1. Make sure that DNS server(s) of the did:webvh controller are using DNSSEC.
2. Impose requirement that they either have a published and audited policy of managing their DNSSEC keys and DNS servers or delegate to a provider that can demonstrate adherence to the best practices. This includes both access control and rotation of the keys, as well as access control to changing the actual DNS records. These events should be monitored. Audit this!
3. Make sure that the web server serving did documents is using at least OV (Org Validated) Certificate to this legal entity. Better yet an EV (Extended Verification) one. Make sure it has a maximum 1 year lifetime, better yet 6 months.
4. Make sure web server is setup for TLS 1.3 only, preferably using a PQC scheme ( this is the easy part). Even better QUIC, as it becomes more prevalent.
5. Very important - require that applications requesting a did document don't rely on OS provided DNS resolvers. They usually don't check DNSSEC status or set-up to fallback silently. Either bundle a reputable DNS Resolver library as it gives you more control, or make sure to use the correct API setting that enforces the validation on your platform (e.g. iOS).
6. Bonus - validate OCSP/CRL status of the cert chain
7. Bonus - monitor Certificate Transparency Log for the domain of the did:wenvh controller.
8. Bonus - follow cyber security news regularly to spot new attacks on DNS/Web Infra in time. There's always something new out there.

Or if you want to have a simple life - take time to understand and love KERI/ACDC and start using vLEIs! In the end there are going to be a lot fewer moving parts :)

Thanks for reading!