DID Operations

The authorizations to perform the operations rely on the properties of the blockchain that will reject the transactions which unlocking script will fail to unlock the addressed UTXOs. Both DID controller and DID subject must possess their own SECP256K1 keys which they MUST use to sign the DID transactions that are to be added to the DID’s chain of transactions.

When DID subject and DID controller are implemented as separate entities, they each use their own DID, which when resolved will yield their respective public keys. The DID subject’s DID document list the DID of its controller:

{
    "@context": "https://www.w3.org/ns/did/v1",
    "id": "did:bsv:1909a27e2f9c01dbc99f6391f77cd96032e00b92ff601584b7e227009055e6da",
    "controller": "did:bsv:a2fc941316adc10d680c98a06bf68da88ec513c658a9dc5ef837058064b588f9",
    "verificationMethod": [
        {
            "id": "did:bsv:1909a27e2f9c01dbc99f6391f77cd96032e00b92ff601584b7e227009055e6da#subject-key",
            "type": "JsonWebKey2020",
            "controller": "did:bsv:1909a27e2f9c01dbc99f6391f77cd96032e00b92ff601584b7e227009055e6da",
            "publicKeyJwk": {
                "kty": "EC",
                "x": "l5sYB-y78yE-n8Fc1d9pZeVFYhGD8qWoFRk-abyr0p4",
                "y": "XVcP352DcjrO374NW-4iNfUUWLLu_ZvcNhZtWPFURAg",
                "crv": "secp256k1"
            } } ],
    "authentication": [
        "did:bsv:1909a27e2f9c01dbc99f6391f77cd96032e00b92ff601584b7e227009055e6da#subject-key"
    ]
}

In SSI use, the DID document lists both public keys since the DID controller’s DID does not exist:

{
    "@context": "https://www.w3.org/ns/did/v1",
    "id": "did:bsv:a2fc941316adc10d680c98a06bf68da88ec513c658a9dc5ef837058064b588f9",
    "verificationMethod": [
        {
            "id": "did:bsv:a2fc941316adc10d680c98a06bf68da88ec513c658a9dc5ef837058064b588f9#subject-key",
            "type": "JsonWebKey2020",
            "controller": "did:bsv:a2fc941316adc10d680c98a06bf68da88ec513c658a9dc5ef837058064b588f9",
            "publicKeyJwk": {
                "kty": "EC",
                "x": "oA39rl7p8GjPi4oVJRhesnhm9M4RKl0_dWs6EjDSm84",
                "y": "l9j72B38c3VHlwk9-YtWyLovLFGU_Bkx1qa6DRLf5UQ",
                "crv": "secp256k1"
            }
        }
    ],
    "service": [
        {
            "id": "did:bsv:a2fc941316adc10d680c98a06bf68da88ec513c658a9dc5ef837058064b588f9#controller-website",
            "type": "LinkedDomains",
            "serviceEndpoint": "<service-endpoint-url>"
        }
    ],
    "authentication": [
        {
            "id": "did:bsv:a2fc941316adc10d680c98a06bf68da88ec513c658a9dc5ef837058064b588f9#auth",
            "type": "JsonWebKey2020",
            "controller": "did:bsv:a2fc941316adc10d680c98a06bf68da88ec513c658a9dc5ef837058064b588f9",
            "publicKeyJwk": {
                "kty": "EC",
                "x": "-femws1TMAIQZLWNuhglkF9N6RrJAIJA7Yk64CavSEA",
                "y": "BvoLuvdFvLv1p3j1myLZrhCBmYvoBHtp15ol_BB81Yk",
                "crv": "secp256k1"
            }
        }
    ]
}

8.3.1 DID Creation

To create DID, DID controller MUST publish two transactions to the blockchain:

• DID issuance transaction (see A.2.1 DID Issuance Transaction), and

• DID Document transaction (see A.2.2 DID Document Transaction) containing the first version of the DID document) It is the DID controller’s responsibility to provide funding to cover mining fees for those transactions. When the DID subject is acting as own controller (SSI) it MUST own and use, C0/PKC0 representing DID controller and S0/PKS0 representing DID subject.

8.3.2 DID Document Updates

To create a new version of DID document, DID controller must publish two transactions to the blockchain:

• DID funding transaction (see A.2.4 DID Funding Transaction) which provides funds to cover mining fees of this and a new DID document transaction.

• DID Document transaction (see A.2.2 DID Document Transaction) which publishes new version of DID document It is the DID controller’s responsibility to provide funding for DID funding transaction. While the DID funding transaction can be signed by either DID subject or DID controller, the DID document transaction itself must be signed by both. This ensures that both DID subject and DID controller agree on the new DID document contents.

8.3.3 DID Deactivation

To deactivate, or revoke a DID, either DID subject or DID controller MUST publish DID revocation transaction (see A.2.3 DID Revocation Transaction). The funds for this transaction are already available in the UTXO of the last transaction of the DID’s transaction chain.

8.3.4 DID Resolution

To resolve DID to the latest version of the DID document, DID resolver MUST:

• Fetch the blockchain transaction which transaction ID is the method specific identifier of DID, decoded from hexadecimal presentation to binary number and make it current.

• Fetch the transaction that spent UTXO 0 of the current transaction

• Check the transaction kind

  • If DID document transaction (see A.2.2 DID Document Transaction), check if current transaction’s UTXO 0 is unspent.

  • If yes, return the DID document as the result of the resolution

  • If no, make this transaction current and repeat from step 2

  • If DID funding transaction (see A.2.4 DID Funding Transaction) make this transaction current and repeat from step 2

  • If DID revocation transaction, return the last seen DID document as the result of the resolution and set deactivated property to true in DID document metadata and terminate

If versionId query is present, the algorithm must modify steps 3.1 to read:

• If DID document transaction check if its transaction ID matches the value of versionId query.

  • If yes, return the DID document as the result of the resolution

  • If no, check if the UTXO of this transaction is spent

    • If no, set error property of DID resolution metadata to notFound and terminate

    • If yes, mark transaction as current and repeat the step 2

Step 3.3 to read:

• If DID revocation transaction, set error property of DID resolution metadata to notFound and terminate.