Skip to content

ISCC Decentralized Content Registry#

IEP: 0013
Title: ISCC Decentralized Content Registry
Author: Titusz Pan tp@iscc.io
Comments: https://github.com/iscc/iscc-ieps/issues/18
Status: DRAFT
Type: Core
License: CC-BY-4.0
Created: 2022-09-28
Updated: 2024-11-30

1. Status of This Document#

This document is a draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organization.

2. Introduction#

The purpose of a decentralized content registry is to connect Actors to Digital Content in a permissionless decentralized environment and provide a global and verifiable data space for content identification and matching.

Actors authenticate themselves with their blockchain accounts which they use to sign ISCC-CODE declarations (ledger transactions). Digital Content is identified by ISCC-CODEs. The ISCC-ID is derived from an ISCC-CODE, a blockchain account and the history of previous declarations. ISCC-IDs are globally unique, persistent, authenticated, and resolve to at least exactly one ISCC-CODE and a blockchain account. The ISCC-IDs are not required to be generated or stored on the participating ledgers. ISCC-IDs are the result of processing the history of transactions according to the Minting Protocol.

3. Protocol Overview#

The protocol to declare an ISCC-CODE and trigger the minting of an ISCC-ID is divided into 3 parts, the Declaration Protocol, the Minting Protocol and the Resolution Protocol.

  1. The declaration protocol defines how an ISCC-CODE has to be written to a ledger to become a valid input for the off-chain minting protocol.
  2. The minting protocol defines how a legers history has to be parsed to mint a valid ISCC-ID
  3. The resolution protocol defines how an ISCC resolver answers queries about ISCC-CODEs and ISCC-ID.

4. Declaration Protocol#

To participate in the ISCC declaration protocol, a ledger MUST establish exactly one globally unique Ledger-ID (Variable Length Integer) that will be used as a prefix for ISCC-IDs that are minted from its ISCC declarations.

Note

An ISCC-ID comes into existence only after an ISCC declaration has been confirmed on a ledger that participates in the protocol.

The following minimal information (Declaration-Set) MUST be provided and made publicly available for a valid ISCC declaration:

  1. An ISCC-CODE (a valid sequence of ISCC-UNITs)
  2. A blockchain account (actors identifier) of the declaring party
  3. A valid signature of the declaring party (transaction signature)

We define the party that signs the ISCC declaration as the DECLARER.

Note

The DECLARER is merely the controller of the ISCC-ID minted from the declaration. The declarer is not required to be the creator or a rights-holder of the declared digital content.

An ISCC declaration MAY additionally include:

  1. A link to external metadata as defined by IEP-0012 - ISCC Metadata
  2. A processing instruction for the minting protocol

The on-chain link to ISCC metadata SHOULD point to a public and integrity preserving resource (e.g. IPFS CID or a hashlink URI). Permissioned, confidential or mutable data SHOULD be referenced from ISCC metadata via URI.

A ledger that wants to accept ISCC declarations and trigger the minting of valid ISCC-IDs MUST fulfill the following minimum requirements:

  1. The ledger must provide an immutable, complete, time-ordered, append-only sequence of transactions.
  2. The legers transaction format must allow for embedding and signing the data required for an ISCC declarations.
  3. The Declaration-Set MUST be publicly readable (permisionless).
  4. ISCC declarations on the ledger MAY be write-permissioned.

A participating ledger or framework MUST provide documentaation of its implementation of the declaration protocol.

  1. The documentation MUST specify how ISCC declarations can be parsed to decode the Declaration-Set
  2. The documentation MUST provide sufficient information to the public such that third parties can independently verify transactions signatures and implement the Minting Protocol
  3. The documentation MUST define how a public observer can distinguish between a transaction that declares an ISCC-CODE and other unrelated transactions.

5. Minting Protocol#

TBD

6. Resolution Protocol#

TBD

7. Reference Implementation#