did:webs Architecture and Resolver Explanation

How does one use did:webs? Why is it designed the way it is? This document exists to concisely, pictorially, and clearly accomplish both documenting architecture ofseveral did:webs components and illustration of integrating did:webs into software that needs to rely on did:webs DIDs. In addition to a how-to, this document is a why-to and a when-to. Components described includes the DID artifact generator for the did.json and keri.cesr artifacts, the resolver, and the available did:webs libraries.

This document is supposed to be short and concise, not a repetition of the specification. This document makes the specification accessible. For authoritative, verbose, normative language refer to the specification text. And, this document constructs a complete picture of the relationship between all specification documents involved in the did:webs effort. This is necessary because did:webs uses DID document extensions for threshold signatures, multisig, and delegation. The challenge of tracking the purpose and status for each of the involved specifications is made easy with an explanatory document like this.

Status: Work in progress

Outline

1. Basic did:webs parts

   1. A did:webs DID document

   2. Versioned DID resolution metadata supporting versioned DID documents

   3. Use of designated aliases

   4. Resolver for containing verification logic

2. Threading did:webs through all of the specifications

   1. DID core spec

   2. DID doc extensions for threshold proofs, multisig, and delegation

      1. ConditionalProof2022 for threshold signatures including multisig

      2. DID doc Service for delegation features

3. Implementations and libraries

   1. Python: GLEIF-IT/did-webs-resolver

   2. (WIP) Typescript: GLEIF-IT/did-web-ts

4. Universal Resolver

   1. did:webs driver for the universal resolver

5. Integrating did:webs with other DID architectures