ISCC Decentralized Content Registry#
IEP: | 0013 |
---|---|
Title: | ISCC Decentralized Content Registry |
Author: | Titusz Pan tp@iscc.foundation |
Comments: | https://github.com/iscc/iscc-ieps/issues/18 |
Status: | DRAFT |
Type: | Core |
License: | CC-BY-4.0 |
Created: | 2022-09-28 |
Updated: | 2023-12-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.
- 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.
- The minting protocol defines how a legers history has to be parsed to mint a valid ISCC-ID
- 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:
- An ISCC-CODE (a valid sequence of ISCC-UNITs)
- A blockchain account (actors identifier) of the declaring party
- 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:
- A link to external metadata as defined by IEP-0012 - ISCC Metadata
- 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:
- The ledger must provide an immutable, complete, time-ordered, append-only sequence of transactions.
- The legers transaction format must allow for embedding and signing the data required for an ISCC declarations.
- The Declaration-Set MUST be publicly readable (permisionless).
- ISCC declarations on the ledger MAY be write-permissioned.
A participating ledger or framework MUST provide documentaation of its implementation of the declaration protocol.
- The documentation MUST specify how ISCC declarations can be parsed to decode the Declaration-Set
- The documentation MUST provide sufficient information to the public such that third parties can independently verify transactions signatures and implement the Minting Protocol
- 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#
- ISCC-ID construction: https://github.com/iscc/iscc-core/blob/main/iscc_core/iscc_id.py
- EVM registry: https://github.com/iscc/iscc-evm
- EVM observer: https://github.com/iscc/iscc-observer-evm
- ISCC-ID resolver: https://github.com/iscc/iscc-registry