Skip to main content

DID Method Specification: did:dfos

Specification Status: Draft Latest Draft: 2025-11-12 Editors: Metalabel Platform Team

Abstract​

This document specifies the did:dfos decentralized identifier method. The did:dfos method enables creation of self-sovereign, cryptographically-verifiable identifiers anchored to content-addressed operation logs. DIDs are permanent identifiers derived from genesis operations, with key management through signed update operations forming an immutable chain.

Status of This Document​

This specification is a draft. It may be updated, replaced, or obsoleted at any time.

Terminology​

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

DID: Decentralized Identifier, as defined in the W3C DID specification.

CID: Content Identifier, as defined in the IPLD specification.

DAG-CBOR: Deterministic CBOR encoding for content addressing.

Operation Log: Ordered sequence of cryptographically signed operations that define an identity's state.

Method Name​

The method name SHALL be dfos.

Method-Specific Identifier​

The method-specific identifier is a 22-character deterministic hash derived from the genesis operation CID.

DID Syntax​

did-dfos = "did:dfos:" method-specific-id
method-specific-id = 22*22(ALPHA / DIGIT)  ; 22 chars from alphabet "2346789acdefhknrtvz"

Example​

did:dfos:r7z9c4kfhne2t38va6d9kn

The method-specific identifier is derived by:

  1. Computing the CID of the genesis operation (DAG-CBOR encoded)
  2. Hashing the CID bytes with SHA-256
  3. Encoding 22 characters using a custom alphabet (2346789acdefhknrtvz)

This produces shorter, human-readable identifiers while preserving cryptographic binding to the genesis operation.

DID Operations​

Create​

To create a did:dfos identifier:

  1. Generate one or more secp256k1 keypairs
  2. Construct a genesis operation (see Genesis Operation)
  3. Canonically encode the operation as DAG-CBOR
  4. Compute the CID of the encoded bytes
  5. Sign the CID bytes using a controller key
  6. Hash the CID bytes with SHA-256 and encode using the custom alphabet
  7. The resulting DID is did:dfos:{encoded-hash}

The genesis operation establishes the initial key set and MUST include at least one controller key.

Read (Resolve)​

DID resolution reconstructs the current key state by:

  1. Retrieving the operation log starting from the genesis operation
  2. Validating each operation according to Verification Rules
  3. Applying operations sequentially to derive the current key state
  4. Returning the DID Document representing the current state

Update​

Identities are updated by creating new update operations signed by current controller keys. Update operations:

  • MUST reference the previous operation via previousCID
  • MUST be signed by a key in the current controller key set
  • MUST have a createdAt timestamp after the previous operation
  • MAY add, remove, or replace keys in any usage category

Key rotation is performed by publishing an update operation with the new key set.

Deactivate (Brick)​

An identity MAY be permanently deactivated by publishing an update operation that:

  • Sets all key arrays (authKeys, assertKeys, controllerKeys) to empty
  • MUST be signed by a current controller key

Once bricked, no further operations are possible. This action is irreversible.

Key Types and Usage​

Each identity maintains three categorized key sets:

Authentication Keys (auth)​

Used for authentication operations. Authentication keys prove control of the identity for purposes such as:

  • Session establishment
  • API authentication
  • Service login

Assertion Keys (assert)​

Used for signing assertions and content. Assertion keys create verifiable authorship for:

  • Catalog operations
  • Content creation
  • Profile updates

Controller Keys (controller)​

Used for identity management operations. Only controller keys can sign operations that modify the key set itself.

Note: A single key MAY appear in multiple usage categories. Key material can serve multiple purposes simultaneously.

Data Structures​

Public Key​

interface PublicKey {
  id: string; // Unique identifier for this key
  type: 'secp256k1-multibase-encoded';
  publicKeyMultibase: string; // Multibase-encoded public key bytes
}

Unsigned Operation​

interface UnsignedOperation {
  type: 'update';
  previousCID: string | null; // null for genesis, CID of previous for updates
  authKeys: PublicKey[];
  assertKeys: PublicKey[];
  controllerKeys: PublicKey[];
  createdAt: string; // ISO 8601 datetime
}

Signed Operation​

interface SignedOperation {
  cid: string; // CID of the unsigned operation
  unsigned: UnsignedOperation;
  signatureMultibase: string; // Multibase-encoded signature
}

Genesis Operation​

The genesis operation is the first operation in an identity's log and determines the DID.

Requirements:

  • type MUST be 'update'
  • previousCID MUST be null
  • controllerKeys MUST contain at least one key
  • authKeys and assertKeys MAY be empty or MAY contain keys
  • createdAt MUST be a valid ISO 8601 timestamp

Example:

const genesisOp: UnsignedOperation = {
  type: 'update',
  previousCID: null,
  authKeys: [key],
  assertKeys: [key],
  controllerKeys: [key],
  createdAt: '2025-10-24T12:00:00.000Z',
};

The CID of this operation, when encoded as DAG-CBOR and hashed, becomes the DID:

did:dfos:r7z9c4kfhne2t38va6d9kn

Verification Process​

To verify an operation log:

  1. Schema Validation: Each operation MUST conform to the operation schema
  2. Genesis Check: The first operation MUST have previousCID: null and at least one controller key
  3. Chain Integrity: Each operation's previousCID MUST match the CID of the previous operation
  4. Temporal Ordering: Each operation's createdAt MUST be strictly after the previous operation's timestamp
  5. Key Consistency: Key IDs MUST map to the same public key material throughout the log
  6. Signature Verification: Each operation MUST be signed by a key in the controller set at the time of signing
  7. State Application: Apply each operation's key changes sequentially
  8. Deactivation Detection: If controller keys become empty, the identity is marked as bricked (deactivated)

Implementations MUST reject operation logs that fail any verification step.

Cryptographic Algorithms​

Signatures​

  • Algorithm: ECDSA with secp256k1 curve
  • Hash: SHA-256
  • Encoding: Multibase (base58btc)

Content Addressing​

  • Encoding: DAG-CBOR (IPLD canonical encoding)
  • Hash: SHA-256
  • CID Version: CIDv1
  • Multibase: base58btc

Security Considerations​

Key Management​

Controller keys have ultimate authority over the identity. Implementations SHOULD:

  • Store controller keys in secure, encrypted storage
  • Use hardware security modules (HSMs) when possible
  • Implement key backup and recovery procedures
  • Rotate keys regularly to limit exposure

Operation Log Integrity​

The operation log forms an immutable chain. Implementers MUST:

  • Validate the entire chain before accepting any operation
  • Reject logs with broken chains or invalid signatures
  • Store operations in tamper-evident storage

Timestamp Trust​

Operation timestamps create a temporal ordering. Implementations SHOULD:

  • Use trusted time sources (NTP servers)
  • Account for clock skew in validation
  • Reject operations with timestamps in the future

Brick Permanence​

Bricking an identity is irreversible. Implementations MUST:

  • Warn users before bricking operations
  • Ensure controller key backups exist
  • Provide no recovery mechanism after bricking

Operation Log Size​

To prevent unbounded growth, implementations MAY limit operation logs to a maximum number of operations (e.g., 100). Key rotation strategies SHOULD account for this limit.

Privacy Considerations​

DIDs themselves do not contain personally identifiable information. However:

  • Operation logs MAY reveal key rotation patterns
  • Temporal analysis of operations MAY reveal usage patterns
  • Content signed with assertion keys creates a public attribution trail

Implementations SHOULD allow users to:

  • Create multiple identities for different contexts
  • Understand the permanent nature of DID-anchored content
  • Control when and how their DIDs are disclosed

Usage in DFOS​

User Identities​

User accounts create did:dfos identifiers for each identity. Users MAY have multiple identities under a single account for different contexts.

Space Identities​

Collaborative spaces create their own did:dfos identifiers. Space identity is distinct from member identities, allowing spaces to persist independently.

Content Attribution​

Catalog operations (profiles, posts, etc.) reference the authoring DID via createdByDID. This creates cryptographically verifiable attribution.

Conformance​

An implementation conforms to this specification if it:

  1. Generates DIDs according to the specified format
  2. Creates and signs operations using the specified algorithms
  3. Verifies operation logs according to the verification process
  4. Rejects invalid operations as specified
  5. Implements key rotation through update operations
  6. Supports identity deactivation (bricking)

References​