Chroma Signet

Signet is a protocol that conveys secure, authoritative symbols across somewhat-trusted boundaries.

Why?

Typically, verifiable statements are simply relationships between signatures and data. Each verifiable statement requires 3 known codecs: Data Serialization, Checksum, and Signature. Currently, there is no portable format that allows the identification and arrangement of these 3 codecs such that their relationship may be identified; therefore, this process inevitably becomes part of a system's implementation code, which is not compatible with other systems, except when made explicitly compatible by convention.

The protocol

Layer 0

Storage to binary

• a signet is a physical mark, most often represented by Chroma's pinwheel.
• a signet can also be distributed as a QR, Aztec, Jabcode, Databar, or other data carrying mark. This typically mandates a smaller footprint, inclusive of the payload and signatures.
• Being stored or transmitted digitally, a signet may be represented as binary, or as a multibase string.

Layer 1

Binary to multicodec graph

Signet protocol aims to allow small multicodec graphs to be encoded as uninterrupted binary with minimum overhead. Similiar to a usb descriptor, this can be accomplished by simply setting lengths for codecs that do not have a fixed length. Then, with the addition of a few basic index and container types, one can communicate notorized statements portably.

Signet descriptor types allow for encoding of multiple multicodecs in a single byte stream

| version | name | data | details | | ------- | -------- | ---------------------- | ------------------------------------------------------------- | | 30† | identity | n/a | multicodec with implicit length | | 3a | variable | codec, length, binary | specify length of next serialization e.g. CBOR, proto | | 3b | index | varint | points to a locally known multi-codec by 0 index | | 3c | hptr | multicodec (hash) | points to a discoverable multicodec via hash pointer | | 3d | tuple | multicodec, multicodec | associate an index or hash with another multicodec | | 3e†† | list | length, multicodec[] | list of multicodecs | | 3f | suite | varint[] | list of multicodec identifiers |

†The current multicodec table treats codecs as having implicit length. A separate table of those default lengths must be maintained, if the implicit length is to be used by automated tooling. For example sha3-256 implies a length of 32 bytes.

†† Why not re-use RLP for a list? Because these binary chunks need explicit codecs. RLP could still be used for a list of strings, so long as utf8 is implicit.

Signet serialization types (to be added to multicodec)

| version | name | details | | ------- | ---------------- | ------------------------------------------------ | | 52 | legendary buffer | legendary is a [descriptor hash, protobuf] tuple |

Signet signature types (to be added to multikey)

| version | name | data | details | | ------- | --------------- | -------- | ------- | | bb | bip-schnorr-pub | 32 bytes | | bc | bip-schnorr-sig | 64 bytes |

Layer 2

Protocol defined multicodec stuctures

Example 1: a "statement" could be a signature of a hash of a CBOR

    [tuple         ]  [tuple          ]  [blob          ]
      [index]  [sig]    [index]  [hash]  [length]  [cbor]
    []       []       []       []                []
  []                []                 []
0x3d3b01     bc +64 3d3b00     16  +32 3adb      51 +219

Example 2: a simple sha-3

    [hash]
0x16  +32

Layer 3

A simple layer 3 application might send a signet packet to a known 3rd party. This could include a corporate infrastructure, or a permissionless blockchain.

For instance, a logistics company might emit the public key derived from a signet packet upon receiving a signed message.

A consumer application might re-sign the whole message so that the original producer of the signet may identify who has received their message.

Best practices

Signatures

The default digital signature algorithm is Schnorr.

Content Addressing

The default secure hash algorithm which should be used for content addressing is SHA3–256.

Linked-Data Serialization

• smaller payloads should use CBOR or JSON.

• larger payloads or smallest offline footprints should use Protobuf via Legendary wrapper format.