Skip to content

did:ckb PDS

PDS (Personal Data Server) is a crucial component in AT Protocol, responsible for managing user data storage. This page provides a implementation guidance for the did:ckb PDS system, which extends the AT Protocol infrastructure to support the did:ckb DID method through integration with the CKB blockchain.

A formal specification for the did:ckb PDS can be found in the wip-03.

The resolveHandle API MUST support did:ckb identifiers. A PDS MAY query the CKB blockchain directly using the CKB Indexer RPC to locate DID Metadata Cells, or synchronize all live DID Metadata Cells locally by processing all interested transactions.

The resolution process involves parsing the method-specific identifier to construct appropriate search queries for Live Cells containing the target DID Metadata.

Operations on did:ckb requires building, signing and submitting CKB transactions. A PDS SHOULD hide the complexity to build CKB transactions from users.

It is RECOMMENDED to adopt a two-step procedure pattern:

did PDS

In the first step, the user submits an operation request to the PDS. The PDS uses the CKB SDK to construct a CKB transaction and returns the unsigned transaction to the user.

In the second step, the user must sign the transaction based on the used Lock Script, typically using a CKB wallet application. The user then submit back the signed transaction to the PDS. The PDS persistently attempts to submit the transaction to the CKB network until it either succeeds or fails.

To create CKB DIDs, users must coordinate with their PDS regarding who supplies the input capacity to cover the DID Metadata Cell storage cost.

  • If users provide the capacity, they must sign the creation transaction.
  • If the PDS covers the cost, it can sign and submit the transaction directly to the CKB network, as it holds the necessary signing authority.

In the latter case, the PDS must secure its creation API to prevent abuse.

The PDS should temporarily freeze input cells during creation procedures to prevent their use in other transactions. This avoids double-spending conflicts that only one transaction in a conflicting group will succeed. The PDS CAN split cells with large CKB capacity into small ones to allow concurrent creation requests.

Since DID operations involve submitting transactions to the CKB network, they are asynchronous by nature. Therefore, the PDS must implement a method for users to check the operation status.