# Specification Overview

## 3.1 Prerequisites

According to [W3C specifications](https://www.w3.org/TR/did-core/) and as a requirement for the deigns of this method, the DID needs to fulfil the basic premise principles listed below:

* A Permanent identifier (URN).
* Be cryptographically verifiable.
* Be decentralised (no central registration authority required).
* Easy and economical to create.
* The DID is always required to resolve (associated with) to a DID Document.
* The DID Subject is not always the administrator of its DID. It depends on use case scenario.

Similarly, the DID Document needs to satisfy the following:

* The DID Document needs to be publicly available.
* The DID Document must contain:
  * One or more keys to authenticate the DID subject.
  * One or more Services associated with DID subject.
  * Additional metadata like digital signatures, timestamps, and other cryptographic proofs.

## 3.2 UTXO DID Method

In this section we present an overview of the DID method. Our proposal introduces a new Decentralized Identifier (DID) method that links a UTXO and the DID with the public key of the subject and manages the DID status and revocation through transaction spending checks. We use the BSV Blockchain as the verifiable data registry.

The UTXO DID method uses the following method name: **bsv**

## **3.2.1 The DID**

The issuance of a DID using this method is performed by publishing a blockchain transaction:**Tx0**. This transaction has a single input and a single output. The transaction ID (**TxID**) becomes the DID for the subject. The **TxID** can be easily calculated by either controller or subject and, because of the properties of blockchain it would never be repeated. It is also easily recognisable by independent third-party platforms, such as blockchain explorers.

*1. Representation of a DID as per W3C specification*

```
DID:example:123456789abcdefghi
```

Where fields are broken down as follows:

| Scheme | DID Method | DID Method-Specific Identifier |
| ------ | ---------- | ------------------------------ |
| DID:   | example:   | 123456789abcdefghi             |

*2. Representation of a DID using UTXO method*

```
DID:bsv:21f2dae26817752b8f92c51a49a898e287ad133a4e7ed64b4909f7b62f0bbb6e
```

Where fields are broken down as follows:

| Scheme | DID Method | DID Method-Specific Identifier                                   |
| ------ | ---------- | ---------------------------------------------------------------- |
| DID:   | Blockchain | TXID                                                             |
| DID:   | bsv:       | 21f2dae26817752b8f92c51a49a898e287ad133a4e7ed64b4909f7b62f0bbb6e |

## **3.2.2 The DID Document**

The DID Document is published via a subsequent transaction **Tx1** that spends the output of **Tx0**. The relationship between the DID, the DID document, and the blockchain transactions is given in Figure 1. The transaction **Tx1** contains a single input and a single output. The output contains the locking script, the DID Document and the funds covering the mining fee of the next transaction. **Tx1** spending the output of **Tx0** allows an external observer to conclude that there is a link between both blockchain transactions. The status of **Tx1** output indicates the latest status of the DID Document.

<div data-full-width="false"><figure><img src="/files/Rthbomlx2oJ3hvrVrdXV" alt=""><figcaption></figcaption></figure></div>

> *Figure 1: DID UTXO Status*

## **3.2.2.1 The DID Document Data Model**

Our current implementation uses [W3C DID Document Data Model](https://www.w3.org/TR/did-core/#data-model) and is referenced in the DID Document. Below is a representative example of a DID Document data model.

```
"@context": "https://www.w3.org/ns/did/v1", 
  "id": "did:bsv:5909468ac49f960e191faba2dd7da60bd1775ccf59e90b8390c971d04741b710",
  "controller": "did:bsv:b6333300b727ae4d355ffe2fee06ebe9ed5565cb1321e02637fa971bd523272e",
  "verificationMethod": 
         [ { 
             "id": "did:bsv:5909468ac49f960e191faba2dd7da60bd1775ccf59e90b8390c971d04741b710#subject-key",
             "type": "JsonWebKey2020", 
             "controller": "did:bsv:5909468ac49f960e191faba2dd7da60bd1775ccf59e90b8390c971d04741b710",
             "publicKeyJwk": 
              { 
                  "kty": "EC", 
                  "x": "xJxFTwL183Hmz19WnLAgBa1wpljMuaYk_rBnAKlol-g", 
                  "y": "585wM9i1dGHr6qgL5NG5N2EAxel3Son9HpkGpl-hY-I", 
                  "crv": "secp256k1" 
              } } ]
  "authentication": [ "did:bsv:5909468ac49f960e191faba2dd7da60bd1775ccf59e90b8390c971d04741b710#subject-key" ] 
```


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.teranode.group/tng-identity-documentation/did/bsv-did-method-specifications/specification-overview.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.