npm package: @siriusid-next/did-method-sirius
Description: This package contains an implementation of Sidetree Core, using Sirius Chain and IPFS
Author: Thomas Tran
Latest version: 0.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](https://identity.foundation/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:
```json
{
  "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

```json
{
  "@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](https://identity.foundation/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:
```json
{
  "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

```json
{
  "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:

```json
{
  "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.