Introduction

Orb implements the following specifications: did:orb, Activity Anchors. The did:orb method is based on the Sidetree specification and Activity Anchors is based on the ActivityPub, ActivityStreams, and Linkset specifications.

Services

A typical Orb domain consists of the following services:

1. Orb instance (multiple instances may be running for redundancy scalability)

2. Document database (AWS DocumentDB or MongoDB)

3. AMQP message broker (RabbitMQ)

4. Key Management Service (Aries KMS)

5. Verifiable Credential Transparency (VCT) (Google Trillian)

6. IPFS (optional)

Components

The diagram below displays the components that make up the Orb server.

The section below describes a typical DID creation flow that gives an overview of the component interactions. More detailed descriptions are provided in the various sections of this document.

DID Creation Flow

Creation and resolution of DIDs involve two REST endpoints: Operation Writer and DID Resolver. The Operation Writer endpoint accepts Sidetree operations to create, update, deactivate and recover DIDs. The DID Resolver endpoint reads the Sidetree operations for a DID suffix and returns a DID document.

When an operation is posted to the Operation Writer, a message is posted to the AMQP operation queue which is consumed by the Batch Writer. The Batch Writer stores the operation and cuts a batch when the maximum batch size is reached, or the batch times out. The batch contains the DID operations that were posted since the last batch was cut. The batch is written to the Content Addressable Storage (CAS) (which can be in a local storage or IPFS) and an anchor linkset is created. The anchor linkset contains the DIDs from the batch and a verifiable credential containing a proof from the local server. The verifiable credential is added to the local VCT. An AnchorEvent (which wraps the linkset) is created and posted via an Offer activity to the Outbox. The Offer activity is stored in the Activities database and an HTTP request (signed by KMS) is sent to the Inbox of one or more Orb servers in the witnesses collection.

Proofs from witnessing servers are received in the Inbox as Accept activities. After the Inbox verifies the HTTP signature of the request, the Accept activity is stored in the Activities database and the proof is sent to the Witness Proof Handler. When this handler determines that enough proofs have been received (according to the Witness Policy), a new anchor linkset is constructed with the gathered proofs. The anchor linkset is written to CAS and the hash of the anchor linkset is posted to the anchor queue for processing.

The Observer consumes the anchor linkset hash from the queue and reads the anchor linkset (along with the corresponding Sidetree operations) from CAS, and processes/stores each operation to the operations database.

A client sends a request to the DID Resolver endpoint to retrieve the DID document for the created/updated operation. The DID Resolver retrieves all operations related to the provided DID suffix from the Operations database, applies the operations, and returns the DID document.