Excursus: tools to help those curious about or skeptical of DID interoperability

Dear DID-WG and subscribers to its list:

The founder and former chair of the DIF Interoperability WG, Orie Steele 
(Transmute Industries, USA), asked me, also a former co-chair of the 
same group, to write for this list a little explanation of some tooling 
that Spruce Systems has open-sourced, mostly engineered by my colleague 
Charles Lehner.  Hopefully people sucked into the maelstrom of this 
objection process with no first-hand experience of DIDs could use these 
tools, or others from our community, to see for themselves how the DID 
spec, put into action, offers a rich and multi-layered interoperability 
model. This model is hard to express in documentation and perhaps the 
spec text could be clearer on the subject (I personally feel guilty for 
not volunteering more time on editorial efforts to that end). That said, 
my hope is that working code can triage that education gap, at least 
among engineers and researchers involved in debating the specification 
or its CR readiness.  Feel free to forward this email far and wide, and 
I will do my best to answer in good faith any questions about it, 
regardless of the organization after the "@" on the e-velope. Sorry if 
this is verbose, but I am hoping this email can stand alone as a 
user-guide to the links it contains for a reader only introduced to this 
whole world by a quick reading of the DID spec.

I generally find it best to start any tour of decentralized identity 
technology on the VC layer, whether my victim is familiar with OIDC and 
today's industry IAM standards or not.  I find it easiest to explain VCs 
as a portability mechanism, a cross-context and *stand-alone* way of 
passing claims made about a subject by an authority, signed by the 
authority (and later re-signed by the subject, for interactive 
presentations).  Importantly, a VC should be verifiable in a 
correlation-minimizing way, leaking as little data as possible, without 
communicating or leaking any data to the original authority or, ideally, 
anyone else.  While VCs can be used without DIDs and DIDs can be used 
without VCs, the DID use-case that I find most explanatory (and for 
which DIDs feel most optimized, in my interpretation) is that DIDs 
create a stable, unopinionated URI that can by resolved to all the key 
material and metadata needed for a verifier of a VC (or its interactive 
presentation) to check those signatures, without "phoning home" to the 
authority.

If this all sounds heady and abstract, it is.  But it can be illustrated 
using artifacts and tools from the interoperability testing regimes 
designed for VCs.  In the VC-API context, Charles made something he 
calls the multiverifier 
<https://demo.didkit.dev/2021/08/multiverifier/>tool, which lets you 
throw an arbitrary [signed] VC at all the endpoints listed on the test 
suite for the VC-API 
<https://github.com/w3c-ccg/vc-http-api-test-suite/>, a 
community-drafted RESTful API for doing the core VC operations over 
HTTP.  Cutting and pasting examples from the VC fixtures directory 
<https://github.com/w3c-ccg/vc-http-api-test-suite/tree/main/packages/vc-http-api-test-server/__fixtures__/verifiableCredentials> 
is a good way of seeing this in action, although examples 16-21 should 
be avoided for the moment, because the signature suite they rely on is 
currently under construction and all verifiers will fail.  (Sidenote: 
cryptographic flexibility is a blessing and a curse! It's also a major 
difference between the DID model and a more static, registry-based 
cryptographic specification.)

It's also worth noting that most of these test vectors are easy to 
generate and test from a known, published private key according to 
best-practices for open testing mechanisms.  These test vectors rely on 
the "did-key <https://w3c-ccg.github.io/did-method-key/>" method, which 
suspends essentially all the complexity of DID interop by using a 
"pseudo-DID"-- a deterministic DID generated from a private key with no 
optionality, update function, or state.  did-key is the first DID method 
most decentralized identity developers implement, as a kind of "warm up" 
exercise and unit-testing scaffolding before implementing DID methods 
with more bells and whistles, and the implementation they are most 
likely to open-source and compare notes on with others to be perfectly 
confident of 100% interoperability and swappability.  You could even say 
that it is the only DID method for which demonstrating interoperability 
across implementations is a trivial challenge, and the only one that is 
unit-testable with the same certainty and determinism with which you 
could test JWT handling, for example. Anything that involves a 
"Verifiable Data Registry" (i.e., an impersonal and tracking-resistant 
decentralized state machine for DID documents) is necessarily harder to 
test, interoperate, and standardize!

Speaking of which, I should probably mention Spruce has designed 
multiple DID methods <https://spruceid.dev/docs/didkit/did-methods> and 
our fully open-source CLI tool 
<https://spruceid.dev/docs/didkit-packages/cli> allows people to 
generate keys and did-keys from those keys with one command each-- 
whether for testing or for research.  Building it from code, you can 
even use Rust's "crate/trait" dependency architecture to choose which 
did methods to support natively from the list of methods we currently 
support, as your use-case demands. All other did methods than the ones 
you chose to support natively can either be ignored/dropped (treated as 
unsafe addresses) or deferred to a local or remote universal resolver.  
This tiered interoperability is illustrative: the main DID methods 
needed for a given use-case can be handled in the core DID-handling 
functions (using higher level-of-assurance, direct VDR mechanisms to 
CRUD and resolve DIDs), a second tier of DID methods can be outsourced 
to an API service within or beyond the local architecture (at a lower 
level of assurance, relying on a trusted third party), and a third tier 
can be ignored.  In a given use case, one could chose to put all 
blockchain-based DID methods, or all POW-based DID methods, out of scope 
and still have wide interoperability across many other architectures and 
VDR types. I see this as an interoperability feature, even a superpower, 
not a bug. This WG never had to choose whether POW-VDR or blockchain-VDR 
DID methods were first- or second-class implementations of the 
specification, because that is an implementation choice and beyond the 
scope of this specification. This makes each DID method a new DNS and a 
new internet, not a profile within a static system.

This degree of architectural open-endedness is, for me, the hardest 
thing to explain about the DID approach; it has certainly caused those 
of us on the educational side of things no shortage of sleepless nights 
and frustrations. Joe Andreiu and Daniel Hardman have spent who knows 
how many hundreds of hours over the years trying to make this knowable 
and measurable with the DID Rubric <https://w3c.github.io/did-rubric/>, 
and Joe's DID-method podcast 
<https://the-rubric.castos.com/podcasts/23899/episodes/introducing-the-rubric> 
makes tangible how much research is required to understand even a 
handful of methods, much less all the possible or likely categories of 
method.

For example, when people refer to DID methods, they tend to exclude from 
that set the "centralized" methods (like did:web, constrained by 
ICANN/DNS infrastructure and thus a centralized point of failure) and 
the "pseudo" methods (like did:key and did:pkh, which deterministically 
express static key material inputs in the format of a DID document for 
cross-context/portability purposes).  Neither of these categories of DID 
has a decentralized "update" or "delete" mechanism, and indeed, even 
their "create" functions often outside the security, recovery, update, 
and delete capabilities we expect in a DID system to another control 
plane, relying on manual processes and/or centralized control 
structures.  This is not a design flaw or a cop-out; it is a hybrid 
approach to create onramps and adoption strategies, as well as making 
testing possible in the short term, before any large-scale DID methods 
have been hardened, battle-tested, and commoditized.  The core of 
standardization and interoperability that is already proven and provable 
is did-key; other methods are best thought of as 
conditionally-interoperable extensions of this solid foundation, and 
seen through that lens the degree of interoperability between them is 
actually quite impressive, on this side of mass adoption.  Each major 
DID method will harden as it grows, and in retrospect this awkward 
period of scaffolding and prime-pumping will not look quite as awkward 
as it can feel at this vulnerable juncture.

This iterative approach to standardization is a lot more deliberate, 
structured, and nuanced than it might appear at first glance, which 
accounts for some of the unavoidable defensiveness many of us feel who 
have tried for years to explain it to various parties outside the 
emerging-infrastructure sector. We have been monitoring its steady 
progress, and feel confident that it is going as planned. On a personal 
note, I would argue that this strategy is largely born of our shared, 
nuanced and deep commitment to anti-trust approaches to IT and IP, a 
commitment which I hope is shared by the broader W3C, and which I hope 
is a major topic at TPAC.

In any case, to anyone who made it this far, in whatever admixture of 
good and bad faith, your volunteering your time to this matter is 
appreciated. Thanks,
--juan
------------------------------------------------------------------------
Juan Caballero, PhD. Open Source Yenta and Advisor, Spruce Systems, USA 
Berlin-based (CET): +1 415 31null one35one