Static
createEntry point for section 4.1 Create. See Btc1Create for implementation details.
A did:btc1 identifier and associated DID document can either be created deterministically from a cryptographic seed, or it can be created from an arbitrary genesis intermediate DID document representation. In both cases, DID creation can be undertaken in an offline manner, i.e., the DID controller does not need to interact with the Bitcoin network to create their DID.
See Btc1CreateParams for details.
Promise resolving to a CreateResponse object.
Static
getGiven the W3C DID Document of a did:btc1
identifier, return the signing verification method that will be used
for signing messages and credentials. If given, the methodId
parameter is used to select the
verification method. If not given, the Identity Key's verification method with an ID fragment
of '#initialKey' is used.
Parameters for the getSigningMethod
method.
DID Document to get the verification method from.
Optional
methodId?: stringOptional ID of the verification method to use for signing.
Promise resolving to the Btc1VerificationMethod object used for signing.
Static
resolveEntry point for section 4.2 Read. See Btc1Read for implementation details.
The read operation is executed by a resolver after a resolution request identifying a specific did:btc1 identifier is received from a client at Resolution Time. The request MAY contain a resolutionOptions object containing additional information to be used in resolution. The resolver then attempts to resolve the DID document of the identifier at a specific Target Time. The Target Time is either provided in resolutionOptions or is set to the Resolution Time of the request.
The DID to be resolved
Optional parameters for the resolution operation
Promise resolving to a DID Resolution Result
Static
updateEntry point for section 4.3 Update. See Btc1Update for implementation details.
An update to a did:btc1 document is an invoked capability using the ZCAP-LD data format, signed by a verificationMethod that has the authority to make the update as specified in the previous DID document. Capability invocations for updates MUST be authorized using Data Integrity following the bip340-jcs-2025 cryptosuite with a proofPurpose of capabilityInvocation.
The Update algorithm takes as inputs a btc1Identifier, sourceDocument, sourceVersionId, documentPatch, a verificationMethodId and an array of beaconIds. The sourceDocument is the DID document being updated. The documentPatch is a JSON Patch object containing a set of transformations to be applied to the sourceDocument. The result of these transformations MUST produce a DID document conformant to the DID Core specification. The verificationMethodId is an identifier for a verificationMethod within the sourceDocument. The verificationMethod identified MUST be a BIP340 Multikey. The beaconIds MUST identify service endpoints with one of the three Beacon Types SingletonBeacon, aCIDAggregateBeacon, and SMTAggregateBeacon.
Required parameters for the update operation.
The beacon IDs to announce the update
The btc1 identifier to be updated.
The DID document being updated.
The versionId of the source document.
The verificationMethod ID to sign the update
Promise resolving to void
Implements did:btc1 DID Method Specification. did:btc1 is a censorship resistant DID Method using the Bitcoin blockchain as a Verifiable Data Registry to announce changes to the DID document. It improves on prior work by allowing: zero-cost off-chain DID creation; aggregated updates for scalable on-chain update costs; long-term identifiers that can support frequent updates; private communication of the DID document; private DID resolution; and non-repudiation appropriate for serious contracts.
DidBtc1