DID resolution

DID parsing, document retrieval, cryptographic verification and authority confirmation are separate contracts. A returned document is not automatically permission to execute an action.

Current resolver library

oas-resolve defines an async Resolver trait and utility implementations:

• InMemoryResolver for explicit local/test documents.
• CachingResolver for time-bounded cached resolution.
• FallbackResolver for priority-ordered backends.
• AnchoredResolver for the configured authority-anchor checks.
• ResolutionMetadata and typed ResolveError results.

Concrete HTTP, DHT or blockchain backends must implement the resolver contract; the utility crate does not itself prove a globally deployed resolution network.

Resolve safely

Parse with the actual OasDid type, select trusted resolver backends, retrieve the document, validate its structure and proofs, and apply the lineage/revocation/authority policy needed by the operation. For agent:instance, the kind has two components; a fixed-count string split is not a DID parser. Identifiers need not all be a multibase public key.

Cache invalidation and fallback order are application choices. An unavailable required authority backend should produce a denied/unverifiable operation, not an invented positive result. Inspect typed errors to distinguish a malformed DID, unresolved document, signature failure and unavailable authority evidence.

See resolver modules, AEGIS verification, and anchor policy.