A command-line tool for creating and managing Decentralized Identifiers (DIDs) using the Cryptographic Event Log (CEL) method. This tool provides an interactive REPL (Read-Eval-Print Loop) for working with did:cel identifiers, which use a witness-based architecture to maintain a cryptographically verifiable history of DID document operations.

The did:cel method is a fully decentralized DID method that doesn't depend on blockchains, centralized registries, or any single point of control. Instead, it uses cryptographic event logs with independent witness attestations to create tamper-evident audit trails for DID operations.

• Node.js (v18 or higher recommended)
• npm (comes with Node.js)

npm install

To start the interactive REPL:

./didcel

You can execute one or more commands and then enter interactive mode:

./didcel -c "create" -c "witness" -c "save" -c "quit"

To run in interactive mode, do the following:

./didcel

Once in the REPL, you'll see a did:cel> prompt. The following commands are available:

Displays help information about available commands.

Usage:

did:cel> help

Description: Shows a list of all available commands with brief descriptions.

Creates a new DID document with an initial verification method.

Usage:

did:cel> create

Description: Generates a new did:cel DID document with a self-certifying identifier derived from the document's cryptographic hash. Creates an initial assertion method using a P-256 elliptic curve key pair and initializes a Cryptographic Event Log (CEL) to track the DID's history. The DID identifier is generated by hashing the canonicalized DID document using SHA3-256.

Output: Displays the created DID identifier (e.g., did:cel:zW1jPC3ViLfgPJX6KaPMhymin3LpATUgYTS7N58FLHtQ4HE)

Adds a new verification method or service to the current DID document.

Usage:

did:cel> add <property> <type>

Parameters:

• <property>: The verification relationship to add to. Choices:

  • authentication - For authentication purposes
  • assertionMethod - For making assertions
  • capabilityDelegation - For delegating capabilities
  • capabilityInvocation - For invoking capabilities
  • keyAgreement - For key agreement protocols
  • service - For service endpoints

• <type>: The type of verification method or service. Choices:

  • eddsa - EdDSA signature scheme (not yet implemented)
  • ecdsa - ECDSA signature scheme with P-256 curve
  • bbs - BBS+ signatures (not yet implemented)
  • FileService - File service endpoint (not yet implemented)

Description: Generates a new cryptographic key pair and adds it to the specified verification relationship in the DID document. Currently, only ECDSA verification methods are supported. The DID document is modified in-place but changes are not committed to the Cryptographic Event Log until you run the update command.

Example:

did:cel> add authentication ecdsa

Output: Confirmation message indicating the verification method was added.

Lists the contents of the DID document.

Usage:

did:cel> ls [suffix]

Parameters:

• [suffix] (optional): The last several characters of an identifier to display details for.

Description:

• Without arguments: Displays a summary of the DID document, showing the DID identifier and abbreviated listings of all verification methods and services.
• With a suffix: Shows detailed JSON representation of the specific object whose identifier ends with the provided suffix.

Examples:

did:cel> ls
did:cel:zW1jPC3ViLfgPJX6KaPMhymin3LpATUgYTS7N58FLHtQ4HE
  assertionMethod: Multikey#zDn...T9UV
  authentication: MultikeyDid:...8j4K

did:cel> ls T9UV
{
  "id": "#zDnaei5odivPwAt8q8QFF1cKCtz6gMkVpb9PBacKBzUNcT9UV",
  "type": "Multikey",
  "controller": "did:cel:zW1jPC3ViLfgPJX6KaPMhymin3LpATUgYTS7N58FLHtQ4HE",
  "publicKeyMultibase": "zDnaei5odivPwAt8q8QFF1cKCtz6gMkVpb9PBacKBzUNcT9UV"
}

Sets an expiration timestamp on a verification method.

Usage:

did:cel> expire <suffix>

Parameters:

• <suffix>: The last several characters of the verification method identifier to expire.

Description: Adds an expires property to the specified verification method with the current timestamp in ISO 8601 format (YYYY-MM-DDTHH:MM:SSZ). This marks the verification method as expired, though it remains in the DID document. Changes take effect immediately in the local DID document but are not committed to the Cryptographic Event Log until you run the update command.

Example:

did:cel> expire T9UV

Output: Confirmation message with the expiration timestamp.

Removes a verification method or service from the DID document.

Usage:

did:cel> remove <suffix>

Parameters:

• <suffix>: The last several characters of the identifier to remove.

Description: Searches through all arrays in the DID document (verification relationships and services) and removes the object whose identifier ends with the specified suffix. The object is immediately removed from the local DID document, but the change is not committed to the Cryptographic Event Log until you run the update and witness commands.

Example:

did:cel> remove T9UV

Output: Confirmation message showing the removed object's full identifier.

Updates the cryptographic event log with the latest DID document changes.

Usage:

did:cel> update

Description: Performs a two-phase operation to record changes to the Cryptographic Event Log:

1. Update Proof: Regenerates the cryptographic proof on the DID document using the first assertion method key (created during the create command). This signs the current state of the DID document.

2. Append Event: Creates a new update event in the Cryptographic Event Log that is hash-linked to the previous event. The hash of the previous event is computed using SHA3-256 and encoded in base58-btc format, then stored in the previousEvent property of the new event.

This creates an immutable, verifiable chain of events. After running update, you should run the witness command to obtain independent attestations from witness services.

Note: This command does not display output but prepares the event log for witnessing.

Obtains cryptographic attestations from witness services for the latest event.

Usage:

did:cel> witness

Description: Generates witness proofs for the most recent event in the Cryptographic Event Log. By default, the tool contacts three independent witness services (red, green, and blue witnesses), each of which:

1. Validates the event
2. Creates a cryptographic proof (data integrity proof using ecdsa-jcs-2019)
3. Returns the proof as an attestation

These witness attestations provide:

• Temporal anchoring: Proof of when the event occurred
• Independent validation: Third-party verification of the event
• Distributed trust: No single witness can compromise the system

The witness proofs are attached to the event structure in the Cryptographic Event Log, creating a fully attested and verifiable history of DID operations.

Output: Confirmation message when witness proofs are complete.

Saves the Cryptographic Event Log to a file.

Usage:

did:cel> save [filename]

Parameters:

• [filename] (optional): The name of the file to save to. Defaults to did.cel if not specified.

Description: Writes the complete Cryptographic Event Log (CEL) to a JSON file. The file contains the entire history of DID operations, including:

• Create and update events
• All witness attestations
• Hash-linked event chain
• Complete DID document state at each event

The JSON is formatted with keys ordered for readability (@context, id, type, cryptosuite, previousEvent first, then alphabetically). This file can later be loaded to reconstruct the DID's complete history and verify the integrity of the event chain.

Example:

did:cel> save my-did.cel
Wrote to my-did.cel

Loads a DID from a cryptographic event log file.

Usage:

did:cel> load

Description: ⚠️ Not yet implemented. This command will eventually load a previously saved Cryptographic Event Log from a file, reconstruct the DID document state, and verify the integrity of the event chain and witness attestations.

Exits the REPL without saving.

Usage:

did:cel> quit

Description: Terminates the interactive session immediately. Any unsaved changes to the DID document or Cryptographic Event Log will be lost. Make sure to run the save command before quitting if you want to persist your work.

Here's a common workflow for creating and managing a DID:

# 1. Start the REPL
./didcel

# 2. Create a new DID
did:cel> create

# 3. Add additional verification methods
did:cel> add authentication ecdsa
did:cel> add assertionMethod ecdsa

# 4. View the current state
did:cel> ls

# 5. Update the event log with changes
did:cel> update

# 6. Get witness attestations
did:cel> witness

# 7. Save the complete event log
did:cel> save

# 8. Exit
did:cel> quit

The DID CEL tools implement the did:cel DID method, which consists of:

• Self-certifying identifiers: DID identifiers derived from cryptographic hashes of the initial DID document
• Cryptographic Event Log (CEL): A hash-linked chain of events recording all DID operations
• Witness attestations: Independent cryptographic proofs from witness services providing temporal evidence and distributed validation
• Data Integrity Proofs: ecdsa-jcs-2019 cryptographic signatures on both DID documents and events

• didcel - Main executable script and REPL implementation
• lib/cel.js - Cryptographic Event Log management (create, update, witness)
• lib/didcel.js - DID document operations (create, add verification methods, update proofs)
• lib/witness.js - Witness service for generating attestation proofs
• lib/utils.js - Utility functions for JSON-LD formatting and object manipulation

• Secret Keys: The tool stores secret keys in memory during the session. Keys are lost when you exit the REPL unless you implement your own key management.
• Witness Keys: Currently uses hardcoded witness keys for development/testing. In production, witnesses should be independent services with securely managed keys.
• File Storage: Saved CEL files contain only public information (DID documents and proofs), not secret keys.

BSD-3-Clause

This is an experimental implementation of the did:cel DID method. Contributions and feedback are welcome.

• DID CEL Specification - Technical specification for the did:cel method
• W3C Decentralized Identifiers (DIDs) v1.0 - Core DID specification
• Verifiable Credential Data Integrity - Data Integrity Proofs specification