@siriusid-next/did-method-sirius v0.1.0-unstable.11

@sidetree/element

This package contains an implementation of Sidetree Core, using Sirius Chain and IPFS

Usage

yarn add @siriusid-next/did-method-sirius

Development

yarn install
yarn test

SiriusID DID Method Specification

SiriusID is an implementation of the Sidetree Protocol that uses the Sirius Chain blockchain as the ledger layer and IPFS as the content-addressable storage layer

For more information, see the sidetree spec

Method syntax

The namestring identifying this did method is sirius

A DID that uses this method MUST begin with the following prefix: did:sirius. Per the DID specification, this string MUST be in lowercase.

An additional optional network specific identifier may be added as such

• did:sirius:testnet:EiBOWH8368BI9NSaVZTmtxuqwpfN9NwAwy4Z95_VCl6A9g
• did:sirius:mainnet:EiBOWH8368BI9NSaVZTmtxuqwpfN9NwAwy4Z95_VCl6A9g
• did:sirius:EiBOWH8368BI9NSaVZTmtxuqwpfN9NwAwy4Z95_VCl6A9g

By default, if the network specific identifier is not present, then the default is testnet. The default may change in the future once mainnet is supported.

The remainder of a DID after the prefix, called the did unique suffix, MUST be SHA256 hash of the encoded create payload (see below)

Format and Encoding

Base64URL encoded Multihashes are used.

CRUD Operations

Element supports the 4 CRUD operations. Each operation is performed by submitting a Sidetree operation from Sidetree client to a Sidetree node.

A Sidetree payload looks like this:

{
  "protected": "Encoded header.",
  "payload": "Encoded payload of the operation.",
  "signature": "Encoded signature."
}

Create

The payload for a create operation MUST be a did document model, that is to say the did document without the id property, and without the controller property for the publicKeys.

A did document model should look like this

{
  "@context": "https://w3id.org/did/v1",
  "publicKey": [
    {
      "id": "#primary",
      "type": "JsonWebKey2020",
      "publicKeyJwk": {
        "crv": "Ed25519",
        "x": "2UR1Cz7qUSuoc4b4xw4JNJto1PD4IcTNC28Xdwrbdug",
        "kty": "OKP"
      }
    },
    {
      "id": "#secondary",
      "type": "JsonWebKey2020",
      "publicKeyJwk": {
        "crv": "Ed25519",
        "x": "2UR1Cz7qUSuoc4b4xw4JNJto1PD4IcTNC28Xdwrbdug",
        "kty": "OKP"
      }
    }
  ]
}

Read

In order to resolve a did into a did document, one MUST use the resolve API of an SiriusID node.

See the Sidetree spec for more details on how a read operation is performed by an SiriusID node

Update

The payload for an update operation MUST be of the following format:

{
  "didUniqueSuffix": "The did unique suffix (the did without the did:elem part)",
  "previousOperationHash": "The operation hash of the latest CREATE or UPDATE operation returned by the Sidetree client",
  "patches": [
    "a list of",
    "supported",
    "patches to apply",
    "to the did document"
  ],
}

The list of patches currently supported is:

• add-public-keys
• add-authentication
• remove-authentication
• add-assertion-method
• remove-assertion-method
• add-capability-delegation
• remove-capability-delegation
• add-capability-invocation
• remove-capability-invocation
• add-key-agreement
• remove-key-agreement
• add-service-endpoint
• remove-service-endpoint

An update payload SHOULD look like this

{
  "didUniqueSuffix": "EiDV20SIx04vrz-2iea-UE7G6y7eRwo7lnCKJNYTfZ3rcQ",
  "previousOperationHash": "EiAZSwY92kqd5oeaWULYe2EjZc6TxTL9yHWgWOVKJraw9w",
  "patches": [
    {
      "action": "add-public-keys",
      "publicKeys": [
        {
          "id": "#newKey2",
          "usage": "signing",
          "type": "JsonWebKey2020",
          "publicKeyJwk": {
                "crv": "Ed25519",
                "x": "2UR1Cz7qUSuoc4b4xw4JNJto1PD4IcTNC28Xdwrbdug",
                "kty": "OKP"
            }
        },
        {
          "id": "#newKey3",
          "usage": "signing",
          "type": "JsonWebKey2020",
          "publicKeyJwk": {
                "crv": "Ed25519",
                "x": "2UR1Cz7qUSuoc4b4xw4JNJto1PD4IcTNC28Xdwrbdug",
                "kty": "OKP"
            }
        }
      ]
    },
    {
      "action": "remove-public-keys",
      "publicKeys": [
        "#primary"
      ]
    }
  ]
}

Delete

The payload for a DELETE operation MUST be:

{
  "didUniqueSuffix": "The did unique suffix (the did without the did:elem part)"
}

Security and privacy considerations

A Sidetree did document need not contain a proof property. Indeed, all operations are authenticated with the signature field of the payload sent to the Sidetree node. This signature is generated using a key specified in the corresponding DID Document.