This specification defines a DID method (did:doge) that supports DIDs based on the public Dogecoin blockchain. Dogecoin is an open-source is a cryptocurrency, blockchain, and payment system that is instant, fun, and free from traditional banking fees.

Introduction

Prior Work and Enhancements

We draw heavily from prior work by Christopher Allen and Kim Hamilton Duffy within the W3C Credentials Community Group on the BTCR DID Method due to strong architectural similarities between the Bitcoin and Dogecoin blockchains.

However, there are some key differences that enable new privacy-preserving benefits. Namely, the did:doge method-specific identifier is the Base58Check-encoded Dogecoin address itself, allowing for DID usage even in the absence of any public transaction histories and only relying upon them for rotation events for verification methods and service endpoints. This specification defines the resolution of the did:doge method-specific identifier to an optional "genesis" transaction for DID document updates, which then follows the linear transaction history "tip" in the same style of did:btcr using "update" transactions.

In summary, while did:btcr requires a cleared transaction prior to first use, did:doge does not, allowing users use of decentralized identifiers even if they do not own cryptocurrencies.

Core Concepts

Doge DID Scheme

The namestring that shall identify this DID method is: doge. A DID that uses this method MUST begin with the prefix did:doge. As per the DID specification, this string MUST be in lowercase.

The full Doge DID scheme is defined by the following ABNF:


doge-did    = "did:doge:" address
address     = "D" 33*33base58-char
base58-char = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /
              "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "J" / "K" /
              "L" / "M" / "N" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" /
              "W" / "X" / "Y" / "Z" /
              "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" /
              "k" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" / "u" /
              "v" / "w" / "x" / "y" / "z"

All Doge DID method-specific identifiers are Dogecoin addresses, which are Base58Check encoded P2PKH and P2SH prefixed by a "D".

Example Doge DID: did:doge:DH5yaieqoZN36fDVciNyRueRGvGLR3mr7L.

Implicit Resolution

Every Dogecoin address, whether it has a transaction on the public Dogecoin blockchain or not, is a valid did:doge by default. If a Dogecoin address does not have any did:doge genesis transactions, then a DID resolver MUST generate a default DID Document using the Dogecoin address as its only input into the following template, substituting the input for the placeholder [DOGECOIN_ADDRESS]:

{
    "@context": ["https://w3id.org/did", "https://w3id.org/doge/v1"],
    "id": "did:doge:[DOGECOIN_ADDRESS]",
    "publicKey": [
       {
            "id": "did:doge:[DOGECOIN_ADDRESS]#wow",
            "controller": "did:doge:[DOGECOIN_ADDRESS]",
            "type": "EcdsaSecp256k1RecoverySignature2020",
            "dogecoinAddress": "[DOGECOIN_ADDRESS]"
        },
        {
             "id": "did:doge:[DOGECOIN_ADDRESS]#vckey-0",
             "controller": "did:doge:[DOGECOIN_ADDRESS]",
             "type": "EcdsaSecp256k1RecoverySignature2020",
             "dogecoinAddress": "[DOGECOIN_ADDRESS]"
         }
    ],
    "authentication": ["#wow"],
    "assertionMethod": ["#vckey-0"]
}

A resolver MUST search the Dogecoin public blockchain exhaustively for did:doge genesis transactions as part of implicit resolution.

did:doge Genesis Transactions

To initiate key and service input rotations, a did:doge DID controller MUST sign and clear a transaction to the public Dogecoin blockchain conforming to the following requirements.

  1. The transaction MUST contain in the scriptSig within the txin at index 0 a valid P2PKH unlocking Script with a public key corresponding to the did:doge method-specific identifier when interpreted as a Dogecoin address.
  2. The transaction MAY contain other txin entries as necessary for paying transaction fees.
  3. The transaction MUST contain in the scriptPubKey within the txout at index 0 a valid P2PKH locking Script with the corresponding Dogecoin address's pubKeyHash as the recipient, specifically by substituting the publicKeyHash for the placeholder [DOGECOIN_ADDRESS_PKH] in the Script template: 
    OP_DUP
  OP_HASH160
    [DOGECOIN_ADDRESS_PKH]
OP_EQUALVERIFY
OP_CHECKSIG
  4. The transaction MUST contain in the scriptPubKey within the txout at index 1 the following Script exactly: 
    OP_RETURN OP_PUSHBYTES_49
  5468652054696d65732032372f4a616e2f32303231202744756d62204d6f6e657927204973206f6e2047616d6553746f70
    This unique value is meant to signify an intentful did:doge genesis transaction, and has been selected because it has not been used previously to this specification's existence.
  5. The transaction MAY contain other txout entries.

The did:doge genesis transaction is defined as the transaction matching the criteria above found on the public Dogecoin blockchain with the lowest block height, and in the case of multiple matching transactions in the same block, the most preceding transaction in the transaction list.

did:doge Update Transactions

To conduct key and service input rotations using did:doge update transactions for a DID, there must exist a corresponding did:doge genesis transaction as specified in the previous section. A did:doge update transaction MUST be produced in the manner described below and cleared on the public Dogecoin blockchain.

  1. The transaction MUST contain in the scriptSig within the txin at index 0 a valid P2PKH unlocking Script with a public key corresponding to the did:doge method-specific identifier when interpreted as a Dogecoin address. Furthermore, the txin at index 0 MUST refer to the OutPoint of of a valid did:doge genesis transaction or valid did:doge update transaction.
  2. The transaction MAY contain other txin entries as necessary for paying transaction fees.
  3. The transaction MUST contain in the scriptPubKey within the txout at index 0 a P2PKH locking Script with the next did:doge active keypair's corresponding pubKeyHash as the recipient, specifically by substituting the publicKeyHash for the placeholder [NEXT_ACTIVE_KEY_PKH] in the Script template: 
    OP_DUP
  OP_HASH160
    [NEXT_ACTIVE_KEY_PKH]
OP_EQUALVERIFY
OP_CHECKSIG
    The next did:doge active keypair MAY be the current did:doge active keypair.
  4. The transaction MUST contain in the scriptPubKey within the txout at index 1 the following Script template, substituing a desired service endpoint URI encoded as hex (no longer than 79 bytes) for [SERVICE_ENDPOINT_URI] and the decimal length of the URI in bytes for [NUM_BYTES]: 
    OP_RETURN OP_PUSHBYTES_[NUM_BYTES] [SERVICE_ENDPOINT_URI]
    If no service endpoint is desired, an empty value MAY be chosen for [SERVICE_ENDPOINT_URI]. The OP_RETURN instruction MUST be included, otherwise this transaction will be considered a did:doge deactivation transaction instead, permanently and irreversibly deactivating the DID.
  5. The transaction MAY contain other txout entries.

did:doge Deactivation Transactions

To deactivate a DID permanently and irreversibly, there must first exist a corresponding did:doge genesis transaction as specified in the previous section. There MAY also exist did:doge update transactions. To deactivate the DID, a deactivation transaction MUST be produced in the manner described below and cleared on the public Dogecoin blockchain.

  1. The transaction MUST contain in the scriptSig within the txin at index 0 a valid P2PKH unlocking Script with a public key corresponding to the did:doge method-specific identifier when interpreted as a Dogecoin address. Furthermore, the txin at index 0 MUST refer to the OutPoint of of a valid did:doge genesis transaction or valid did:doge update transaction.
  2. The transaction MAY contain other txin entries as necessary for paying transaction fees.
  3. The transaction MAY contain other txout entries. However, the transaction MUST NOT contain the Script instruction OP_RETURN within the scriptPubKey of any of its txout entries.

Additional Terminology

The following did:doge update transaction with respect to a did:doge genesis transaction or did:doge update transaction is defined as the conforming did:doge update transaction on the public Dogecoin blockchain that uses the current transaction's txout at index 0 as its txin at index 0.

The did:doge active update transaction is the last transaction obtained by starting at a did:doge genesis transaction or did:doge update transaction and recursively identifying the following did:doge update transaction until none exists.

The did:doge active keypair is the corresponding keypair to the signature produced via private key signing of the did:doge active update transaction, or the corresponding keypair to the DID method-specific identifier if no update transactions exist.

The did:doge active service endpoint is the parameter of OP_RETURN in the scriptPubKey of the txout at index 1 of the did:doge active update transaction, or it is empty if no update transactions exist or the OP_RETURN has no following data.

Operations

Create (Register)

Doge DIDs exist per each Dogecoin address by default.

However, to enable key rotation and specification of a service endpoint, the following steps MUST be followed:

  1. Ensure no valid did:doge genesis transactions exist.
  2. Construct a did:doge genesis transaction for desired DID as described in Section 2.3.

Read (Resolve)

To resolve a did:doge DID, the following steps MUST be followed:

  1. Search the public Dogecoin blockchain exhaustively for a did:doge genesis transaction as defined in Section 2.3.
  2. If the did:doge genesis transaction does not exist, then resolve the DID document implicitly as specified in 2.2. At this point, resolution is considered to be completed successfully and any additional steps MUST NOT be followed.
  3. If the did:doge deactivation transaction exists, then the DID is considered deactivated, resolution is considered to be a failure, and any additional steps MUST NOT be followed.
  4. Construct a DID document substituting the Dogecoin address corresponding to the did:doge active keypair (as defined in 2.5) in the template specified within 2.2.
  5. If the did:doge active service endpoint exists, define a single service endpoint within the DID document, populating the id with did:doge:[DOGECOIN_ADDRESS]#service (where [DOGECOIN_ADDRESS] is the Dogecoin address corresponding to the method-specific identifier), type with DidDogeService, and serviceEndpoint of the did:doge active service endpoint.

Update (Replace)

To update a did:doge DID document, the following steps MUST be followed.

  1. Ensure that a did:doge genesis transaction exists.
  2. Construct a did:doge update transaction as described in 2.4 referencing the did:doge active update transaction, or the did:doge genesis transaction if none exists, in its txin at index 0.

Delete (Revoke)

To deactivate a did:doge DID, the following steps MUST be followed.

  1. Ensure that a did:doge genesis transaction exists.
  2. Construct a did:doge deactivation transaction as described in 2.5 referencing the did:doge active update transaction, or the did:doge genesis transaction if none exists, in its txin at index 0.

Security & Privacy

Security Considerations

DID method specifications MUST include their own Security Considerations sections. This section MUST consider all the requirements mentioned in section 5 of [RFC3552] (page 27) for the DID operations defined in the specification, including eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle. Potential denial of service attacks MUST be identified as well.

A full list of requirements for this section may be found at W3C Decentralized Identifiers 7.3

Privacy Considerations

DID method specifications MUST include their own Privacy Considerations sections to discuss any subsection of section 5 of [RFC6973] that could apply in a method-specific manner. The subsections to consider are: surveillance, stored data compromise, unsolicited traffic, misattribution, correlation, identification, secondary use, disclosure, exclusion.

A full list of requirements for this section may be found at W3C Decentralized Identifiers 7.4

Reference Implementations

Spruce Systems, Inc. is developing a referencing implementation in Rust at github.com/spruceid/did-doge.

Resources