Synopsis

DID PLC is a self-authenticating DID which is strongly-consistent, recoverable, and allows for key rotation. DID PLC relies on a central directory server to resolve the mutation conflicts and determine the latest state for any identity. Centralized services are prone to censorship. Additionally, centralized service providers may collude with the early owners of an identity to rewrite history, thereby altering the latest state of the identity. This RFC proposes an alternative registry service running on CKB, which stores operations log on CKB chain and relies on the CKB consensus to resolve the mutation conflicts. DKD PLC identities hosted on this new registry service can achieve the same level of decentralization and censorship-resistant ability as the CKB consensus.

This RFC will introduce DID PLC briefly first. Then the following chapters are organized by features that each chapter will propose the design for a new feature based on the prior chapter. To avoid interrupting the reading flow, the design decision choices will be explained in the appendix and is referenced by link like (a1).

Introduction to DID PLC

DID PLC identity is derived from the hash of its initial state. Following update operations reference a prior version of the identity state by hash. For any identity, the initial state and the chained update operations constitute a tree. Given an identity and an operations tree, users can verify that the operations tree is for the identity and any operation is authorized by a prior owner listed in the prior state. However, users cannot tell which leaf of the tree is the latest state of the identity. There's no safe and deterministic algorithm to determine the latest state. If users want to reach consensus, they have to trust a third-party service, such as the central directory server https://plc.directory/.

More details about DID PLC can be found in its specification.

Operations Chain

The basic version of the DID PLC Registry on CKB stores signed operations in cells. A script R is responsible to verify the operations.

Here is how a DID PLC operation cell looks like:

• data: signed operation encoded with DAG-CBOR. An alternative design is putting unsigned operations in data and signatures in transaction witness. However, saving signatures in cell data can make it easy to fetch the signed operations from the CKB chain.
• type script: R with args OP | did
  • OP: an integer tag to indicate that the script is used as the type script of an operation cell. It is encoded as a single byte and the value is 1.
  • did: the full string in utf-8 of the did identity, example: did:plc:ewvi7nxzyoun6zhxrhs64oiz.
• lock script: R without args.