From b25a47b06bc65d02b0274e09f2e5eebc1045d626 Mon Sep 17 00:00:00 2001
From: Titusz Pan <titusz.pan@gmail.com>
Date: Thu, 28 Dec 2023 11:48:20 +0100
Subject: [PATCH] Deployed 7770f24 with MkDocs version: 1.5.3

---
 iep-0002/index.html      | 171 ++++++++++++++++++++++++++-------------
 search/search_index.json |   2 +-
 sitemap.xml.gz           | Bin 284 -> 284 bytes
 3 files changed, 118 insertions(+), 55 deletions(-)

diff --git a/iep-0002/index.html b/iep-0002/index.html
index 87136ea..44e3140 100755
--- a/iep-0002/index.html
+++ b/iep-0002/index.html
@@ -173,72 +173,104 @@
     </label>
 <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix="">
 <li class="md-nav__item">
-<a class="md-nav__link" href="#1-meta-code">
+<a class="md-nav__link" href="#1-general">
 <span class="md-ellipsis">
-      1. Meta-Code
+      1. General
     </span>
 </a>
-<nav aria-label="1. Meta-Code" class="md-nav">
-<ul class="md-nav__list">
+</li>
 <li class="md-nav__item">
-<a class="md-nav__link" href="#11-general">
+<a class="md-nav__link" href="#2-purpose">
 <span class="md-ellipsis">
-      1.1 General
+      2. Purpose
     </span>
 </a>
 </li>
 <li class="md-nav__item">
-<a class="md-nav__link" href="#12-purpose">
+<a class="md-nav__link" href="#3-format">
 <span class="md-ellipsis">
-      1.2 Purpose
+      3. Format
     </span>
 </a>
 </li>
 <li class="md-nav__item">
-<a class="md-nav__link" href="#13-format">
+<a class="md-nav__link" href="#4-inputs">
+<span class="md-ellipsis">
+      4. Inputs
+    </span>
+</a>
+<nav aria-label="4. Inputs" class="md-nav">
+<ul class="md-nav__list">
+<li class="md-nav__item">
+<a class="md-nav__link" href="#41-name-element">
 <span class="md-ellipsis">
-      1.3 Format
+      4.1 name element
     </span>
 </a>
 </li>
 <li class="md-nav__item">
-<a class="md-nav__link" href="#14-inputs">
+<a class="md-nav__link" href="#42-description-element">
 <span class="md-ellipsis">
-      1.4 Inputs
+      4.2 description element
     </span>
 </a>
 </li>
 <li class="md-nav__item">
-<a class="md-nav__link" href="#15-outputs">
+<a class="md-nav__link" href="#43-meta-element">
 <span class="md-ellipsis">
-      1.5 Outputs
+      4.3 meta element
     </span>
 </a>
 </li>
+</ul>
+</nav>
+</li>
 <li class="md-nav__item">
-<a class="md-nav__link" href="#16-seed-metadata">
+<a class="md-nav__link" href="#5-outputs">
 <span class="md-ellipsis">
-      1.6 Seed metadata
+      5. Outputs
     </span>
 </a>
 </li>
 <li class="md-nav__item">
-<a class="md-nav__link" href="#17-metadata-embedding">
+<a class="md-nav__link" href="#6-seed-metadata">
 <span class="md-ellipsis">
-      1.7 Metadata embedding
+      6. Seed metadata
+    </span>
+</a>
+<nav aria-label="6. Seed metadata" class="md-nav">
+<ul class="md-nav__list">
+<li class="md-nav__item">
+<a class="md-nav__link" href="#61-meta-code-processing">
+<span class="md-ellipsis">
+      6.1 Meta-Code processing
     </span>
 </a>
 </li>
 <li class="md-nav__item">
-<a class="md-nav__link" href="#18-metadata-extraction">
+<a class="md-nav__link" href="#62-meta-hash-processing">
 <span class="md-ellipsis">
-      1.8 Metadata extraction
+      6.2 Meta-Hash processing
     </span>
 </a>
 </li>
 </ul>
 </nav>
 </li>
+<li class="md-nav__item">
+<a class="md-nav__link" href="#7-metadata-embedding">
+<span class="md-ellipsis">
+      7. Metadata embedding
+    </span>
+</a>
+</li>
+<li class="md-nav__item">
+<a class="md-nav__link" href="#8-metadata-extraction">
+<span class="md-ellipsis">
+      8. Metadata extraction
+    </span>
+</a>
+</li>
 </ul>
 </nav>
 </li>
@@ -348,72 +380,104 @@
     </label>
 <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix="">
 <li class="md-nav__item">
-<a class="md-nav__link" href="#1-meta-code">
+<a class="md-nav__link" href="#1-general">
 <span class="md-ellipsis">
-      1. Meta-Code
+      1. General
     </span>
 </a>
-<nav aria-label="1. Meta-Code" class="md-nav">
-<ul class="md-nav__list">
+</li>
 <li class="md-nav__item">
-<a class="md-nav__link" href="#11-general">
+<a class="md-nav__link" href="#2-purpose">
 <span class="md-ellipsis">
-      1.1 General
+      2. Purpose
     </span>
 </a>
 </li>
 <li class="md-nav__item">
-<a class="md-nav__link" href="#12-purpose">
+<a class="md-nav__link" href="#3-format">
 <span class="md-ellipsis">
-      1.2 Purpose
+      3. Format
     </span>
 </a>
 </li>
 <li class="md-nav__item">
-<a class="md-nav__link" href="#13-format">
+<a class="md-nav__link" href="#4-inputs">
+<span class="md-ellipsis">
+      4. Inputs
+    </span>
+</a>
+<nav aria-label="4. Inputs" class="md-nav">
+<ul class="md-nav__list">
+<li class="md-nav__item">
+<a class="md-nav__link" href="#41-name-element">
 <span class="md-ellipsis">
-      1.3 Format
+      4.1 name element
     </span>
 </a>
 </li>
 <li class="md-nav__item">
-<a class="md-nav__link" href="#14-inputs">
+<a class="md-nav__link" href="#42-description-element">
 <span class="md-ellipsis">
-      1.4 Inputs
+      4.2 description element
     </span>
 </a>
 </li>
 <li class="md-nav__item">
-<a class="md-nav__link" href="#15-outputs">
+<a class="md-nav__link" href="#43-meta-element">
 <span class="md-ellipsis">
-      1.5 Outputs
+      4.3 meta element
     </span>
 </a>
 </li>
+</ul>
+</nav>
+</li>
 <li class="md-nav__item">
-<a class="md-nav__link" href="#16-seed-metadata">
+<a class="md-nav__link" href="#5-outputs">
 <span class="md-ellipsis">
-      1.6 Seed metadata
+      5. Outputs
     </span>
 </a>
 </li>
 <li class="md-nav__item">
-<a class="md-nav__link" href="#17-metadata-embedding">
+<a class="md-nav__link" href="#6-seed-metadata">
 <span class="md-ellipsis">
-      1.7 Metadata embedding
+      6. Seed metadata
+    </span>
+</a>
+<nav aria-label="6. Seed metadata" class="md-nav">
+<ul class="md-nav__list">
+<li class="md-nav__item">
+<a class="md-nav__link" href="#61-meta-code-processing">
+<span class="md-ellipsis">
+      6.1 Meta-Code processing
     </span>
 </a>
 </li>
 <li class="md-nav__item">
-<a class="md-nav__link" href="#18-metadata-extraction">
+<a class="md-nav__link" href="#62-meta-hash-processing">
 <span class="md-ellipsis">
-      1.8 Metadata extraction
+      6.2 Meta-Hash processing
     </span>
 </a>
 </li>
 </ul>
 </nav>
 </li>
+<li class="md-nav__item">
+<a class="md-nav__link" href="#7-metadata-embedding">
+<span class="md-ellipsis">
+      7. Metadata embedding
+    </span>
+</a>
+</li>
+<li class="md-nav__item">
+<a class="md-nav__link" href="#8-metadata-extraction">
+<span class="md-ellipsis">
+      8. Metadata extraction
+    </span>
+</a>
+</li>
 </ul>
 </nav>
 </div>
@@ -471,18 +535,17 @@ <h1 id="iscc-unit-meta-code"><abbr title="International Standard Content Code">I
 developed at the International Organization for Standardization as
 <a href="https://www.iso.org/standard/77899.html"><abbr title="International Organization for Standardization">ISO</abbr>/DIS 24138</a></p>
 </div>
-<h2 id="1-meta-code">1. Meta-Code<a class="headerlink" href="#1-meta-code" title="Permanent link">#</a></h2>
-<h3 id="11-general">1.1 General<a class="headerlink" href="#11-general" title="Permanent link">#</a></h3>
+<h2 id="1-general">1. General<a class="headerlink" href="#1-general" title="Permanent link">#</a></h2>
 <p>The Meta-Code is a <abbr title="hash that preserves correlations between inputs to the hash algorithm">similarity hash</abbr> generated from <abbr title="that which is identified">referent</abbr> <abbr title="initial metadata used as input to a hash function">seed metadata</abbr> as defined in 
 <a href="../iep-0012/">IEP-0012</a></p>
-<h3 id="12-purpose">1.2 Purpose<a class="headerlink" href="#12-purpose" title="Permanent link">#</a></h3>
+<h2 id="2-purpose">2. Purpose<a class="headerlink" href="#2-purpose" title="Permanent link">#</a></h2>
 <p>The Meta-Code shall support the following use cases:</p>
 <ol>
 <li>clustering of digital assets based on their <abbr title="data that defines and describes other data">metadata</abbr>;</li>
 <li>discovery of digital assets with similar <abbr title="data that defines and describes other data">metadata</abbr>;</li>
 <li>verification or manual disambiguation of matching codes.</li>
 </ol>
-<h3 id="13-format">1.3 Format<a class="headerlink" href="#13-format" title="Permanent link">#</a></h3>
+<h2 id="3-format">3. Format<a class="headerlink" href="#3-format" title="Permanent link">#</a></h2>
 <p>The Meta-Code shall have the <abbr title="ordered sequence of bits">data</abbr> format as illustrated in Figure 2:</p>
 <figure>
 <p><a class="glightbox" href="../images/iscc-iep-0002-f02-meta-code.png"><img alt="Figure 2 - Data format of the Meta-Code" src="../images/iscc-iep-0002-f02-meta-code.png"/></a>
@@ -497,7 +560,7 @@ <h3 id="13-format">1.3 Format<a class="headerlink" href="#13-format" title="Perm
 <p class="admonition-title">EXAMPLE: 256-<abbr title="atomic unit of information in a computer system">bit</abbr> Meta-Code in its canonical form:</p>
 <p><abbr title="International Standard Content Code">ISCC</abbr>:AADUL6P7RMVNT4UJJ4SMTDXBL5JFZ5XPCDKO42XYPJEVQ4L7PTYDORQ</p>
 </div>
-<h3 id="14-inputs">1.4 Inputs<a class="headerlink" href="#14-inputs" title="Permanent link">#</a></h3>
+<h2 id="4-inputs">4. Inputs<a class="headerlink" href="#4-inputs" title="Permanent link">#</a></h2>
 <p>Seed <abbr title="data that defines and describes other data">metadata</abbr> is the <abbr title="data that defines and describes other data">metadata</abbr> that is used as the input to calculate the Meta-Code and has three 
 possible elements:</p>
 <ol>
@@ -517,7 +580,7 @@ <h3 id="14-inputs">1.4 Inputs<a class="headerlink" href="#14-inputs" title="Perm
 <p>The <abbr title="sequence of characters that uniquely denotes a referent">identifier</abbr> standards and their schemas defined by <abbr title="International Organization for Standardization">ISO</abbr>/TC 46/SC 9 provide helpful guidance 
 in selecting <abbr title="initial metadata used as input to a hash function">seed metadata</abbr>.</p>
 </div>
-<h4 id="141-name-element">1.4.1 name element<a class="headerlink" href="#141-name-element" title="Permanent link">#</a></h4>
+<h3 id="41-name-element">4.1 name element<a class="headerlink" href="#41-name-element" title="Permanent link">#</a></h3>
 <p>The text input for the name element shall be pre-processed before similarity hashing as follows:</p>
 <ol>
 <li>Apply <abbr title="International Organization for Standardization">ISO</abbr>/IEC 10646 NFKC Unicode Normalization  (see Unicode Normalization Forms <a href="https://unicode.org/reports/tr15/#Norm_Forms">https://unicode.org/reports/tr15/#Norm_Forms</a>). </li>
@@ -525,7 +588,7 @@ <h4 id="141-name-element">1.4.1 name element<a class="headerlink" href="#141-nam
 <li>Strip leading and trailing whitespace. </li>
 <li>Trim the end of the text such that the UTF-8 encoded size does not exceed 128 bytes.</li>
 </ol>
-<h4 id="142-description-element">1.4.2 description element<a class="headerlink" href="#142-description-element" title="Permanent link">#</a></h4>
+<h3 id="42-description-element">4.2 description element<a class="headerlink" href="#42-description-element" title="Permanent link">#</a></h3>
 <p>Text input for the description element shall be pre-processed before similarity hashing as follows:</p>
 <ol>
 <li>Apply NFKC Unicode Normalization.</li>
@@ -542,7 +605,7 @@ <h4 id="142-description-element">1.4.2 description element<a class="headerlink"
 <li>Collapse more than two consecutive newlines characters to a maximum of two consecutive newlines.</li>
 <li>Strip leading and trailing whitespace characters.</li>
 </ol>
-<h4 id="143-meta-element">1.4.3 meta element<a class="headerlink" href="#143-meta-element" title="Permanent link">#</a></h4>
+<h3 id="43-meta-element">4.3 meta element<a class="headerlink" href="#43-meta-element" title="Permanent link">#</a></h3>
 <ol>
 <li>The value of the meta element shall be wrapped in a RFC 2397 Data-URL.</li>
 <li>The value of the meta element may include any conceivable and supportive <abbr title="data that defines and describes other data">metadata</abbr> such as for example:<ul>
@@ -563,7 +626,7 @@ <h4 id="143-meta-element">1.4.3 meta element<a class="headerlink" href="#143-met
 </ol>
 </li>
 </ol>
-<h3 id="15-outputs">1.5 Outputs<a class="headerlink" href="#15-outputs" title="Permanent link">#</a></h3>
+<h2 id="5-outputs">5. Outputs<a class="headerlink" href="#5-outputs" title="Permanent link">#</a></h2>
 <p>Meta-Code processing shall generate the following output elements for inclusion into the produced 
 <abbr title="International Standard Content Code">ISCC</abbr> <abbr title="data that defines and describes other data">metadata</abbr>:</p>
 <ol>
@@ -581,8 +644,8 @@ <h3 id="15-outputs">1.5 Outputs<a class="headerlink" href="#15-outputs" title="P
 <p class="admonition-title">NOTE 2</p>
 <p>An <abbr title="application that generates ISCCs for digital content">ISCC processor</abbr> may produce other custom output elements, which are helpful to identify the <abbr title="file or stream encoded in conformance with a specific content format">digital asset</abbr>.</p>
 </div>
-<h3 id="16-seed-metadata">1.6 Seed <abbr title="data that defines and describes other data">metadata</abbr><a class="headerlink" href="#16-seed-metadata" title="Permanent link">#</a></h3>
-<h4 id="161-meta-code-processing">1.6.1 Meta-Code processing<a class="headerlink" href="#161-meta-code-processing" title="Permanent link">#</a></h4>
+<h2 id="6-seed-metadata">6. Seed <abbr title="data that defines and describes other data">metadata</abbr><a class="headerlink" href="#6-seed-metadata" title="Permanent link">#</a></h2>
+<h3 id="61-meta-code-processing">6.1 Meta-Code processing<a class="headerlink" href="#61-meta-code-processing" title="Permanent link">#</a></h3>
 <p>The Meta-Code shall be constructed from 2 similarity hashes interleaved in 32-<abbr title="atomic unit of information in a computer system">bit</abbr> chunks by 
 selecting the elements according to the <abbr title="set of instructions">algorithm</abbr> illustrated in Figure 3.</p>
 <figure>
@@ -597,7 +660,7 @@ <h4 id="161-meta-code-processing">1.6.1 Meta-Code processing<a class="headerlink
 <li>If the meta element is unavailable, the second part of the <abbr title="hash that preserves correlations between inputs to the hash algorithm">similarity hash</abbr> shall be generated from the description element.</li>
 <li>If the description element is unavailable, the second part of the <abbr title="hash that preserves correlations between inputs to the hash algorithm">similarity hash</abbr> shall also be generated from the name element.</li>
 </ol>
-<h4 id="162-meta-hash-processing">1.6.2 Meta-Hash processing<a class="headerlink" href="#162-meta-hash-processing" title="Permanent link">#</a></h4>
+<h3 id="62-meta-hash-processing">6.2 Meta-Hash processing<a class="headerlink" href="#62-meta-hash-processing" title="Permanent link">#</a></h3>
 <p>The Meta-Hash shall be constructed from the <abbr title="initial metadata used as input to a hash function">seed metadata</abbr> by selecting input elements according to 
 the <abbr title="set of instructions">algorithm</abbr> illustrated in Figure 4.</p>
 <figure>
@@ -611,7 +674,7 @@ <h4 id="162-meta-hash-processing">1.6.2 Meta-Hash processing<a class="headerlink
 <li>If the meta element is unavailable, but the description element is available, the space-concatenated value of the pre-processed name and description shall be the input to the <abbr title="computationally efficient function mapping binary strings of arbitrary length to binary strings of fixed length, such that it is computationally infeasible to find two distinct values that hash into a common value">cryptographic hash function</abbr>.</li>
 <li>If only the name element is available, its pre-processed value shall be the input to the <abbr title="computationally efficient function mapping binary strings of arbitrary length to binary strings of fixed length, such that it is computationally infeasible to find two distinct values that hash into a common value">cryptographic hash function</abbr>.</li>
 </ol>
-<h3 id="17-metadata-embedding">1.7 Metadata embedding<a class="headerlink" href="#17-metadata-embedding" title="Permanent link">#</a></h3>
+<h2 id="7-metadata-embedding">7. Metadata embedding<a class="headerlink" href="#7-metadata-embedding" title="Permanent link">#</a></h2>
 <ol>
 <li>Seed <abbr title="data that defines and describes other data">metadata</abbr> shall be embedded into the processed <abbr title="file or stream encoded in conformance with a specific content format">digital asset</abbr> if:<ol>
 <li><abbr title="initial metadata used as input to a hash function">seed metadata</abbr> values have been provided explicitly to an <abbr title="application that generates ISCCs for digital content">ISCC processor</abbr>;</li>
@@ -628,7 +691,7 @@ <h3 id="17-metadata-embedding">1.7 Metadata embedding<a class="headerlink" href=
 <li>If <abbr title="initial metadata used as input to a hash function">seed metadata</abbr> is to be embedded, it shall be embedded before processing other <abbr title="International Standard Content Code">ISCC</abbr>-UNITs.</li>
 <li>An <abbr title="application that generates ISCCs for digital content">ISCC processor</abbr> should document for which media types it supports <abbr title="data that defines and describes other data">metadata</abbr>-embedding and how it maps <abbr title="initial metadata used as input to a hash function">seed metadata</abbr> to format specific elements.</li>
 </ol>
-<h3 id="18-metadata-extraction">1.8 Metadata extraction<a class="headerlink" href="#18-metadata-extraction" title="Permanent link">#</a></h3>
+<h2 id="8-metadata-extraction">8. Metadata extraction<a class="headerlink" href="#8-metadata-extraction" title="Permanent link">#</a></h2>
 <ol>
 <li>An <abbr title="application that generates ISCCs for digital content">ISCC processor</abbr> shall try to extract <abbr title="initial metadata used as input to a hash function">seed metadata</abbr> from the <abbr title="file or stream encoded in conformance with a specific content format">digital asset</abbr> if:<ol>
 <li><abbr title="initial metadata used as input to a hash function">seed metadata</abbr> has not been provided explicitly to the <abbr title="application that generates ISCCs for digital content">ISCC processor</abbr>;</li>
diff --git a/search/search_index.json b/search/search_index.json
index 3e53eab..b21ab8b 100755
--- a/search/search_index.json
+++ b/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"ISCC - Enhancement Proposals (IEPs)","text":""},{"location":"#what-is-an-iep","title":"What is an IEP?","text":"<p>IEP stands for ISCC Enhancement Proposal. An IEP is a design document providing information to the ISCC community, or describing a new feature for the ISCC or its processes or environment.</p> <p>IEPs are a mechanism for proposing new features, for collecting community input on an issue, and for documenting design decisions. The IEP author is responsible for building consensus within the community and documenting dissenting opinions.</p> <p>Because the IEPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.</p>"},{"location":"#list-of-ieps","title":"List of IEPs","text":"ID Title Type Status IEP-0000 IEP Purpose and Guidelines Process Draft IEP-0001 ISCC Structure and Format Core Draft IEP-0002 ISCC-UNIT Meta-Code Core Draft IEP-0003 ISCC-UNIT Condent-Code Text Core TBD IEP-0004 ISCC-UNIT Condent-Code Image Core TBD IEP-0005 ISCC-UNIT Condent-Code Audio Core TBD IEP-0006 ISCC-UNIT Condent-Code Video Core TBD IEP-0007 ISCC-UNIT Condent-Code Mixed Core TBD IEP-0008 ISCC-UNIT Data-Code Core TBD IEP-0009 ISCC-UNIT Instance-Code Core TBD IEP-0010 ISCC-CODE Core TBD IEP-0011 ISCC-ID Core TBD IEP-0012 ISCC Metadata Core TBD IEP-0013 ISCC Decentralized Content Registry Core Draft IEP-0014 EVM Based ISCC Registries Core TBD IEP-0015 ISCC DID Method Core Draft"},{"location":"iep-0000/","title":"IEP-0: IEP Purpose and Guidelines","text":"IEP: 0000 Title: IEP Purpose and Guidelines Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/2 Status: Draft Type: Process License: BSD-2-Clause Created: 2022-08-28 Updated: 2022-09-23"},{"location":"iep-0000/#1-what-is-an-iep","title":"1. What is an IEP?","text":"<p>An ISCC Enhancement Proposal (IEP) is a design document providing information to the ISCC community, or describing a new feature for the ISCC or its processes or environment. An IEP should provide a concise technical specification of a feature and a rationale for the feature. IEPs have no special status except that accorded by the community.</p> <p>IEPs are a mechanism for proposing new features, for collecting community input on an issue, and for documenting design decisions. The IEP author is responsible for building consensus within the community and documenting dissenting opinions.</p> <p>Because the IEPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.</p>"},{"location":"iep-0000/#2-iep-audience","title":"2. IEP audience","text":"<p>The typical primary audience for IEPs are the developers of ISCC implementations.</p> <p>However, other parts of the ISCC community may also choose to use the process (particularly for Informational IEPs) to document expected API conventions and to manage complex design coordination problems that require collaboration across multiple projects.</p>"},{"location":"iep-0000/#3-iep-workflow","title":"3. IEP workflow","text":"<p>The IEP process begins with a new idea for the ISCC. Each potential IEP must have a champion - someone who writes the IEP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea.</p> <p>Small enhancements or patches to a particular piece of software often don't require coordination between multiple projects or implementations; these don't need an IEP and should be injected into the relevant project-specific development workflow with a patch submission to the applicable issue tracker.</p> <p>After investigating past work, the best way to proceed is by opening issue for discussion about the new idea. Following a discussion, the proposal should be submitted to the IEPs git repository as a pull request. This draft must be written in IEP style as described below, and named with an alias such as \"iep-johndoe-new-semantic-id\" until an editor has assigned it an IEP number (authors MUST NOT self-assign IEP numbers).</p> <p>When the IEP draft is complete, an IEP editor will assign the IEP a number, label it as Core, Informational, or Process, and merge the pull request to the IEPs git repository. The IEP editors will not unreasonably reject an IEP. Reasons for rejecting IEPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility. For an IEP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.</p> <p>The IEP author may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the author as pull requests.</p>"},{"location":"iep-0000/#31-transferring-iep-ownership","title":"3.1 Transferring IEP ownership","text":"<p>It occasionally becomes necessary to transfer ownership of IEPs to a new champion. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the IEP process, or is unreachable or not responding to email.</p> <p>If you are interested in assuming ownership of an IEP, send a message asking to take over, addressed to both the original author and the IEP editors. If the original author doesn't respond to email in a timely manner, the IEP editors will make a unilateral decision.</p>"},{"location":"iep-0000/#32-iep-editors","title":"3.2 IEP editors","text":"<p>The current IEP editors are:</p> <ul> <li>Titusz Pan tp@iscc.foundation</li> </ul>"},{"location":"iep-0000/#33-iep-editor-responsibilities","title":"3.3 IEP editor responsibilities","text":"<p>The IEP editors subscribe to the IEP issue tracker. Correspondence outside the issue tracker should be sent (or CC'd) to the IEP editors.</p> <p>For each new IEP that comes in an editor does the following:</p> <ul> <li> <p>Read the IEP to check if it is ready: sound and complete. The ideas must make technical sense.</p> </li> <li> <p>The title should accurately describe the content.</p> </li> <li> <p>Motivation and backward compatibility (when applicable) must be addressed.</p> </li> <li> <p>Licensing terms must be acceptable for IEPs.</p> </li> <li> <p>If the IEP isn't ready, the editor will send it back to the author for revision, with specific   instructions.</p> </li> <li> <p>Once the IEP is ready for the repository it should be submitted as a \"pull request\" to the IEPs   git repository where it may get further feedback.</p> </li> </ul> <p>The IEP editor will:</p> <ul> <li>Assign an IEP number in the pull request.</li> <li>Merge the pull request when it is ready.</li> <li>List the IEP in README.md.</li> </ul> <p>The IEP editors are intended to fulfill administrative and editorial responsibilities. The IEP editors monitor IEP changes, and update IEP headers as appropriate.</p>"},{"location":"iep-0000/#4-iep-format-and-structure","title":"4. IEP format and structure","text":"<p>IEPs should be written in Markdown format.</p> <p>Each IEP should have the following parts:</p> <ul> <li>Preamble - Headers containing metadata about the IEP (see below).</li> <li>Abstract - A short (~200 word) description of the issue being addressed.</li> <li>Motivation - A motivation section is critical for IEPs that want to change pre-existing   specifications. It should clearly explain why the existing specification is inadequate to address   the problem that the IEP solves. This section may be omitted if the motivation is evident.</li> <li>Specification - The specification should describe the syntax and semantics of any new feature. The   specification should be detailed enough to allow competing, interoperable implementations.</li> <li>Rationale - The rationale fleshes out the specification by describing what motivated the design   and why particular design decisions were made. It should describe alternate designs that were   considered and related work. The rationale should provide evidence of consensus within the   community and discuss important objections or concerns raised during discussion around the IEP.</li> <li>Backwards compatibility - All IEPs that introduce backwards incompatibilities must include a   section describing these incompatibilities and their severity. The IEP must explain how the author   proposes to deal with these incompatibilities.</li> <li>Reference implementation - A reference implementation must be completed before a Core IEP is given   status Stable, but it need not be completed before the IEP is accepted. The stable implementation   must include test code and documentation.</li> <li>Copyright - The IEP must be explicitly licensed under acceptable copyright   terms see below.</li> </ul>"},{"location":"iep-0000/#41-iep-header-preamble","title":"4.1 IEP header preamble","text":"<p>Each IEP must begin with a header preamble. The headers must appear in the following order. Headers marked with \"*\" are optional and are described below. All other headers are required.</p> <pre><code>  IEP: &lt;IEP number, or \"?\" before being assigned&gt;\n  Title: &lt;IEP title; maximum 44 characters&gt;\n  Author: &lt;list of authors' names and email addresses&gt;\n  Comments: &lt;link to issue page for comments&gt;\n  Status: &lt;Draft | Deferred | Withdrawn | Proposed | Rejected | Stable | Obsolete&gt;\n  Type: &lt;Core | Informational | Process&gt;\n  License: &lt;abbreviation for approved license(s)&gt;\n  Created: &lt;date created on, in ISO 8601 (yyyy-mm-dd) format&gt;\n  Updated: &lt;date updated on, in ISO 8601 (yyyy-mm-dd) format&gt;\n* Replaces: &lt;IEP number&gt;\n* Superseded-By: &lt;IEP number&gt;\n</code></pre> <p>The Author header lists the names and email addresses of all the authors/owners of the IEP. The format of the Author header value must be</p> <pre><code>Random J. User &lt;address@dom.ain&gt;\n</code></pre> <p>If there are multiple authors, each should be on a separate line.</p> <p>The Type header specifies the type of IEP: Core, Informational, or Process.</p> <p>The Created header records the date that the IEP was assigned a number. Dates should be in yyyy-mm-dd format, e.g. 2001-08-14.</p> <p>IEPs may have a Superseded-By header indicating that an IEP has been rendered obsolete by a later document; the value is the number of the IEP that replaces the current document. The newer IEP must have a Replaces header containing the number of the IEP that it rendered obsolete.</p>"},{"location":"iep-0000/#5-iep-types","title":"5. IEP Types","text":"<p>There are three kinds of IEPs:</p> <ul> <li>A Core IEP describes any change that affects most or all ISCC implementations, such as a   change to the algorithms for creating ISCCs, or any change or addition that affects the   interoperability of applications using the ISCC. Core IEPs consist of two parts, a design document   and a reference implementation.</li> <li>An Informational IEP describes an ISCC design issue, or provides general guidelines or   information to the ISCC community, but does not propose a new feature. Informational IEPs do not   necessarily represent a ISCC community consensus or recommendation, so users and implementors are   free to ignore Informational IEPs or follow their advice.</li> <li>A Process IEP describes a process surrounding ISCC, or proposes a change to (or an event in) a   process. Process IEPs are like Core IEPs but apply to areas other than the ISCC algorithms itself.   Examples include procedures, guidelines, changes to the decision-making process, and changes to   the tools or environment used in ISCC development.</li> </ul>"},{"location":"iep-0000/#6-iep-status","title":"6. IEP status","text":"<p>The typical paths of the status of IEPs are as follows:</p> <pre><code>flowchart LR\n    B[Draft]\n    B --&gt; C[Poposed]\n    B &lt;--&gt; D[Deferred]\n    B &lt;--&gt; E[Withdrawn]\n    C --&gt; F[Stable]\n    C --&gt; G[Rejected]\n    F --&gt; H[Obsolete]\n</code></pre> <p>Champions of an IEP may decide on their own to change the status between Draft, Deferred, or Withdrawn. An IEP editor may also change the status to Deferred when no progress is being made on the IEP.</p> <p>An IEP may only change status from Draft to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Stable status.</p> <p>IEPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such an IEP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph.</p> <p>An IEP may change status from Draft to Stable when it achieves rough consensus on the issue tracker and sufficient real-world adoption. Such a proposal is said to have rough consensus if it has been open to discussion on the issue tracker for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances.</p> <p>Software authors are encouraged to publish summaries of what IEPs their software supports to aid in verification of status changes.</p> <p>Should an IEP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Stable status.</p> <p>When a Stable IEP is no longer relevant, its status may be changed to Obsolete. This change must also be objectively verifiable and/or discussed.</p>"},{"location":"iep-0000/#7-iep-licensing","title":"7. IEP licensing","text":"<p>New IEPs may be accepted with the following licenses. Each new IEP must identify at least one acceptable license in its preamble. The License header in the preamble must be placed befor the Created header. Each license must be referenced by their respective abbreviation given below.</p> <p>IEPs are not required to be exclusively licensed under approved terms, and may also be licensed under unacceptable licenses in addition to at least one acceptable license. In this case, only the acceptable license(s) should be listed in the License header.</p>"},{"location":"iep-0000/#71-acceptable-licenses","title":"7.1 Acceptable licenses","text":"<ul> <li>BSD-2-Clause: OSI-approved BSD 2-clause license</li> <li>BSD-3-Clause: OSI-approved BSD 3-clause license</li> <li>CC0-1.0: Creative Commons CC0 1.0 Universal</li> <li>Apache-2.0: Apache License, version 2.0</li> <li>CC-BY-4.0: Creative Commons Attribution 4.0 International</li> <li>CC-BY-SA-4.0: Creative Commons Attribution-ShareAlike 4.0 International</li> <li>MIT: Expat/MIT/X11 license</li> </ul>"},{"location":"iep-0000/#8-history","title":"8. History","text":"<p>This document was derived heavily from Bitcoin\u2019s BIP-0002 which in turn was derived from Python\u2019s PEP-0001. In many places text was simply copied and modified. The original authors of BIP-0002 and PEP-0001 are not responsible for its use in the ISCC Enhancement Proposals, and should not be bothered with technical questions specific to ISCC or the IEPs.</p>"},{"location":"iep-0001/","title":"ISCC Structure and Format","text":"IEP: 0001 Title: ISCC Structure and Format Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/6 Status: Draft Type: Core License: CC-BY-4.0 Created: 2022-09-23 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0001/#1-abstract","title":"1. Abstract","text":"<p>This document describes the coding scheme for the International Standard Content Code (ISCC).</p>"},{"location":"iep-0001/#2-motivation","title":"2. Motivation","text":"<p>The ISCC is a similarity preserving identifier for all kinds of digital content. As such the ISCC requires a universal coding scheme to meet a broad set of use cases and support different media types. The coding scheme for all ISCCs should be:</p> <ol> <li>compact</li> <li>interoperable</li> <li>modular</li> <li>extensible</li> <li>self-describing</li> </ol>"},{"location":"iep-0001/#3-general-structure-of-iscc","title":"3. General structure of ISCC","text":"<ol> <li>An ISCC shall be composed of an ISCC-HEADER and an ISCC-BODY.</li> <li>The ISCC-HEADER shall describe the MainType, SubType, Version, and Length of its ISCC-BODY.</li> <li>An ISCC-UNIT shall be an ISCC based on one specific algorithm.</li> <li>An ISCC-CODE shall be an ISCC composed of two or more different ISCC-UNITs.</li> </ol> Figure 1 - General Structure of an ISCC"},{"location":"iep-0001/#4-iscc-header","title":"4. ISCC-HEADER","text":"<p>The ISCC-HEADER is a variable sized bitstream composed of an ordered sequence of the 4 header-fields MainType, SubType, Version, Length.</p> <p>Each header-field is a bitstream with a length between 4 and 16 bits and encodes an integer value between 0 and 4679 with the following encoding scheme:</p> <ol> <li>The total bit-length of a header-field shall be determined by its prefix-bits.</li> <li>The prefix-bits shall be followed by data-bits.</li> <li>The data-bits shall be interpreted as unsigned integer values plus the maximum value of the    preceding range.</li> <li>If the total length of all header-fields in number of bits is not divisible by 8, the header    shall be padded with 4 zero bits (0000) on the right side.</li> </ol> <p>Table 1 \u2013 Variable length ISCC-HEADER field encoding</p> Prefix bits Number of nibbles Number of data bits Integer range 0 1 3 0-7 10 2 6 8-71 110 3 9 72-583 1110 4 12 584-4679 <p>Header-field examples</p> <pre><code>0 = 0000\n1 = 0001\n\u2026\n7 = 0111\n8 = 1000 0000\n9 = 1000 0001\n</code></pre> <p>The interpretation of the integer value of a header-field shall be context dependent:</p> <ol> <li>For the MainType and SubType fields it shall be an identifier for the designated type.</li> <li>For the Version field it shall be the literal version number.</li> <li>For the Length field of ISCC-UNITs it shall be a number used as a multiplier to calculate the bit length of the ISCC-BODY.</li> <li>For the Length field of ISCC-CODEs it shall be a bit-pattern encoding the combination of ISCC-UNITs and the bit-length of the ISCC-BODY.</li> </ol>"},{"location":"iep-0001/#41-maintypes","title":"4.1 MainTypes","text":"<p>The MainType header-field shall signify the type of the ISCC.</p> <p>Backward incompatible updates to an algorithm associated with a MainType shall be indicated by incrementing the version field of the ISCC-HEADER of the respective MainType.</p> <p>Note</p> <p>The first edition of the standard specifies initial algorithms (version 0) for all reserved MainTypes except for the SEMANTIC type which is not currently defined.</p> <p>Table 2 \u2013 Reserved ISCC MainTypes</p> ID Symbol Bits Definition 0 META 0000 An ISCC-UNIT that matches on metadata similarity 1 SEMANTIC 0001 An ISCC-UNIT that matches on semantic content similarity 2 CONTENT 0010 An ISCC-UNIT that matches on perceptual content similarity 3 DATA 0011 An ISCC-UNIT that matches on data similarity 4 INSTANCE 0100 An ISCC-UNIT that matches on data identity 5 ISCC 0101 An ISCC-CODE composed of two or more headerless ISCC-UNITs for multi-modal matching"},{"location":"iep-0001/#42-subtypes","title":"4.2 SubTypes","text":"<p>The MainTypes META, DATA, and INSTANCE shall have a single default SubType NONE encoded with the bits 0000.</p> <p>The MainTypes SEMANTIC, CONTENT, and ISCC shall have SubTypes that signify the perceptual mode.</p> <p>Table 3 \u2013 Reserved SubTypes for MainTypes ISCC, SEMANTIC, and CONTENT</p> ID Symbol Bits Definition 0 TEXT 0000 Match on text similarity 1 IMAGE 0001 Match on image similarity 2 AUDIO 0010 Match on audio similarity 3 VIDEO 0011 Match on video similarity 4 MIXED 0100 Match on multi-modal similarity <p>Table 4 \u2013 Additional Reserved SubTypes for the MainType ISCC</p> ID Symbol Bits Definition 5 SUM 0101 Composite of ISCC-UNITs including only Data- and Instance-Code 6 NONE 0110 Composite ISCC-UNITs including Meta-, Data- and Instance-Code"},{"location":"iep-0001/#43-version","title":"4.3 Version","text":"<p>All ISCC-HEADERs shall have a version header-field of 0000 for the first edition of the standard.</p> <p>Table 5 \u2013 Reserved ISCC Versions</p> ID Symbol Bits Definition 0 V0 0000 Initial version of ISCC-UNITs and ISCC-CODE"},{"location":"iep-0001/#44-length","title":"4.4 Length","text":"<p>The encoding of the Length header-field shall be specific to the MainType.</p>"},{"location":"iep-0001/#441-length-of-iscc-units","title":"4.4.1 Length of ISCC-UNITs","text":"<p>For ISCC-UNITs of the MainTypes META, SEMANTIC, CONTENT, DATA, and INSTANCE the length value shall be encoded as the number of 32-bit blocks of the ISCC-BODY in addition to the minimum length of 32 bits.</p> <p>Table 6 \u2013 Reserved length field values (multiples of 32 bit)</p> ID Symbol Bits Definition 0 L32 0000 Length of body is 32 bits (minimum length) 1 L64 0001 Length of body is 64 bits (default length) 2 L96 0010 Length of body is 96 bits 3 L128 0011 Length of body is 128 bits 4 L160 0100 Length of body is 160 bits 5 L192 0101 Length of body is 192 bits 6 L224 0110 Length of body is 224 bits 7 L256 0111 Length of body is 256 bits"},{"location":"iep-0001/#442-length-of-iscc-codes","title":"4.4.2 Length of ISCC-CODEs","text":"<ol> <li> <p>For ISCC-CODEs the length value shall designate the composition of ISCC-UNITs.</p> </li> <li> <p>The Data-Code and Instance-Code shall be mandatory 64-bit components of an ISCC-CODE.</p> </li> <li> <p>The first data-bit shall designate the presence of a 64-bit Meta-Code.</p> </li> <li> <p>The second data-bit shall designate the presence of a 64-bit Semantic-Code.</p> </li> <li> <p>The third data-bit shall designate the presence of a 64-bit Content-Code.</p> </li> <li> <p>The length of an ISCC-CODE shall be calculated as the number of active data-bits times 64 plus    128 bits of mandatory data.</p> </li> </ol> <p>Table 7 \u2013 Reserved length field values (for MainType ISCC)</p> ID Symbol Bits Definition 0 SUM 0000 No optional ISCC-UNITs. Length of body is 128 bits. 1 CDI 0001 Includes Content-Code. Length of body is 192 bits 2 SDI 0010 Includes Semantic-Code. Length of body is 192 bits 3 SCDI 0011 Includes Semantic- and Content-Code. Length of body is 256 bits 4 MDI 0100 Includes Meta-Code. Length of body is 192 bits 5 MCDI 0101 Includes Meta-Code and Content-Code. Length of body is 256 bits 6 MSDI 0110 Includes Meta-Code and Semantic-Code. Length of body is 256 bits 7 MSCDI 0111 Includes Meta-, Semantic-, and Content-Code. Length is 320 bits"},{"location":"iep-0001/#5-iscc-body","title":"5. ISCC-BODY","text":"<ol> <li>The preceding MainType, SubType, and Version fields shall qualify the semantics of an ISCC-BODY.</li> <li>The Length field shall determine the number of bits of an ISCC-BODY.</li> </ol>"},{"location":"iep-0001/#6-encoding-of-iscc","title":"6. Encoding of ISCC","text":""},{"location":"iep-0001/#61-canonical-form","title":"6.1 Canonical form","text":"<p>The printable canonical form of an ISCC shall be its RFC 4648 Base32 encoded representation without padding and prefixed with \u201cISCC:\u201d.</p> <p>Canonical ISCC-CODE example</p> <p>ISCC:KEC43HJLPUSHVAZT66YLPUWNVACWYPIV533TRQMWF2IUQYSP5LA4CTY</p>"},{"location":"iep-0001/#62-uri-encoding","title":"6.2 URI encoding","text":"<ol> <li>An ISCC shall be encodable as a Uniform Resource Identifier (URI) according to RFC 3986.</li> <li>The URI representation shall have the format <code>&lt;scheme&gt;:&lt;path&gt;</code>.</li> <li>The URI scheme shall be the string \u201ciscc\u201d.</li> <li>The URI path shall be the lower-cased base32 representation of an ISCC without padding.</li> </ol> <p>URI encoded ISCC-CODE example</p> <p>iscc:kec43hjlpushvazt66ylpuwnvacwypiv533trqmwf2iuqysp5la4cty</p>"},{"location":"iep-0001/#63-multiformats-encoding","title":"6.3 Multiformats encoding","text":"<ol> <li>The ISCC shall be encodable as    a multibase string.</li> <li>The multicodec identifier of    an ISCC shall be <code>0xcc01</code>.</li> <li>A Multiformat representation of an ISCC shall be prefixed with a    Multibase code.</li> <li>The encoding scheme shall be <code>&lt;multibase&gt;&lt;multicodec&gt;&lt;iscc-header&gt;&lt;iscc-body&gt;</code>.</li> </ol> <p>ISCC shall support the following multibase encodings:</p> <p>Table 8 \u2013 Supported multibase encodings</p> Encoding Code Definition base16 f hexadecimal base32 b RFC4648 case-insensitive - no padding base32hex v Match on audio similarity base58btc z base58 bitcoin base64url u RFC4648 no padding <p>Table 9 \u2013 Examples of ISCCs in multiformats encoding</p> Encoding Example MF base16 fcc015105cd9d2b7d247a8333f7b0b7d2cda8056c3d15eef738c1962e9148624feac1c14f MF base32 bzqavcbontuvx2jd2qmz7pmfx2lg2qblmhuk655zyyglc5ekimjh6vqobj4 MF base32hex vpg0l21edjklnq93qgcpvfc5nqb6qg1bc7kauttpoo6b2t4a8c97ulge19s MF base58btc z2Yr3BMx3Rj56fyYkNvfa19PCk4SjspQhpVWoLSGg9yXr4vUGsx MF base64url uzAFRBc2dK30keoMz97C30s2oBWw9Fe73OMGWLpFIYk_qwcFP"},{"location":"iep-0001/#64-readable-encoding","title":"6.4 Readable encoding","text":"<ol> <li>The ISCC shall be encodable in human-readable representation.</li> <li>The readable representation shall encode the header-fields with their symbols and the ISCC-BODY    in base16 lower-case.</li> <li>The header-fields and the ISCC-BODY shall be separated with hyphens.</li> </ol> <p>Example of human-readable ISCC-CODE</p> <p>ISCC-IMAGE-V0-MCDI-cd9d2b7d247a8333f7b0b7d2cda8056c3d15eef738c1962e9148624feac1c14f</p>"},{"location":"iep-0001/#7-reference-implementation","title":"7. Reference implementation","text":"<p>The reference implementation of this coding scheme is published in the iscc-core python package in the codec.py module.</p>"},{"location":"iep-0002/","title":"ISCC-UNIT Meta-Code","text":"IEP: 0002 Title: ISCC-UNIT Meta-Code Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/7 Status: Draft Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0002/#1-meta-code","title":"1. Meta-Code","text":""},{"location":"iep-0002/#11-general","title":"1.1 General","text":"<p>The Meta-Code is a similarity hash generated from referent seed metadata as defined in  IEP-0012</p>"},{"location":"iep-0002/#12-purpose","title":"1.2 Purpose","text":"<p>The Meta-Code shall support the following use cases:</p> <ol> <li>clustering of digital assets based on their metadata;</li> <li>discovery of digital assets with similar metadata;</li> <li>verification or manual disambiguation of matching codes.</li> </ol>"},{"location":"iep-0002/#13-format","title":"1.3 Format","text":"<p>The Meta-Code shall have the data format as illustrated in Figure 2:</p> <p> </p> Figure 2 - Data format of the Meta-Code <p>EXAMPLE: 64-bit Meta-Code in its canonical form:</p> <p>ISCC:AAAUL6P7RMVNT4UJ</p> <p>EXAMPLE: 256-bit Meta-Code in its canonical form:</p> <p>ISCC:AADUL6P7RMVNT4UJJ4SMTDXBL5JFZ5XPCDKO42XYPJEVQ4L7PTYDORQ</p>"},{"location":"iep-0002/#14-inputs","title":"1.4 Inputs","text":"<p>Seed metadata is the metadata that is used as the input to calculate the Meta-Code and has three  possible elements:</p> <ol> <li>name (required): the name or title of the work manifested by the digital asset;</li> <li>description (optional): a disambiguating textual description of the digital asset;</li> <li>meta (optional): subject, industry, or use-case specific metadata.</li> </ol> <p>NOTE 1</p> <p>Because seed metadata is used to construct the Meta-Code, changes to its value may produce  different (and therefore no longer matching) Meta-Codes. Seed metadata is stored and carried  along unaltered with ISCC Metadata if automated verification of the Meta-Code based on the  original seed metadata is required.</p> <p>NOTE 2</p> <p>The identifier standards and their schemas defined by ISO/TC 46/SC 9 provide helpful guidance  in selecting seed metadata.</p>"},{"location":"iep-0002/#141-name-element","title":"1.4.1 name element","text":"<p>The text input for the name element shall be pre-processed before similarity hashing as follows:</p> <ol> <li>Apply ISO/IEC 10646 NFKC Unicode Normalization  (see Unicode Normalization Forms https://unicode.org/reports/tr15/#Norm_Forms). </li> <li>Remove control characters (see Unicode Character Database https://www.unicode.org/ucd/). </li> <li>Strip leading and trailing whitespace. </li> <li>Trim the end of the text such that the UTF-8 encoded size does not exceed 128 bytes.</li> </ol>"},{"location":"iep-0002/#142-description-element","title":"1.4.2 description element","text":"<p>Text input for the description element shall be pre-processed before similarity hashing as follows:</p> <ol> <li>Apply NFKC Unicode Normalization.</li> <li>Remove control characters (as specified by Unicode Character Database) except for the following newline characters:<ul> <li>U000A - Line Feed;</li> <li>U000B - Vertical Tab;</li> <li>U000C - Form Feed;</li> <li>U000D - Carriage Return;</li> <li>U0085 - Next Line;</li> <li>U2028 - Line Separator;</li> <li>U2029 - Paragraph Separator.</li> </ul> </li> <li>Collapse more than two consecutive newlines characters to a maximum of two consecutive newlines.</li> <li>Strip leading and trailing whitespace characters.</li> </ol>"},{"location":"iep-0002/#143-meta-element","title":"1.4.3 meta element","text":"<ol> <li>The value of the meta element shall be wrapped in a RFC 2397 Data-URL.</li> <li>The value of the meta element may include any conceivable and supportive metadata such as for example:<ul> <li>JSON serialized metadata (<code>data:application/json;base64,&lt;data&gt;</code>);</li> <li>JSON-LD serialized metadata (<code>data:application/ld+json;base64,&lt;data&gt;</code>);</li> <li>XML serialized metadata (<code>data:application/xml;base64,&lt;data&gt;</code>);</li> <li>MARC21 XML (<code>data:application/xml;base64,&lt;data&gt;</code>);</li> <li>IPTC NewsML (<code>data:application/vnd.iptc.g2.newsitem+xml;base64,&lt;data&gt;</code>);</li> <li>a file header (<code>data:application/octet-stream;base64,&lt;data&gt;</code>);</li> <li>a thumbnail image (<code>data:image/png;base64,&lt;data&gt;</code>);</li> <li>an audio sample (<code>data:audio/mp4;base64,&lt;data&gt;</code>).</li> </ul> </li> <li>If the value of the meta element is JSON or JSON-LD it shall be serialized with RFC 8785 JCS canonicalization before being wrapped in a Data-URL.</li> <li>If the value of the meta element is XML it shall be serialized as Canonical XML.</li> <li>The Data-URL shall be pre-processed before similarity hashing as follows:<ol> <li>Decode the base64 encoded data section of the Data URL to a raw bitstream without further interpretation.</li> </ol> </li> </ol>"},{"location":"iep-0002/#15-outputs","title":"1.5 Outputs","text":"<p>Meta-Code processing shall generate the following output elements for inclusion into the produced  ISCC metadata:</p> <ol> <li>iscc (required): the ISCC Meta-Code in its canonical form;</li> <li>name (required): the pre-processed value of the name element;</li> <li>meta (optional): the unaltered value of the meta element;</li> <li>description (optional): the pre-processed value of the description element;</li> <li>metahash (required): a cryptographic hash of the seed metadata.</li> </ol> <p>NOTE 1</p> <p>The reference implementation uses a multihash <sup>1</sup> encoded BLAKE3 <sup>2</sup> value for the metahash element.</p> <p>NOTE 2</p> <p>An ISCC processor may produce other custom output elements, which are helpful to identify the digital asset.</p>"},{"location":"iep-0002/#16-seed-metadata","title":"1.6 Seed metadata","text":""},{"location":"iep-0002/#161-meta-code-processing","title":"1.6.1 Meta-Code processing","text":"<p>The Meta-Code shall be constructed from 2 similarity hashes interleaved in 32-bit chunks by  selecting the elements according to the algorithm illustrated in Figure 3.</p> <p> </p> Figure 3 - Meta-Code processing logic <ol> <li>If the name element is unavailable, Meta-Code generation shall be skipped.</li> <li>The first part of the similarity hash for the Meta-Code shall be generated from the name element.</li> <li>The second part of the similarity hash shall be generated from the meta element. </li> <li>If the meta element is unavailable, the second part of the similarity hash shall be generated from the description element.</li> <li>If the description element is unavailable, the second part of the similarity hash shall also be generated from the name element.</li> </ol>"},{"location":"iep-0002/#162-meta-hash-processing","title":"1.6.2 Meta-Hash processing","text":"<p>The Meta-Hash shall be constructed from the seed metadata by selecting input elements according to  the algorithm illustrated in Figure 4.</p> <p> </p> Figure 4 - Meta-Hash processing logic <ol> <li>If the name element is unavailable, Meta-Hash generation shall be skipped.</li> <li>If the meta element is available, the decoded raw and un-interpreted data of the Data-URL shall be used as sole input to the cryptographic hash function.</li> <li>If the meta element is unavailable, but the description element is available, the space-concatenated value of the pre-processed name and description shall be the input to the cryptographic hash function.</li> <li>If only the name element is available, its pre-processed value shall be the input to the cryptographic hash function.</li> </ol>"},{"location":"iep-0002/#17-metadata-embedding","title":"1.7 Metadata embedding","text":"<ol> <li>Seed metadata shall be embedded into the processed digital asset if:<ol> <li>seed metadata values have been provided explicitly to an ISCC processor;</li> <li>the ISCC processor supports metadata embedding for the given media type.</li> </ol> </li> <li>If the media type supports ISO 16684 XMP metadata-embedding, an ISCC processor shall use the namespace http://purl.org/iscc/schema and embed seed metadata values under the names:<ol> <li>Xmp.iscc.name</li> <li>Xmp.iscc.description</li> <li>Xmp.iscc.meta</li> </ol> </li> <li>If the media type does not support ISO 16684 XMP metadata-embedding the ISCC processor may choose other suitable format-specific fields for embedding seed metadata.</li> <li>If seed metadata is to be embedded, it shall be embedded before processing other ISCC-UNITs.</li> <li>An ISCC processor should document for which media types it supports metadata-embedding and how it maps seed metadata to format specific elements.</li> </ol>"},{"location":"iep-0002/#18-metadata-extraction","title":"1.8 Metadata extraction","text":"<ol> <li>An ISCC processor shall try to extract seed metadata from the digital asset if:<ol> <li>seed metadata has not been provided explicitly to the ISCC processor;</li> <li>the ISCC processor supports metadata extraction for the given media type.</li> </ol> </li> <li>Seed metadata shall be extracted with the following precedence:<ol> <li>Extract seed metadata from XMP metadata under the namespace http://purl.org/iscc/schema.</li> <li>Extract seed metadata from suitable, format-specific embedded metadata.</li> <li>Use the filename of the asset as a value for the name element, discarding the file extension and replacing the characters \u201c-\u201d and \u201c_\u201d with spaces.</li> <li>An ISCC processor shall document for which media types it supports metadata-extraction and how it maps seed metadata to format specific elements.</li> </ol> </li> </ol> <p>Bibliography</p> <ol> <li> <p>IETF, draft-multiformats-multihash-05 \u2014 The Multihash Data Format Available at https://datatracker.ietf.org/doc/html/draft-multiformats-multihash-05 \u21a9</p> </li> <li> <p>O\u2019Connor, J., Aumasson, J.P., Neves, S., Wilcox-O\u2019Hearn, Z., BLAKE3: one function, fast  everywhere. Version 20211102173700, accessed July 2022. Available at https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf \u21a9</p> </li> </ol>"},{"location":"iep-0003/","title":"ISCC-UNIT Content-Code Text","text":"IEP: 0003 Title: ISCC-UNIT Condent-Code Text Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/8 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0004/","title":"ISCC-UNIT Content-Code Image","text":"IEP: 0004 Title: ISCC-UNIT Condent-Code Image Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/9 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0005/","title":"ISCC-UNIT Content-Code Audio","text":"IEP: 0005 Title: ISCC-UNIT Condent-Code Audio Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/10 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0006/","title":"ISCC-UNIT Content-Code Video","text":"IEP: 0006 Title: ISCC-UNIT Condent-Code Video Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/11 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0007/","title":"ISCC-UNIT Content-Code Mixed","text":"IEP: 0007 Title: ISCC-UNIT Condent-Code Mixed Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/12 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0008/","title":"ISCC-UNIT Data-Code","text":"IEP: 0008 Title: ISCC-UNIT Data-Code Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/13 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0009/","title":"ISCC-UNIT Instance-Code","text":"IEP: 0009 Title: ISCC-UNIT Instance-Code Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/14 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0010/","title":"ISCC-CODE","text":"IEP: 0010 Title: ISCC-CODE Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/15 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0011/","title":"ISCC-ID","text":"IEP: 0011 Title: ISCC-ID Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/16 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2022-09-28"},{"location":"iep-0012/","title":"ISCC Metadata","text":"IEP: 0012 Title: ISCC Metadata Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/17 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0013/","title":"ISCC Decentralized Content Registry","text":"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: 2022-09-29"},{"location":"iep-0013/#1-status-of-this-document","title":"1. Status of This Document","text":"<p>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.</p>"},{"location":"iep-0013/#2-introduction","title":"2. Introduction","text":"<p>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.</p> <p>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.</p>"},{"location":"iep-0013/#3-protocol-overview","title":"3. Protocol Overview","text":"<p>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. </p> <ol> <li>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. </li> <li>The minting protocol defines how a legers history has to be parsed to mint a valid ISCC-ID</li> <li>The resolution protocol defines how an ISCC resolver answers queries about ISCC-CODEs and ISCC-ID.</li> </ol>"},{"location":"iep-0013/#4-declaration-protocol","title":"4. Declaration Protocol","text":"<p>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. </p> <p>Note</p> <p>An ISCC-ID comes into existence only after an ISCC declaration has been confirmed on a ledger that participates in the protocol. </p> <p>The following minimal information (Declaration-Set) MUST be provided and made publicly available for a valid ISCC declaration:</p> <ol> <li>An ISCC-CODE (a valid sequence of ISCC-UNITs)</li> <li>A blockchain account (actors identifier) of the declaring party </li> <li>A valid signature of the declaring party (transaction signature)</li> </ol> <p>We define the party that signs the ISCC declaration as the DECLARER. </p> <p>Note</p> <p>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.</p> <p>An ISCC declaration MAY additionally include:</p> <ol> <li>A link to external metadata as defined by IEP-0012 - ISCC Metadata</li> <li>A processing instruction for the minting protocol </li> </ol> <p>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.</p> <p>A ledger that wants to accept ISCC declarations and trigger the minting of valid ISCC-IDs MUST fulfill the following minimum requirements:</p> <ol> <li>The ledger must provide an immutable, complete, time-ordered, append-only sequence of transactions.</li> <li>The legers transaction format must allow for embedding and signing the data required for an ISCC declarations.</li> <li>The Declaration-Set MUST be publicly readable (permisionless).</li> <li>ISCC declarations on the ledger MAY be write-permissioned.</li> </ol> <p>A participating ledger or framework MUST provide documentaation of its implementation of the declaration protocol.</p> <ol> <li>The documentation MUST specify how ISCC declarations can be parsed to decode the Declaration-Set</li> <li>The documentation MUST provide sufficient information to the public such that third parties can independently verify transactions signatures and implement the Minting Protocol</li> <li>The documentation MUST define how a public observer can distinguish between a transaction that declares an ISCC-CODE and other unrelated transactions.</li> </ol>"},{"location":"iep-0013/#5-minting-protocol","title":"5. Minting Protocol","text":"<p>TBD</p>"},{"location":"iep-0013/#6-resolution-protocol","title":"6. Resolution Protocol","text":"<p>TBD</p>"},{"location":"iep-0013/#7-reference-implementation","title":"7. Reference Implementation","text":"<ul> <li>ISCC-ID construction: https://github.com/iscc/iscc-core/blob/main/iscc_core/iscc_id.py</li> <li>EVM registry: https://github.com/iscc/iscc-evm</li> <li>EVM observer: https://github.com/iscc/iscc-observer-evm</li> <li>ISCC-ID resolver: https://github.com/iscc/iscc-registry</li> </ul>"},{"location":"iep-0014/","title":"EVM Based ISCC Registries","text":"IEP: 0014 Title: EVM Based ISCC Registries Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/19 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2022-09-28"},{"location":"iep-0015/","title":"ISCC DID Method","text":"IEP: 0015 Title: ISCC DID Method Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/20 Status: DRAFT Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2022-10-09 <p>Abstract</p> <p>A DID method that identifies decentralized declarations of digital content using ISCC-IDs.</p> <p>Status of This Document</p> <p>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.</p>"},{"location":"iep-0015/#1-introduction","title":"1. Introduction","text":""},{"location":"iep-0015/#11-preface","title":"1.1 Preface","text":"<p>The ISCC DID method specification conforms to the requirements specified in the Decentralized Identifiers v1.0 Specification DID-CORE.</p>"},{"location":"iep-0015/#12-motivation","title":"1.2 Motivation","text":"<p>The need for a universal identifier for digital content has emerged as an increasing amount of dynamic, short-lived and granular digital content is produced, consumed and processed. Commercial interests of many stakeholders depend on proper identification of digital content.</p> <p>Professionally produced digital content but also semi-professional and user-generated content are the currency of the information age. A variety of specific content identifier standards already  exist, but a universal content-dependent identifier for digital media has not yet been developed.</p> <p>In particular, the structure and management of identifiers for digital content have a substantial impact on the level of possible adoption, automation, and the potential for machine-to-machine  communication and innovation within and across different industry sectors.</p> <p>Digital content is dynamic, always in motion, and acted upon globally by a variety of entities with  different interests and requirements. Digital content continuously re-encodes, resizes, and  re-compresses, changing its underlying data as it travels through a complex network of actors and  systems. These circumstances require a special design for a universal identifier that is capable of matching transcoded or otherwise transformed content.</p>"},{"location":"iep-0015/#13-the-iscc","title":"1.3 The ISCC","text":"<p>The ISCC (International Standard Content Code) is a universal and open identification system for text, audio, image, and video content. ISCC-CODEs can be created from media assets by anybody using open source software. Similar content can then be matched by comparing ISCC-CODEs only.</p> <p>Example ISCC-CODE</p> <pre><code>ISCC:KECYCPU3OKIUDZ7TYBRK5HZ4JGPTILLAT2IW7TY7EYIJI4QSK5I353I\nDecoded: ISCC-IMAGE-V0-MCDI-813e9b729141e7f3c062ae9f3c499f342d609e916fcf1f26109472125751beed\n</code></pre> <p>Users can also register ISCC-CODEs on any supported public blockchain to obtain a short and globaly unique ISCC-ID. The ISCC-ID is under the control of the registrant and resolves to an ISCC-CODE,  on-chain metadata and optional off-chain metadata. ISCC-IDs are globaly unique even if the same ISCC-CODE is registered multiple times by different entities. An ISCC-ID is minted  deterministically by observing participating legers and can be reproduced by anybody who observes  the public and immutable registration events.</p> <p>Example ISCC-ID</p> <pre><code>ISCC:MIAGWPTV4J2Z57CI\nDecoded: ID-ETHEREUM-V0-64-6b3e75e2759efc48\n</code></pre>"},{"location":"iep-0015/#14-iscc-id-as-did","title":"1.4 ISCC-ID as DID","text":"<p>The ISCC DID method creates a mechanism to reference digital content with a globaly unique persistent identifier that does not require a centralized registration authority. Instead, the ISCC system defines an open and voluntary cross-chain registration protocol using cryptography and distributed ledger technology.</p> <p>Integrating ISCC with the DID system improves ISCC interoperability. DID documents provide standardized ways to discover services related to the referenced content and its registrant.</p> <p>Verifiable credentials discovered through the DID document  <code>service</code> property can improve trust in otherwise permissionless content registrations. Additionaly the use of decentralized web nodes allow for interoperable discovery and data sovereignity of hosted verifiable credentials.</p> <p>At the same time ISCC would bring open content identification to the Decentalized Identifiers  ecosystem.</p>"},{"location":"iep-0015/#2-method-syntax","title":"2. Method Syntax","text":""},{"location":"iep-0015/#21-method-name","title":"2.1 Method Name","text":"<ol> <li>The name that shall identify this DID method is: <code>iscc</code>.</li> <li>A DID that uses this method MUST begin with the following prefix: <code>did:iscc:</code>.</li> <li>According to the DID specification, this string MUST be in lowercase.</li> </ol>"},{"location":"iep-0015/#22-method-specific-identifier","title":"2.2 Method Specific Identifier","text":"<p>The ISCC DID scheme conforms to the DID Syntax and is defined by the follwing ABNF:</p> <p>ISCC DID scheme ABNF</p> <pre><code>iscc-did = \"did:iscc:\" iscc\niscc     = 10*88(numbers / letters)\nnumbers  = %x32-37  ; 2-7\nletters  = %x61-7A  ; a-z\n</code></pre> <ol> <li>The data structure of the ISCC is <code>&lt;MainType&gt;&lt;SubType&gt;&lt;Version&gt;&lt;Length&gt;&lt;ISCC-BODY&gt;</code></li> <li>The method specific identifier is a lower-cased base32 representation of the ISCC structure.</li> <li>The regular expression for this DID method is <code>^did:iscc:[2-7a-z]{10,88}$</code></li> </ol>"},{"location":"iep-0015/#23-iscc-did-example","title":"2.3 ISCC DID Example","text":"<p>DID representation of an ISCC-ID</p> <pre><code>did:iscc:miagwptv4j2z57ci\n</code></pre>"},{"location":"iep-0015/#3-method-operations","title":"3. Method Operations","text":""},{"location":"iep-0015/#31-creation","title":"3.1 Creation","text":"<ol> <li>An ISCC DID MUST be created by a signed and confirmed ledger transaction that declares an    ISCC-CODE in  accordance with the cross-chain declaration protocol.</li> <li>The initial controller of a newly created ISCC DID MUST be the     did:pkh representation of    the blockchain account that signed the declaration transaction.</li> <li>The controller MAY set a custom DID Document at declaration time by embedding or referencing it    from ISCC Metadata</li> </ol>"},{"location":"iep-0015/#32-read","title":"3.2 Read","text":"<ol> <li>A basic DID document is implicitly created with every ISCC declaration and MUST be     deterministicaly derived from on-chain metadata.</li> <li>Extended DID document properties MAY be imported from externaly referenced ISCC Metadata</li> </ol>"},{"location":"iep-0015/#33-update-deactivate","title":"3.3 Update &amp; Deactivate","text":"<p>The ISCC DID MAY be updated or deactivated in accordence with the chain specific implementation of the ISCC declaration protocol.</p>"},{"location":"iep-0015/#4-verifiable-data-registry","title":"4. Verifiable Data Registry","text":"<p>The verifiable data registry or \"target system\" for ISCC DIDs is a federation of existing public ledgers that support the  ISCC declaration protocol. The protocol can be implemented on most public ledgers (even without smart  contracts) that provide an orderd, immutable, append-only history of signed transactions. </p> <p> </p> Figure 1 - ISCC Verifiable Data Registry"},{"location":"iep-0015/#5-did-document","title":"5. DID Document","text":"<p>DID documents are sourced from on-chain metadata and optionally from immutably or mutably referenced off-chain metadata. </p> <p>All information required to construct a minimal valid DID document from an ISCC declaration is available on-chain and can be dynamically transformed and presented as DID document by a DID  driver implementation.</p> <p>Minimal ISCC DID Document example</p> <pre><code>{\n  \"@context\": \"https://www.w3id.org/ns/did/v1\"\n  \"id\": \"did:iscc:miagwptv4j2z57ci\",\n  \"controller\": \"did:pkh:eip155:1:0x901ee44e3bddf4bc1c08a2ed229498512f8bcfdc\",\n  \"alsoKnownAs\": \"iscc:kecycpu3okiudz7tybrk5hz4jgptillat2iw7ty7eyiji4qsk5i353i\",\n  \"service\": [{\n    \"id\":\"did:iscc:miagwptv4j2z57ci#iscc-metadata\",\n    \"type\": \"IsccMetadata\", \n    \"serviceEndpoint\": \"ipfs://bafybeiccys7kilr3rynlhoelrdn6ragpbfoti73h4e3oszbgd5inthicja/iscc-metadata/43.json\"\n  }]\n}\n</code></pre> <ol> <li>The DID subject (<code>id</code>-property) MUST be the ISCC-ID in DID representation.</li> <li>The DID controller (<code>controller</code>-property) MUST be constructed deterministically by converting   the blockchain account that signed the declaration transaction to a <code>did:pkh</code>.</li> <li>The <code>alsoKnownAs</code>-property MUST be set to the ISCC-CODE registered by the transaction.</li> <li>If the original ISCC declaration includes a link to off-chain metadata the DID document MUST   include the reference via an entry into the <code>service</code>-property with type \"IsccMetadata\". The    referenced <code>serviceEndpoint</code> SHOULD return a document of type http://purl.org/iscc/context.</li> </ol> <p>Info</p> <p>Properties like <code>verificationMethod</code>, <code>authentication</code>, <code>assertionMethod</code> etc. are left out  intentionally, as their autoritative values are managed by the DID document associated with the <code>controller</code> that can be resolved separately.</p> <p>To be defined</p> <p>Additional/Optional DID document data MAY be added off-chain in mutable or immutable modes and retrived and incjected by the DID driver in realtime to compose an extended DID document that includes other properties like <code>service</code>.</p>"},{"location":"iep-0015/#6-resolving-dids","title":"6. Resolving DIDs","text":"<ol> <li>An ISCC DID can be resolved by querying an instantiation of an ISCC content registry.</li> <li>The authenticity of the response can be verified through the referenced on-chain transaction.</li> </ol> Figure 2 - ISCC DID Architecture"},{"location":"iep-0015/#7-security-considerations","title":"7. Security Considerations","text":"<p>Implementers should be aware that ISCC-CODEs are not cryptographic hashes but descriptors or  similarity preserving (soft) hashes. As such they leak information about the structure of the identified content. This is by design and necessary to support similarity matching with ISCC-CODEs.</p> <p>An ISCC DID document does not need to contain a proof property. All operations are authenticated with the signature of the transaction payload sent to the network of the originating ledger.  This signature is generated using a key specified in the corresponding DID Document.</p>"},{"location":"iep-0015/#8-privacy-considerations","title":"8. Privacy Considerations","text":"<p>ISCC declarations do not publish any personal data on-chain. Declarers may optionally reference off-chain metadata related to their content registration. Such metadata may contain personal data such as creator and rightsholder information. The assumption is that creators have an interest in proper attribution. Applications that implement ISCC declarations are advised to inform users about any privacy related matters specific to their application.</p>"},{"location":"iep-0015/#9-reference-implementation","title":"9. Reference Implementation","text":"<p>An end-to-end reference implementation of the decentralized content registry is manifested by the following modules:</p> <ul> <li>Codec and Algorithms: https://github.com/iscc/iscc-core</li> <li>ISCC Metadata: https://github.com/iscc/iscc-schema</li> <li>EVM Smart Contracts: https://github.com/iscc/iscc-evm</li> <li>EVM Chain Observer: https://github.com/iscc/iscc-observer-evm</li> <li>ISCC Content Registry: https://github.com/iscc/iscc-registry / https://iscc.id</li> <li>ISCC DID driver: https://github.com/iscc/iscc-did-driver / https://did.iscc.id</li> </ul>"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"ISCC - Enhancement Proposals (IEPs)","text":""},{"location":"#what-is-an-iep","title":"What is an IEP?","text":"<p>IEP stands for ISCC Enhancement Proposal. An IEP is a design document providing information to the ISCC community, or describing a new feature for the ISCC or its processes or environment.</p> <p>IEPs are a mechanism for proposing new features, for collecting community input on an issue, and for documenting design decisions. The IEP author is responsible for building consensus within the community and documenting dissenting opinions.</p> <p>Because the IEPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.</p>"},{"location":"#list-of-ieps","title":"List of IEPs","text":"ID Title Type Status IEP-0000 IEP Purpose and Guidelines Process Draft IEP-0001 ISCC Structure and Format Core Draft IEP-0002 ISCC-UNIT Meta-Code Core Draft IEP-0003 ISCC-UNIT Condent-Code Text Core TBD IEP-0004 ISCC-UNIT Condent-Code Image Core TBD IEP-0005 ISCC-UNIT Condent-Code Audio Core TBD IEP-0006 ISCC-UNIT Condent-Code Video Core TBD IEP-0007 ISCC-UNIT Condent-Code Mixed Core TBD IEP-0008 ISCC-UNIT Data-Code Core TBD IEP-0009 ISCC-UNIT Instance-Code Core TBD IEP-0010 ISCC-CODE Core TBD IEP-0011 ISCC-ID Core TBD IEP-0012 ISCC Metadata Core TBD IEP-0013 ISCC Decentralized Content Registry Core Draft IEP-0014 EVM Based ISCC Registries Core TBD IEP-0015 ISCC DID Method Core Draft"},{"location":"iep-0000/","title":"IEP-0: IEP Purpose and Guidelines","text":"IEP: 0000 Title: IEP Purpose and Guidelines Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/2 Status: Draft Type: Process License: BSD-2-Clause Created: 2022-08-28 Updated: 2022-09-23"},{"location":"iep-0000/#1-what-is-an-iep","title":"1. What is an IEP?","text":"<p>An ISCC Enhancement Proposal (IEP) is a design document providing information to the ISCC community, or describing a new feature for the ISCC or its processes or environment. An IEP should provide a concise technical specification of a feature and a rationale for the feature. IEPs have no special status except that accorded by the community.</p> <p>IEPs are a mechanism for proposing new features, for collecting community input on an issue, and for documenting design decisions. The IEP author is responsible for building consensus within the community and documenting dissenting opinions.</p> <p>Because the IEPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.</p>"},{"location":"iep-0000/#2-iep-audience","title":"2. IEP audience","text":"<p>The typical primary audience for IEPs are the developers of ISCC implementations.</p> <p>However, other parts of the ISCC community may also choose to use the process (particularly for Informational IEPs) to document expected API conventions and to manage complex design coordination problems that require collaboration across multiple projects.</p>"},{"location":"iep-0000/#3-iep-workflow","title":"3. IEP workflow","text":"<p>The IEP process begins with a new idea for the ISCC. Each potential IEP must have a champion - someone who writes the IEP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea.</p> <p>Small enhancements or patches to a particular piece of software often don't require coordination between multiple projects or implementations; these don't need an IEP and should be injected into the relevant project-specific development workflow with a patch submission to the applicable issue tracker.</p> <p>After investigating past work, the best way to proceed is by opening issue for discussion about the new idea. Following a discussion, the proposal should be submitted to the IEPs git repository as a pull request. This draft must be written in IEP style as described below, and named with an alias such as \"iep-johndoe-new-semantic-id\" until an editor has assigned it an IEP number (authors MUST NOT self-assign IEP numbers).</p> <p>When the IEP draft is complete, an IEP editor will assign the IEP a number, label it as Core, Informational, or Process, and merge the pull request to the IEPs git repository. The IEP editors will not unreasonably reject an IEP. Reasons for rejecting IEPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility. For an IEP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.</p> <p>The IEP author may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the author as pull requests.</p>"},{"location":"iep-0000/#31-transferring-iep-ownership","title":"3.1 Transferring IEP ownership","text":"<p>It occasionally becomes necessary to transfer ownership of IEPs to a new champion. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the IEP process, or is unreachable or not responding to email.</p> <p>If you are interested in assuming ownership of an IEP, send a message asking to take over, addressed to both the original author and the IEP editors. If the original author doesn't respond to email in a timely manner, the IEP editors will make a unilateral decision.</p>"},{"location":"iep-0000/#32-iep-editors","title":"3.2 IEP editors","text":"<p>The current IEP editors are:</p> <ul> <li>Titusz Pan tp@iscc.foundation</li> </ul>"},{"location":"iep-0000/#33-iep-editor-responsibilities","title":"3.3 IEP editor responsibilities","text":"<p>The IEP editors subscribe to the IEP issue tracker. Correspondence outside the issue tracker should be sent (or CC'd) to the IEP editors.</p> <p>For each new IEP that comes in an editor does the following:</p> <ul> <li> <p>Read the IEP to check if it is ready: sound and complete. The ideas must make technical sense.</p> </li> <li> <p>The title should accurately describe the content.</p> </li> <li> <p>Motivation and backward compatibility (when applicable) must be addressed.</p> </li> <li> <p>Licensing terms must be acceptable for IEPs.</p> </li> <li> <p>If the IEP isn't ready, the editor will send it back to the author for revision, with specific   instructions.</p> </li> <li> <p>Once the IEP is ready for the repository it should be submitted as a \"pull request\" to the IEPs   git repository where it may get further feedback.</p> </li> </ul> <p>The IEP editor will:</p> <ul> <li>Assign an IEP number in the pull request.</li> <li>Merge the pull request when it is ready.</li> <li>List the IEP in README.md.</li> </ul> <p>The IEP editors are intended to fulfill administrative and editorial responsibilities. The IEP editors monitor IEP changes, and update IEP headers as appropriate.</p>"},{"location":"iep-0000/#4-iep-format-and-structure","title":"4. IEP format and structure","text":"<p>IEPs should be written in Markdown format.</p> <p>Each IEP should have the following parts:</p> <ul> <li>Preamble - Headers containing metadata about the IEP (see below).</li> <li>Abstract - A short (~200 word) description of the issue being addressed.</li> <li>Motivation - A motivation section is critical for IEPs that want to change pre-existing   specifications. It should clearly explain why the existing specification is inadequate to address   the problem that the IEP solves. This section may be omitted if the motivation is evident.</li> <li>Specification - The specification should describe the syntax and semantics of any new feature. The   specification should be detailed enough to allow competing, interoperable implementations.</li> <li>Rationale - The rationale fleshes out the specification by describing what motivated the design   and why particular design decisions were made. It should describe alternate designs that were   considered and related work. The rationale should provide evidence of consensus within the   community and discuss important objections or concerns raised during discussion around the IEP.</li> <li>Backwards compatibility - All IEPs that introduce backwards incompatibilities must include a   section describing these incompatibilities and their severity. The IEP must explain how the author   proposes to deal with these incompatibilities.</li> <li>Reference implementation - A reference implementation must be completed before a Core IEP is given   status Stable, but it need not be completed before the IEP is accepted. The stable implementation   must include test code and documentation.</li> <li>Copyright - The IEP must be explicitly licensed under acceptable copyright   terms see below.</li> </ul>"},{"location":"iep-0000/#41-iep-header-preamble","title":"4.1 IEP header preamble","text":"<p>Each IEP must begin with a header preamble. The headers must appear in the following order. Headers marked with \"*\" are optional and are described below. All other headers are required.</p> <pre><code>  IEP: &lt;IEP number, or \"?\" before being assigned&gt;\n  Title: &lt;IEP title; maximum 44 characters&gt;\n  Author: &lt;list of authors' names and email addresses&gt;\n  Comments: &lt;link to issue page for comments&gt;\n  Status: &lt;Draft | Deferred | Withdrawn | Proposed | Rejected | Stable | Obsolete&gt;\n  Type: &lt;Core | Informational | Process&gt;\n  License: &lt;abbreviation for approved license(s)&gt;\n  Created: &lt;date created on, in ISO 8601 (yyyy-mm-dd) format&gt;\n  Updated: &lt;date updated on, in ISO 8601 (yyyy-mm-dd) format&gt;\n* Replaces: &lt;IEP number&gt;\n* Superseded-By: &lt;IEP number&gt;\n</code></pre> <p>The Author header lists the names and email addresses of all the authors/owners of the IEP. The format of the Author header value must be</p> <pre><code>Random J. User &lt;address@dom.ain&gt;\n</code></pre> <p>If there are multiple authors, each should be on a separate line.</p> <p>The Type header specifies the type of IEP: Core, Informational, or Process.</p> <p>The Created header records the date that the IEP was assigned a number. Dates should be in yyyy-mm-dd format, e.g. 2001-08-14.</p> <p>IEPs may have a Superseded-By header indicating that an IEP has been rendered obsolete by a later document; the value is the number of the IEP that replaces the current document. The newer IEP must have a Replaces header containing the number of the IEP that it rendered obsolete.</p>"},{"location":"iep-0000/#5-iep-types","title":"5. IEP Types","text":"<p>There are three kinds of IEPs:</p> <ul> <li>A Core IEP describes any change that affects most or all ISCC implementations, such as a   change to the algorithms for creating ISCCs, or any change or addition that affects the   interoperability of applications using the ISCC. Core IEPs consist of two parts, a design document   and a reference implementation.</li> <li>An Informational IEP describes an ISCC design issue, or provides general guidelines or   information to the ISCC community, but does not propose a new feature. Informational IEPs do not   necessarily represent a ISCC community consensus or recommendation, so users and implementors are   free to ignore Informational IEPs or follow their advice.</li> <li>A Process IEP describes a process surrounding ISCC, or proposes a change to (or an event in) a   process. Process IEPs are like Core IEPs but apply to areas other than the ISCC algorithms itself.   Examples include procedures, guidelines, changes to the decision-making process, and changes to   the tools or environment used in ISCC development.</li> </ul>"},{"location":"iep-0000/#6-iep-status","title":"6. IEP status","text":"<p>The typical paths of the status of IEPs are as follows:</p> <pre><code>flowchart LR\n    B[Draft]\n    B --&gt; C[Poposed]\n    B &lt;--&gt; D[Deferred]\n    B &lt;--&gt; E[Withdrawn]\n    C --&gt; F[Stable]\n    C --&gt; G[Rejected]\n    F --&gt; H[Obsolete]\n</code></pre> <p>Champions of an IEP may decide on their own to change the status between Draft, Deferred, or Withdrawn. An IEP editor may also change the status to Deferred when no progress is being made on the IEP.</p> <p>An IEP may only change status from Draft to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Stable status.</p> <p>IEPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such an IEP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph.</p> <p>An IEP may change status from Draft to Stable when it achieves rough consensus on the issue tracker and sufficient real-world adoption. Such a proposal is said to have rough consensus if it has been open to discussion on the issue tracker for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances.</p> <p>Software authors are encouraged to publish summaries of what IEPs their software supports to aid in verification of status changes.</p> <p>Should an IEP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Stable status.</p> <p>When a Stable IEP is no longer relevant, its status may be changed to Obsolete. This change must also be objectively verifiable and/or discussed.</p>"},{"location":"iep-0000/#7-iep-licensing","title":"7. IEP licensing","text":"<p>New IEPs may be accepted with the following licenses. Each new IEP must identify at least one acceptable license in its preamble. The License header in the preamble must be placed befor the Created header. Each license must be referenced by their respective abbreviation given below.</p> <p>IEPs are not required to be exclusively licensed under approved terms, and may also be licensed under unacceptable licenses in addition to at least one acceptable license. In this case, only the acceptable license(s) should be listed in the License header.</p>"},{"location":"iep-0000/#71-acceptable-licenses","title":"7.1 Acceptable licenses","text":"<ul> <li>BSD-2-Clause: OSI-approved BSD 2-clause license</li> <li>BSD-3-Clause: OSI-approved BSD 3-clause license</li> <li>CC0-1.0: Creative Commons CC0 1.0 Universal</li> <li>Apache-2.0: Apache License, version 2.0</li> <li>CC-BY-4.0: Creative Commons Attribution 4.0 International</li> <li>CC-BY-SA-4.0: Creative Commons Attribution-ShareAlike 4.0 International</li> <li>MIT: Expat/MIT/X11 license</li> </ul>"},{"location":"iep-0000/#8-history","title":"8. History","text":"<p>This document was derived heavily from Bitcoin\u2019s BIP-0002 which in turn was derived from Python\u2019s PEP-0001. In many places text was simply copied and modified. The original authors of BIP-0002 and PEP-0001 are not responsible for its use in the ISCC Enhancement Proposals, and should not be bothered with technical questions specific to ISCC or the IEPs.</p>"},{"location":"iep-0001/","title":"ISCC Structure and Format","text":"IEP: 0001 Title: ISCC Structure and Format Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/6 Status: Draft Type: Core License: CC-BY-4.0 Created: 2022-09-23 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0001/#1-abstract","title":"1. Abstract","text":"<p>This document describes the coding scheme for the International Standard Content Code (ISCC).</p>"},{"location":"iep-0001/#2-motivation","title":"2. Motivation","text":"<p>The ISCC is a similarity preserving identifier for all kinds of digital content. As such the ISCC requires a universal coding scheme to meet a broad set of use cases and support different media types. The coding scheme for all ISCCs should be:</p> <ol> <li>compact</li> <li>interoperable</li> <li>modular</li> <li>extensible</li> <li>self-describing</li> </ol>"},{"location":"iep-0001/#3-general-structure-of-iscc","title":"3. General structure of ISCC","text":"<ol> <li>An ISCC shall be composed of an ISCC-HEADER and an ISCC-BODY.</li> <li>The ISCC-HEADER shall describe the MainType, SubType, Version, and Length of its ISCC-BODY.</li> <li>An ISCC-UNIT shall be an ISCC based on one specific algorithm.</li> <li>An ISCC-CODE shall be an ISCC composed of two or more different ISCC-UNITs.</li> </ol> Figure 1 - General Structure of an ISCC"},{"location":"iep-0001/#4-iscc-header","title":"4. ISCC-HEADER","text":"<p>The ISCC-HEADER is a variable sized bitstream composed of an ordered sequence of the 4 header-fields MainType, SubType, Version, Length.</p> <p>Each header-field is a bitstream with a length between 4 and 16 bits and encodes an integer value between 0 and 4679 with the following encoding scheme:</p> <ol> <li>The total bit-length of a header-field shall be determined by its prefix-bits.</li> <li>The prefix-bits shall be followed by data-bits.</li> <li>The data-bits shall be interpreted as unsigned integer values plus the maximum value of the    preceding range.</li> <li>If the total length of all header-fields in number of bits is not divisible by 8, the header    shall be padded with 4 zero bits (0000) on the right side.</li> </ol> <p>Table 1 \u2013 Variable length ISCC-HEADER field encoding</p> Prefix bits Number of nibbles Number of data bits Integer range 0 1 3 0-7 10 2 6 8-71 110 3 9 72-583 1110 4 12 584-4679 <p>Header-field examples</p> <pre><code>0 = 0000\n1 = 0001\n\u2026\n7 = 0111\n8 = 1000 0000\n9 = 1000 0001\n</code></pre> <p>The interpretation of the integer value of a header-field shall be context dependent:</p> <ol> <li>For the MainType and SubType fields it shall be an identifier for the designated type.</li> <li>For the Version field it shall be the literal version number.</li> <li>For the Length field of ISCC-UNITs it shall be a number used as a multiplier to calculate the bit length of the ISCC-BODY.</li> <li>For the Length field of ISCC-CODEs it shall be a bit-pattern encoding the combination of ISCC-UNITs and the bit-length of the ISCC-BODY.</li> </ol>"},{"location":"iep-0001/#41-maintypes","title":"4.1 MainTypes","text":"<p>The MainType header-field shall signify the type of the ISCC.</p> <p>Backward incompatible updates to an algorithm associated with a MainType shall be indicated by incrementing the version field of the ISCC-HEADER of the respective MainType.</p> <p>Note</p> <p>The first edition of the standard specifies initial algorithms (version 0) for all reserved MainTypes except for the SEMANTIC type which is not currently defined.</p> <p>Table 2 \u2013 Reserved ISCC MainTypes</p> ID Symbol Bits Definition 0 META 0000 An ISCC-UNIT that matches on metadata similarity 1 SEMANTIC 0001 An ISCC-UNIT that matches on semantic content similarity 2 CONTENT 0010 An ISCC-UNIT that matches on perceptual content similarity 3 DATA 0011 An ISCC-UNIT that matches on data similarity 4 INSTANCE 0100 An ISCC-UNIT that matches on data identity 5 ISCC 0101 An ISCC-CODE composed of two or more headerless ISCC-UNITs for multi-modal matching"},{"location":"iep-0001/#42-subtypes","title":"4.2 SubTypes","text":"<p>The MainTypes META, DATA, and INSTANCE shall have a single default SubType NONE encoded with the bits 0000.</p> <p>The MainTypes SEMANTIC, CONTENT, and ISCC shall have SubTypes that signify the perceptual mode.</p> <p>Table 3 \u2013 Reserved SubTypes for MainTypes ISCC, SEMANTIC, and CONTENT</p> ID Symbol Bits Definition 0 TEXT 0000 Match on text similarity 1 IMAGE 0001 Match on image similarity 2 AUDIO 0010 Match on audio similarity 3 VIDEO 0011 Match on video similarity 4 MIXED 0100 Match on multi-modal similarity <p>Table 4 \u2013 Additional Reserved SubTypes for the MainType ISCC</p> ID Symbol Bits Definition 5 SUM 0101 Composite of ISCC-UNITs including only Data- and Instance-Code 6 NONE 0110 Composite ISCC-UNITs including Meta-, Data- and Instance-Code"},{"location":"iep-0001/#43-version","title":"4.3 Version","text":"<p>All ISCC-HEADERs shall have a version header-field of 0000 for the first edition of the standard.</p> <p>Table 5 \u2013 Reserved ISCC Versions</p> ID Symbol Bits Definition 0 V0 0000 Initial version of ISCC-UNITs and ISCC-CODE"},{"location":"iep-0001/#44-length","title":"4.4 Length","text":"<p>The encoding of the Length header-field shall be specific to the MainType.</p>"},{"location":"iep-0001/#441-length-of-iscc-units","title":"4.4.1 Length of ISCC-UNITs","text":"<p>For ISCC-UNITs of the MainTypes META, SEMANTIC, CONTENT, DATA, and INSTANCE the length value shall be encoded as the number of 32-bit blocks of the ISCC-BODY in addition to the minimum length of 32 bits.</p> <p>Table 6 \u2013 Reserved length field values (multiples of 32 bit)</p> ID Symbol Bits Definition 0 L32 0000 Length of body is 32 bits (minimum length) 1 L64 0001 Length of body is 64 bits (default length) 2 L96 0010 Length of body is 96 bits 3 L128 0011 Length of body is 128 bits 4 L160 0100 Length of body is 160 bits 5 L192 0101 Length of body is 192 bits 6 L224 0110 Length of body is 224 bits 7 L256 0111 Length of body is 256 bits"},{"location":"iep-0001/#442-length-of-iscc-codes","title":"4.4.2 Length of ISCC-CODEs","text":"<ol> <li> <p>For ISCC-CODEs the length value shall designate the composition of ISCC-UNITs.</p> </li> <li> <p>The Data-Code and Instance-Code shall be mandatory 64-bit components of an ISCC-CODE.</p> </li> <li> <p>The first data-bit shall designate the presence of a 64-bit Meta-Code.</p> </li> <li> <p>The second data-bit shall designate the presence of a 64-bit Semantic-Code.</p> </li> <li> <p>The third data-bit shall designate the presence of a 64-bit Content-Code.</p> </li> <li> <p>The length of an ISCC-CODE shall be calculated as the number of active data-bits times 64 plus    128 bits of mandatory data.</p> </li> </ol> <p>Table 7 \u2013 Reserved length field values (for MainType ISCC)</p> ID Symbol Bits Definition 0 SUM 0000 No optional ISCC-UNITs. Length of body is 128 bits. 1 CDI 0001 Includes Content-Code. Length of body is 192 bits 2 SDI 0010 Includes Semantic-Code. Length of body is 192 bits 3 SCDI 0011 Includes Semantic- and Content-Code. Length of body is 256 bits 4 MDI 0100 Includes Meta-Code. Length of body is 192 bits 5 MCDI 0101 Includes Meta-Code and Content-Code. Length of body is 256 bits 6 MSDI 0110 Includes Meta-Code and Semantic-Code. Length of body is 256 bits 7 MSCDI 0111 Includes Meta-, Semantic-, and Content-Code. Length is 320 bits"},{"location":"iep-0001/#5-iscc-body","title":"5. ISCC-BODY","text":"<ol> <li>The preceding MainType, SubType, and Version fields shall qualify the semantics of an ISCC-BODY.</li> <li>The Length field shall determine the number of bits of an ISCC-BODY.</li> </ol>"},{"location":"iep-0001/#6-encoding-of-iscc","title":"6. Encoding of ISCC","text":""},{"location":"iep-0001/#61-canonical-form","title":"6.1 Canonical form","text":"<p>The printable canonical form of an ISCC shall be its RFC 4648 Base32 encoded representation without padding and prefixed with \u201cISCC:\u201d.</p> <p>Canonical ISCC-CODE example</p> <p>ISCC:KEC43HJLPUSHVAZT66YLPUWNVACWYPIV533TRQMWF2IUQYSP5LA4CTY</p>"},{"location":"iep-0001/#62-uri-encoding","title":"6.2 URI encoding","text":"<ol> <li>An ISCC shall be encodable as a Uniform Resource Identifier (URI) according to RFC 3986.</li> <li>The URI representation shall have the format <code>&lt;scheme&gt;:&lt;path&gt;</code>.</li> <li>The URI scheme shall be the string \u201ciscc\u201d.</li> <li>The URI path shall be the lower-cased base32 representation of an ISCC without padding.</li> </ol> <p>URI encoded ISCC-CODE example</p> <p>iscc:kec43hjlpushvazt66ylpuwnvacwypiv533trqmwf2iuqysp5la4cty</p>"},{"location":"iep-0001/#63-multiformats-encoding","title":"6.3 Multiformats encoding","text":"<ol> <li>The ISCC shall be encodable as    a multibase string.</li> <li>The multicodec identifier of    an ISCC shall be <code>0xcc01</code>.</li> <li>A Multiformat representation of an ISCC shall be prefixed with a    Multibase code.</li> <li>The encoding scheme shall be <code>&lt;multibase&gt;&lt;multicodec&gt;&lt;iscc-header&gt;&lt;iscc-body&gt;</code>.</li> </ol> <p>ISCC shall support the following multibase encodings:</p> <p>Table 8 \u2013 Supported multibase encodings</p> Encoding Code Definition base16 f hexadecimal base32 b RFC4648 case-insensitive - no padding base32hex v Match on audio similarity base58btc z base58 bitcoin base64url u RFC4648 no padding <p>Table 9 \u2013 Examples of ISCCs in multiformats encoding</p> Encoding Example MF base16 fcc015105cd9d2b7d247a8333f7b0b7d2cda8056c3d15eef738c1962e9148624feac1c14f MF base32 bzqavcbontuvx2jd2qmz7pmfx2lg2qblmhuk655zyyglc5ekimjh6vqobj4 MF base32hex vpg0l21edjklnq93qgcpvfc5nqb6qg1bc7kauttpoo6b2t4a8c97ulge19s MF base58btc z2Yr3BMx3Rj56fyYkNvfa19PCk4SjspQhpVWoLSGg9yXr4vUGsx MF base64url uzAFRBc2dK30keoMz97C30s2oBWw9Fe73OMGWLpFIYk_qwcFP"},{"location":"iep-0001/#64-readable-encoding","title":"6.4 Readable encoding","text":"<ol> <li>The ISCC shall be encodable in human-readable representation.</li> <li>The readable representation shall encode the header-fields with their symbols and the ISCC-BODY    in base16 lower-case.</li> <li>The header-fields and the ISCC-BODY shall be separated with hyphens.</li> </ol> <p>Example of human-readable ISCC-CODE</p> <p>ISCC-IMAGE-V0-MCDI-cd9d2b7d247a8333f7b0b7d2cda8056c3d15eef738c1962e9148624feac1c14f</p>"},{"location":"iep-0001/#7-reference-implementation","title":"7. Reference implementation","text":"<p>The reference implementation of this coding scheme is published in the iscc-core python package in the codec.py module.</p>"},{"location":"iep-0002/","title":"ISCC-UNIT Meta-Code","text":"IEP: 0002 Title: ISCC-UNIT Meta-Code Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/7 Status: Draft Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0002/#1-general","title":"1. General","text":"<p>The Meta-Code is a similarity hash generated from referent seed metadata as defined in  IEP-0012</p>"},{"location":"iep-0002/#2-purpose","title":"2. Purpose","text":"<p>The Meta-Code shall support the following use cases:</p> <ol> <li>clustering of digital assets based on their metadata;</li> <li>discovery of digital assets with similar metadata;</li> <li>verification or manual disambiguation of matching codes.</li> </ol>"},{"location":"iep-0002/#3-format","title":"3. Format","text":"<p>The Meta-Code shall have the data format as illustrated in Figure 2:</p> <p> </p> Figure 2 - Data format of the Meta-Code <p>EXAMPLE: 64-bit Meta-Code in its canonical form:</p> <p>ISCC:AAAUL6P7RMVNT4UJ</p> <p>EXAMPLE: 256-bit Meta-Code in its canonical form:</p> <p>ISCC:AADUL6P7RMVNT4UJJ4SMTDXBL5JFZ5XPCDKO42XYPJEVQ4L7PTYDORQ</p>"},{"location":"iep-0002/#4-inputs","title":"4. Inputs","text":"<p>Seed metadata is the metadata that is used as the input to calculate the Meta-Code and has three  possible elements:</p> <ol> <li>name (required): the name or title of the work manifested by the digital asset;</li> <li>description (optional): a disambiguating textual description of the digital asset;</li> <li>meta (optional): subject, industry, or use-case specific metadata.</li> </ol> <p>NOTE 1</p> <p>Because seed metadata is used to construct the Meta-Code, changes to its value may produce  different (and therefore no longer matching) Meta-Codes. Seed metadata is stored and carried  along unaltered with ISCC Metadata if automated verification of the Meta-Code based on the  original seed metadata is required.</p> <p>NOTE 2</p> <p>The identifier standards and their schemas defined by ISO/TC 46/SC 9 provide helpful guidance  in selecting seed metadata.</p>"},{"location":"iep-0002/#41-name-element","title":"4.1 name element","text":"<p>The text input for the name element shall be pre-processed before similarity hashing as follows:</p> <ol> <li>Apply ISO/IEC 10646 NFKC Unicode Normalization  (see Unicode Normalization Forms https://unicode.org/reports/tr15/#Norm_Forms). </li> <li>Remove control characters (see Unicode Character Database https://www.unicode.org/ucd/). </li> <li>Strip leading and trailing whitespace. </li> <li>Trim the end of the text such that the UTF-8 encoded size does not exceed 128 bytes.</li> </ol>"},{"location":"iep-0002/#42-description-element","title":"4.2 description element","text":"<p>Text input for the description element shall be pre-processed before similarity hashing as follows:</p> <ol> <li>Apply NFKC Unicode Normalization.</li> <li>Remove control characters (as specified by Unicode Character Database) except for the following newline characters:<ul> <li>U000A - Line Feed;</li> <li>U000B - Vertical Tab;</li> <li>U000C - Form Feed;</li> <li>U000D - Carriage Return;</li> <li>U0085 - Next Line;</li> <li>U2028 - Line Separator;</li> <li>U2029 - Paragraph Separator.</li> </ul> </li> <li>Collapse more than two consecutive newlines characters to a maximum of two consecutive newlines.</li> <li>Strip leading and trailing whitespace characters.</li> </ol>"},{"location":"iep-0002/#43-meta-element","title":"4.3 meta element","text":"<ol> <li>The value of the meta element shall be wrapped in a RFC 2397 Data-URL.</li> <li>The value of the meta element may include any conceivable and supportive metadata such as for example:<ul> <li>JSON serialized metadata (<code>data:application/json;base64,&lt;data&gt;</code>);</li> <li>JSON-LD serialized metadata (<code>data:application/ld+json;base64,&lt;data&gt;</code>);</li> <li>XML serialized metadata (<code>data:application/xml;base64,&lt;data&gt;</code>);</li> <li>MARC21 XML (<code>data:application/xml;base64,&lt;data&gt;</code>);</li> <li>IPTC NewsML (<code>data:application/vnd.iptc.g2.newsitem+xml;base64,&lt;data&gt;</code>);</li> <li>a file header (<code>data:application/octet-stream;base64,&lt;data&gt;</code>);</li> <li>a thumbnail image (<code>data:image/png;base64,&lt;data&gt;</code>);</li> <li>an audio sample (<code>data:audio/mp4;base64,&lt;data&gt;</code>).</li> </ul> </li> <li>If the value of the meta element is JSON or JSON-LD it shall be serialized with RFC 8785 JCS canonicalization before being wrapped in a Data-URL.</li> <li>If the value of the meta element is XML it shall be serialized as Canonical XML.</li> <li>The Data-URL shall be pre-processed before similarity hashing as follows:<ol> <li>Decode the base64 encoded data section of the Data URL to a raw bitstream without further interpretation.</li> </ol> </li> </ol>"},{"location":"iep-0002/#5-outputs","title":"5. Outputs","text":"<p>Meta-Code processing shall generate the following output elements for inclusion into the produced  ISCC metadata:</p> <ol> <li>iscc (required): the ISCC Meta-Code in its canonical form;</li> <li>name (required): the pre-processed value of the name element;</li> <li>meta (optional): the unaltered value of the meta element;</li> <li>description (optional): the pre-processed value of the description element;</li> <li>metahash (required): a cryptographic hash of the seed metadata.</li> </ol> <p>NOTE 1</p> <p>The reference implementation uses a multihash <sup>1</sup> encoded BLAKE3 <sup>2</sup> value for the metahash element.</p> <p>NOTE 2</p> <p>An ISCC processor may produce other custom output elements, which are helpful to identify the digital asset.</p>"},{"location":"iep-0002/#6-seed-metadata","title":"6. Seed metadata","text":""},{"location":"iep-0002/#61-meta-code-processing","title":"6.1 Meta-Code processing","text":"<p>The Meta-Code shall be constructed from 2 similarity hashes interleaved in 32-bit chunks by  selecting the elements according to the algorithm illustrated in Figure 3.</p> <p> </p> Figure 3 - Meta-Code processing logic <ol> <li>If the name element is unavailable, Meta-Code generation shall be skipped.</li> <li>The first part of the similarity hash for the Meta-Code shall be generated from the name element.</li> <li>The second part of the similarity hash shall be generated from the meta element. </li> <li>If the meta element is unavailable, the second part of the similarity hash shall be generated from the description element.</li> <li>If the description element is unavailable, the second part of the similarity hash shall also be generated from the name element.</li> </ol>"},{"location":"iep-0002/#62-meta-hash-processing","title":"6.2 Meta-Hash processing","text":"<p>The Meta-Hash shall be constructed from the seed metadata by selecting input elements according to  the algorithm illustrated in Figure 4.</p> <p> </p> Figure 4 - Meta-Hash processing logic <ol> <li>If the name element is unavailable, Meta-Hash generation shall be skipped.</li> <li>If the meta element is available, the decoded raw and un-interpreted data of the Data-URL shall be used as sole input to the cryptographic hash function.</li> <li>If the meta element is unavailable, but the description element is available, the space-concatenated value of the pre-processed name and description shall be the input to the cryptographic hash function.</li> <li>If only the name element is available, its pre-processed value shall be the input to the cryptographic hash function.</li> </ol>"},{"location":"iep-0002/#7-metadata-embedding","title":"7. Metadata embedding","text":"<ol> <li>Seed metadata shall be embedded into the processed digital asset if:<ol> <li>seed metadata values have been provided explicitly to an ISCC processor;</li> <li>the ISCC processor supports metadata embedding for the given media type.</li> </ol> </li> <li>If the media type supports ISO 16684 XMP metadata-embedding, an ISCC processor shall use the namespace http://purl.org/iscc/schema and embed seed metadata values under the names:<ol> <li>Xmp.iscc.name</li> <li>Xmp.iscc.description</li> <li>Xmp.iscc.meta</li> </ol> </li> <li>If the media type does not support ISO 16684 XMP metadata-embedding the ISCC processor may choose other suitable format-specific fields for embedding seed metadata.</li> <li>If seed metadata is to be embedded, it shall be embedded before processing other ISCC-UNITs.</li> <li>An ISCC processor should document for which media types it supports metadata-embedding and how it maps seed metadata to format specific elements.</li> </ol>"},{"location":"iep-0002/#8-metadata-extraction","title":"8. Metadata extraction","text":"<ol> <li>An ISCC processor shall try to extract seed metadata from the digital asset if:<ol> <li>seed metadata has not been provided explicitly to the ISCC processor;</li> <li>the ISCC processor supports metadata extraction for the given media type.</li> </ol> </li> <li>Seed metadata shall be extracted with the following precedence:<ol> <li>Extract seed metadata from XMP metadata under the namespace http://purl.org/iscc/schema.</li> <li>Extract seed metadata from suitable, format-specific embedded metadata.</li> <li>Use the filename of the asset as a value for the name element, discarding the file extension and replacing the characters \u201c-\u201d and \u201c_\u201d with spaces.</li> <li>An ISCC processor shall document for which media types it supports metadata-extraction and how it maps seed metadata to format specific elements.</li> </ol> </li> </ol> <p>Bibliography</p> <ol> <li> <p>IETF, draft-multiformats-multihash-05 \u2014 The Multihash Data Format Available at https://datatracker.ietf.org/doc/html/draft-multiformats-multihash-05 \u21a9</p> </li> <li> <p>O\u2019Connor, J., Aumasson, J.P., Neves, S., Wilcox-O\u2019Hearn, Z., BLAKE3: one function, fast  everywhere. Version 20211102173700, accessed July 2022. Available at https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf \u21a9</p> </li> </ol>"},{"location":"iep-0003/","title":"ISCC-UNIT Content-Code Text","text":"IEP: 0003 Title: ISCC-UNIT Condent-Code Text Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/8 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0004/","title":"ISCC-UNIT Content-Code Image","text":"IEP: 0004 Title: ISCC-UNIT Condent-Code Image Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/9 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0005/","title":"ISCC-UNIT Content-Code Audio","text":"IEP: 0005 Title: ISCC-UNIT Condent-Code Audio Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/10 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0006/","title":"ISCC-UNIT Content-Code Video","text":"IEP: 0006 Title: ISCC-UNIT Condent-Code Video Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/11 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0007/","title":"ISCC-UNIT Content-Code Mixed","text":"IEP: 0007 Title: ISCC-UNIT Condent-Code Mixed Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/12 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0008/","title":"ISCC-UNIT Data-Code","text":"IEP: 0008 Title: ISCC-UNIT Data-Code Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/13 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0009/","title":"ISCC-UNIT Instance-Code","text":"IEP: 0009 Title: ISCC-UNIT Instance-Code Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/14 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0010/","title":"ISCC-CODE","text":"IEP: 0010 Title: ISCC-CODE Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/15 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0011/","title":"ISCC-ID","text":"IEP: 0011 Title: ISCC-ID Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/16 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2022-09-28"},{"location":"iep-0012/","title":"ISCC Metadata","text":"IEP: 0012 Title: ISCC Metadata Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/17 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2023-12-28 <p>Note</p> <p>This document is a DRAFT contributed as input to  ISO TC 46/SC 9/WG 18. The final version is  developed at the International Organization for Standardization as ISO/DIS 24138</p>"},{"location":"iep-0013/","title":"ISCC Decentralized Content Registry","text":"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: 2022-09-29"},{"location":"iep-0013/#1-status-of-this-document","title":"1. Status of This Document","text":"<p>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.</p>"},{"location":"iep-0013/#2-introduction","title":"2. Introduction","text":"<p>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.</p> <p>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.</p>"},{"location":"iep-0013/#3-protocol-overview","title":"3. Protocol Overview","text":"<p>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. </p> <ol> <li>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. </li> <li>The minting protocol defines how a legers history has to be parsed to mint a valid ISCC-ID</li> <li>The resolution protocol defines how an ISCC resolver answers queries about ISCC-CODEs and ISCC-ID.</li> </ol>"},{"location":"iep-0013/#4-declaration-protocol","title":"4. Declaration Protocol","text":"<p>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. </p> <p>Note</p> <p>An ISCC-ID comes into existence only after an ISCC declaration has been confirmed on a ledger that participates in the protocol. </p> <p>The following minimal information (Declaration-Set) MUST be provided and made publicly available for a valid ISCC declaration:</p> <ol> <li>An ISCC-CODE (a valid sequence of ISCC-UNITs)</li> <li>A blockchain account (actors identifier) of the declaring party </li> <li>A valid signature of the declaring party (transaction signature)</li> </ol> <p>We define the party that signs the ISCC declaration as the DECLARER. </p> <p>Note</p> <p>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.</p> <p>An ISCC declaration MAY additionally include:</p> <ol> <li>A link to external metadata as defined by IEP-0012 - ISCC Metadata</li> <li>A processing instruction for the minting protocol </li> </ol> <p>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.</p> <p>A ledger that wants to accept ISCC declarations and trigger the minting of valid ISCC-IDs MUST fulfill the following minimum requirements:</p> <ol> <li>The ledger must provide an immutable, complete, time-ordered, append-only sequence of transactions.</li> <li>The legers transaction format must allow for embedding and signing the data required for an ISCC declarations.</li> <li>The Declaration-Set MUST be publicly readable (permisionless).</li> <li>ISCC declarations on the ledger MAY be write-permissioned.</li> </ol> <p>A participating ledger or framework MUST provide documentaation of its implementation of the declaration protocol.</p> <ol> <li>The documentation MUST specify how ISCC declarations can be parsed to decode the Declaration-Set</li> <li>The documentation MUST provide sufficient information to the public such that third parties can independently verify transactions signatures and implement the Minting Protocol</li> <li>The documentation MUST define how a public observer can distinguish between a transaction that declares an ISCC-CODE and other unrelated transactions.</li> </ol>"},{"location":"iep-0013/#5-minting-protocol","title":"5. Minting Protocol","text":"<p>TBD</p>"},{"location":"iep-0013/#6-resolution-protocol","title":"6. Resolution Protocol","text":"<p>TBD</p>"},{"location":"iep-0013/#7-reference-implementation","title":"7. Reference Implementation","text":"<ul> <li>ISCC-ID construction: https://github.com/iscc/iscc-core/blob/main/iscc_core/iscc_id.py</li> <li>EVM registry: https://github.com/iscc/iscc-evm</li> <li>EVM observer: https://github.com/iscc/iscc-observer-evm</li> <li>ISCC-ID resolver: https://github.com/iscc/iscc-registry</li> </ul>"},{"location":"iep-0014/","title":"EVM Based ISCC Registries","text":"IEP: 0014 Title: EVM Based ISCC Registries Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/19 Status: TBD Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2022-09-28"},{"location":"iep-0015/","title":"ISCC DID Method","text":"IEP: 0015 Title: ISCC DID Method Author: Titusz Pan tp@iscc.foundation Comments: https://github.com/iscc/iscc-ieps/issues/20 Status: DRAFT Type: Core License: CC-BY-4.0 Created: 2022-09-28 Updated: 2022-10-09 <p>Abstract</p> <p>A DID method that identifies decentralized declarations of digital content using ISCC-IDs.</p> <p>Status of This Document</p> <p>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.</p>"},{"location":"iep-0015/#1-introduction","title":"1. Introduction","text":""},{"location":"iep-0015/#11-preface","title":"1.1 Preface","text":"<p>The ISCC DID method specification conforms to the requirements specified in the Decentralized Identifiers v1.0 Specification DID-CORE.</p>"},{"location":"iep-0015/#12-motivation","title":"1.2 Motivation","text":"<p>The need for a universal identifier for digital content has emerged as an increasing amount of dynamic, short-lived and granular digital content is produced, consumed and processed. Commercial interests of many stakeholders depend on proper identification of digital content.</p> <p>Professionally produced digital content but also semi-professional and user-generated content are the currency of the information age. A variety of specific content identifier standards already  exist, but a universal content-dependent identifier for digital media has not yet been developed.</p> <p>In particular, the structure and management of identifiers for digital content have a substantial impact on the level of possible adoption, automation, and the potential for machine-to-machine  communication and innovation within and across different industry sectors.</p> <p>Digital content is dynamic, always in motion, and acted upon globally by a variety of entities with  different interests and requirements. Digital content continuously re-encodes, resizes, and  re-compresses, changing its underlying data as it travels through a complex network of actors and  systems. These circumstances require a special design for a universal identifier that is capable of matching transcoded or otherwise transformed content.</p>"},{"location":"iep-0015/#13-the-iscc","title":"1.3 The ISCC","text":"<p>The ISCC (International Standard Content Code) is a universal and open identification system for text, audio, image, and video content. ISCC-CODEs can be created from media assets by anybody using open source software. Similar content can then be matched by comparing ISCC-CODEs only.</p> <p>Example ISCC-CODE</p> <pre><code>ISCC:KECYCPU3OKIUDZ7TYBRK5HZ4JGPTILLAT2IW7TY7EYIJI4QSK5I353I\nDecoded: ISCC-IMAGE-V0-MCDI-813e9b729141e7f3c062ae9f3c499f342d609e916fcf1f26109472125751beed\n</code></pre> <p>Users can also register ISCC-CODEs on any supported public blockchain to obtain a short and globaly unique ISCC-ID. The ISCC-ID is under the control of the registrant and resolves to an ISCC-CODE,  on-chain metadata and optional off-chain metadata. ISCC-IDs are globaly unique even if the same ISCC-CODE is registered multiple times by different entities. An ISCC-ID is minted  deterministically by observing participating legers and can be reproduced by anybody who observes  the public and immutable registration events.</p> <p>Example ISCC-ID</p> <pre><code>ISCC:MIAGWPTV4J2Z57CI\nDecoded: ID-ETHEREUM-V0-64-6b3e75e2759efc48\n</code></pre>"},{"location":"iep-0015/#14-iscc-id-as-did","title":"1.4 ISCC-ID as DID","text":"<p>The ISCC DID method creates a mechanism to reference digital content with a globaly unique persistent identifier that does not require a centralized registration authority. Instead, the ISCC system defines an open and voluntary cross-chain registration protocol using cryptography and distributed ledger technology.</p> <p>Integrating ISCC with the DID system improves ISCC interoperability. DID documents provide standardized ways to discover services related to the referenced content and its registrant.</p> <p>Verifiable credentials discovered through the DID document  <code>service</code> property can improve trust in otherwise permissionless content registrations. Additionaly the use of decentralized web nodes allow for interoperable discovery and data sovereignity of hosted verifiable credentials.</p> <p>At the same time ISCC would bring open content identification to the Decentalized Identifiers  ecosystem.</p>"},{"location":"iep-0015/#2-method-syntax","title":"2. Method Syntax","text":""},{"location":"iep-0015/#21-method-name","title":"2.1 Method Name","text":"<ol> <li>The name that shall identify this DID method is: <code>iscc</code>.</li> <li>A DID that uses this method MUST begin with the following prefix: <code>did:iscc:</code>.</li> <li>According to the DID specification, this string MUST be in lowercase.</li> </ol>"},{"location":"iep-0015/#22-method-specific-identifier","title":"2.2 Method Specific Identifier","text":"<p>The ISCC DID scheme conforms to the DID Syntax and is defined by the follwing ABNF:</p> <p>ISCC DID scheme ABNF</p> <pre><code>iscc-did = \"did:iscc:\" iscc\niscc     = 10*88(numbers / letters)\nnumbers  = %x32-37  ; 2-7\nletters  = %x61-7A  ; a-z\n</code></pre> <ol> <li>The data structure of the ISCC is <code>&lt;MainType&gt;&lt;SubType&gt;&lt;Version&gt;&lt;Length&gt;&lt;ISCC-BODY&gt;</code></li> <li>The method specific identifier is a lower-cased base32 representation of the ISCC structure.</li> <li>The regular expression for this DID method is <code>^did:iscc:[2-7a-z]{10,88}$</code></li> </ol>"},{"location":"iep-0015/#23-iscc-did-example","title":"2.3 ISCC DID Example","text":"<p>DID representation of an ISCC-ID</p> <pre><code>did:iscc:miagwptv4j2z57ci\n</code></pre>"},{"location":"iep-0015/#3-method-operations","title":"3. Method Operations","text":""},{"location":"iep-0015/#31-creation","title":"3.1 Creation","text":"<ol> <li>An ISCC DID MUST be created by a signed and confirmed ledger transaction that declares an    ISCC-CODE in  accordance with the cross-chain declaration protocol.</li> <li>The initial controller of a newly created ISCC DID MUST be the     did:pkh representation of    the blockchain account that signed the declaration transaction.</li> <li>The controller MAY set a custom DID Document at declaration time by embedding or referencing it    from ISCC Metadata</li> </ol>"},{"location":"iep-0015/#32-read","title":"3.2 Read","text":"<ol> <li>A basic DID document is implicitly created with every ISCC declaration and MUST be     deterministicaly derived from on-chain metadata.</li> <li>Extended DID document properties MAY be imported from externaly referenced ISCC Metadata</li> </ol>"},{"location":"iep-0015/#33-update-deactivate","title":"3.3 Update &amp; Deactivate","text":"<p>The ISCC DID MAY be updated or deactivated in accordence with the chain specific implementation of the ISCC declaration protocol.</p>"},{"location":"iep-0015/#4-verifiable-data-registry","title":"4. Verifiable Data Registry","text":"<p>The verifiable data registry or \"target system\" for ISCC DIDs is a federation of existing public ledgers that support the  ISCC declaration protocol. The protocol can be implemented on most public ledgers (even without smart  contracts) that provide an orderd, immutable, append-only history of signed transactions. </p> <p> </p> Figure 1 - ISCC Verifiable Data Registry"},{"location":"iep-0015/#5-did-document","title":"5. DID Document","text":"<p>DID documents are sourced from on-chain metadata and optionally from immutably or mutably referenced off-chain metadata. </p> <p>All information required to construct a minimal valid DID document from an ISCC declaration is available on-chain and can be dynamically transformed and presented as DID document by a DID  driver implementation.</p> <p>Minimal ISCC DID Document example</p> <pre><code>{\n  \"@context\": \"https://www.w3id.org/ns/did/v1\"\n  \"id\": \"did:iscc:miagwptv4j2z57ci\",\n  \"controller\": \"did:pkh:eip155:1:0x901ee44e3bddf4bc1c08a2ed229498512f8bcfdc\",\n  \"alsoKnownAs\": \"iscc:kecycpu3okiudz7tybrk5hz4jgptillat2iw7ty7eyiji4qsk5i353i\",\n  \"service\": [{\n    \"id\":\"did:iscc:miagwptv4j2z57ci#iscc-metadata\",\n    \"type\": \"IsccMetadata\", \n    \"serviceEndpoint\": \"ipfs://bafybeiccys7kilr3rynlhoelrdn6ragpbfoti73h4e3oszbgd5inthicja/iscc-metadata/43.json\"\n  }]\n}\n</code></pre> <ol> <li>The DID subject (<code>id</code>-property) MUST be the ISCC-ID in DID representation.</li> <li>The DID controller (<code>controller</code>-property) MUST be constructed deterministically by converting   the blockchain account that signed the declaration transaction to a <code>did:pkh</code>.</li> <li>The <code>alsoKnownAs</code>-property MUST be set to the ISCC-CODE registered by the transaction.</li> <li>If the original ISCC declaration includes a link to off-chain metadata the DID document MUST   include the reference via an entry into the <code>service</code>-property with type \"IsccMetadata\". The    referenced <code>serviceEndpoint</code> SHOULD return a document of type http://purl.org/iscc/context.</li> </ol> <p>Info</p> <p>Properties like <code>verificationMethod</code>, <code>authentication</code>, <code>assertionMethod</code> etc. are left out  intentionally, as their autoritative values are managed by the DID document associated with the <code>controller</code> that can be resolved separately.</p> <p>To be defined</p> <p>Additional/Optional DID document data MAY be added off-chain in mutable or immutable modes and retrived and incjected by the DID driver in realtime to compose an extended DID document that includes other properties like <code>service</code>.</p>"},{"location":"iep-0015/#6-resolving-dids","title":"6. Resolving DIDs","text":"<ol> <li>An ISCC DID can be resolved by querying an instantiation of an ISCC content registry.</li> <li>The authenticity of the response can be verified through the referenced on-chain transaction.</li> </ol> Figure 2 - ISCC DID Architecture"},{"location":"iep-0015/#7-security-considerations","title":"7. Security Considerations","text":"<p>Implementers should be aware that ISCC-CODEs are not cryptographic hashes but descriptors or  similarity preserving (soft) hashes. As such they leak information about the structure of the identified content. This is by design and necessary to support similarity matching with ISCC-CODEs.</p> <p>An ISCC DID document does not need to contain a proof property. All operations are authenticated with the signature of the transaction payload sent to the network of the originating ledger.  This signature is generated using a key specified in the corresponding DID Document.</p>"},{"location":"iep-0015/#8-privacy-considerations","title":"8. Privacy Considerations","text":"<p>ISCC declarations do not publish any personal data on-chain. Declarers may optionally reference off-chain metadata related to their content registration. Such metadata may contain personal data such as creator and rightsholder information. The assumption is that creators have an interest in proper attribution. Applications that implement ISCC declarations are advised to inform users about any privacy related matters specific to their application.</p>"},{"location":"iep-0015/#9-reference-implementation","title":"9. Reference Implementation","text":"<p>An end-to-end reference implementation of the decentralized content registry is manifested by the following modules:</p> <ul> <li>Codec and Algorithms: https://github.com/iscc/iscc-core</li> <li>ISCC Metadata: https://github.com/iscc/iscc-schema</li> <li>EVM Smart Contracts: https://github.com/iscc/iscc-evm</li> <li>EVM Chain Observer: https://github.com/iscc/iscc-observer-evm</li> <li>ISCC Content Registry: https://github.com/iscc/iscc-registry / https://iscc.id</li> <li>ISCC DID driver: https://github.com/iscc/iscc-did-driver / https://did.iscc.id</li> </ul>"}]}
\ No newline at end of file
diff --git a/sitemap.xml.gz b/sitemap.xml.gz
index 1060dfc6e0790919b50bdfb028a86604b7367df1..1b6c93ad84e3ff11281ff5b07e6aa89803911a49 100755
GIT binary patch
delta 15
WcmbQkG>3^zzMF%iIA|lA7$X25bpwz9

delta 15
WcmbQkG>3^zzMF&NTEIp&F-8C(y#w(8