Comment on page
Method Specification for BSC
Decentralized identifiers (DIDs) are a new type of identifiers that enables verifiable, self-sovereign digital identity. This Binance DID method specification describes a new DID method, that is, Binance DID and defines how Binance Smart Chain stores Binance DIDs and their corresponding DID documents, and how to do CRUD operations on Binance DID documents.
The namestring that shall identify this DID method is:
A DID that uses this method MUST begin with the following prefix:
did:bnb. Per this DID specification, this string MUST be in lowercase.
The remainder of the DID, after the prefix, is its namespace-specific identifier specified below.
The namespace specific identifier is defined by the following ABNF:
bnb-did = "did:bnb:" bnb-specific-idstring
bnb-specific-idstring = 40*40HEXDIG
A valid Binance DID might be:
The following section outlines the DID operations for the
Binance DIDs reside on the Binance blockchain, and are managed via the Binance DID management smart contract.
For the sake of convenience, we refer to the Binance DID management smart contract as 'the registry'.
The Binance DID creation is implicit and it does not reqiure any interaction with the registry.
A subject who has a Binance address need not invoke any method and will automatically own a Binance DID that concatenating "did:bnb:" and the Binance address without a
For instance, Alice, who has a Binance address
0x1f4B9d871fed2dEcb2670A80237F7253DB5766De, will automatically become the subject of
Binance DID's associated DID document can be looked up by invoking the
getDocumentmethod of the registry.
To ensure the smart contract invocation result is trustworthy, the client could query a certain number of nodes and then compare the return values or deploy its own node.
The interface method for resolving a Binance DID document is defined as follows:
Besides this full-fledged resolver, the Binance Smart Chain provides other simple resolvers, such as fetching the
Binance DID Document Example
To update a Binance DID document, the corresponding Binance DID subject just need to invoke relevant functions.
For instance, the Binance DID subject can invoke the
addControllermethod to add a delegate which has the authorization to insert a new verification method into the
authenticationproperty of the delegated Binance DID.
The interface method for adding a delegate Binance DID is defined as follows:
delegateparameter specifies the to-be-added controller.
Similarly, the interface method for removing a delegate Binance DID is defined as follows:
delegateparameter specifies the to-be-removed controller.
Here we do not provide the full list of supported update methods and will provide specific documentation which lists all of the related APIs.
To delete (or deactivate) a Binance DID, it suffices to remove all the verification methods from its associated DID document and set a flag in the registry to indicate the DID is deactivated. In this case, there is no authentication method that can be used to authenticate the holder's identity.
The interface method for deactivating a Binance DID document is defined as follows:
didparameter specifies the to-be-deactivated Binance DID.
More importantly, the deletion of a Binance DID implies this DID cannot be registered or reactivated again.
There are several securities and privacy considerations that implementers would want to take into consideration when implementing this specification.
The current Binance DID implementation does not allow a Binance address to have multiple Binance DIDs, and if the Binance DID is deactivated, the corresponding Binance address cannot access the deactivated Binance DID. Hence, it loses all capability to perform operations on that Binance DID.
Since the delegates specified in the
controllerproperty can change the value of
authentication, they have the same privileges as the DID subject.
Binance DID documents should be limited to verification methods and service endpoints, and should not store any personal information.
Last modified 2yr ago