Here is a structured article written in a precise, verification-forward style.
DID Method Specifications as Abstract Data Types
And DID Documents as Second-Order Abstract Data Types
The relationship between a DID method specification and a DID Document can be understood cleanly through the lens of abstract data type (ADT) theory. This framing is not metaphorical fluff—it is structurally accurate and technically clarifying.
We proceed in two layers:
- A DID method specification is analogous to an ADT definition for the DID method itself.
- A DID Document is analogous to an additional ADT for working with the entities defined by that method.
I. What an Abstract Data Type Actually Is
An abstract data type defines:
- A domain (a set of valid values)
- A set of operations
- Behavioral constraints and invariants
- Without specifying internal implementation details
Classic examples:
- Stack (push, pop, peek)
- Map (put, get, delete)
- Set (add, remove, contains)
An ADT defines what is valid and what operations mean, not how they are implemented.
II. A DID Method Specification as an ADT
A DID method (e.g., did:example, did:key, did:web) is formally defined by a method specification under the W3C DID Core framework.
1. The Domain
A DID method defines:
- The syntactic structure of valid identifiers
(e.g.,did:<method>:<method-specific-id>) - The rules for resolving identifiers
- The lifecycle semantics (creation, update, deactivation)
In ADT terms:
The DID method defines the valid elements of its identifier space.
Formally:
Domain = { all valid DIDs conforming to method rules }
2. The Operations
Every DID method defines:
- Create
- Resolve
- Update (if supported)
- Deactivate (if supported)
These are behavioral operations over the identifier space.
Crucially:
The specification defines what those operations mean, not how they are implemented internally (blockchain, database, DNS, etc.).
That is exactly what an ADT does.
3. Invariants
Each DID method defines constraints such as:
- Uniqueness guarantees
- Immutability or mutability properties
- Resolution determinism
- Authorization rules
These are behavioral invariants of the abstract structure.
Conclusion (Layer 1)
A DID method specification functions as:
An abstract data type definition whose elements are DIDs of that method, and whose operations are create/resolve/update/deactivate under defined invariants.
It defines:
- The type
- The allowable operations
- The semantic guarantees
- While abstracting away implementation details
That is textbook ADT structure.
III. The DID Document as a Second-Order ADT
Now we move to the second layer.
When you resolve a DID, you obtain a DID Document (as defined by the DID Core specification).
A DID Document is not just a JSON file.
It is a structured object with defined semantics.
1. The Collection Defined by the DID Method
If a DID method defines a collection:
M = { all valid DIDs under method X }
Then each DID in that collection corresponds to a resolvable subject.
The DID Document is the canonical representation of that subject.
So:
- DID method → defines the identifier collection
- DID Document → defines the abstract representation of each member
2. DID Document as an ADT
A DID Document defines:
Domain
A structured object containing:
- id
- verificationMethod entries
- authentication methods
- key agreement methods
- service endpoints
This defines the state space of a subject.
Operations
Although not expressed as classical functions, the DID Document supports defined semantic operations:
- Verification of signatures
- Authentication checks
- Capability delegation
- Service endpoint discovery
These operations are defined by the structure of the document.
Again:
The document defines the interface and semantics—not the underlying cryptographic implementation.
That is ADT structure.
3. Abstraction Boundary
The DID Document abstracts:
- How keys are stored
- How cryptographic proofs are generated
- Where services are hosted
It defines only:
- What verification methods exist
- What services are associated
- What relationships are authorized
This is interface-level abstraction.
Exactly what ADTs formalize.
IV. Why This Is Not Just Analogy
This mapping is not poetic. It is structurally precise.
ADT ConceptDID MethodDID DocumentType DefinitionMethod specDocument schemaDomainValid DIDsValid subject stateOperationsCreate/Resolve/UpdateVerify/Auth/DiscoverInvariantsUniqueness, lifecycleKey integrity, structural validityImplementation HiddenLedger/DNS/etc.Key storage, crypto engines
The layering is clean:
- DID method = ADT over identifiers.
- DID Document = ADT over resolvable subjects.
- Applications operate only through these abstractions.
V. Deeper Structural Insight
There is an important second-order property here.
A DID method defines:
A type whose elements resolve to another type.
In type-theoretic terms:
Method : Identifier → Document
So the DID method ADT produces instances of another ADT (the DID Document).
This is analogous to:
- A class factory
- A parameterized type constructor
- A category whose morphisms produce structured objects
Thus:
- The DID method defines the collection.
- The DID Document defines the algebra over elements of that collection.
VI. Why This Framing Matters
Viewing DID architecture through ADTs clarifies:
- Why methods must be formally specified.
- Why interoperability depends on behavioral invariants.
- Why documents must obey strict structural semantics.
- Why implementation diversity does not break correctness.
It also reveals a design strength:
The DID architecture is layered abstraction done properly.
VII. Compact Executive Statement
A DID method specification functions as an abstract data type that defines the valid identifier space, lifecycle operations, and invariants for a class of decentralized identifiers.
A DID Document functions as a second abstract data type that defines the structured state, verification semantics, and service interface of each subject within that identifier class.
Together, they form a two-level abstraction system:
- Level 1: Identifier type algebra
- Level 2: Subject capability algebra
This perspective removes confusion and replaces it with formal clarity.