The Meta-Code is a similarity hash generated from referent seed metadata as defined in IEP-0012
-The Meta-Code shall support the following use cases:
The Meta-Code shall have the data format as illustrated in Figure 2:
@@ -497,7 +560,7 @@
ISCC:AADUL6P7RMVNT4UJJ4SMTDXBL5JFZ5XPCDKO42XYPJEVQ4L7PTYDORQ
-Seed metadata is the metadata that is used as the input to calculate the Meta-Code and has three possible elements:
The text input for the name element shall be pre-processed before similarity hashing as follows:
Text input for the description element shall be pre-processed before similarity hashing as follows:
Meta-Code processing shall generate the following output elements for inclusion into the produced ISCC metadata:
An ISCC processor may produce other custom output elements, which are helpful to identify the digital asset.
-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.
The Meta-Hash shall be constructed from the seed metadata by selecting input elements according to the algorithm illustrated in Figure 4.
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.
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.
Because the IEPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
"},{"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":"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.
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.
Because the IEPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
"},{"location":"iep-0000/#2-iep-audience","title":"2. IEP audience","text":"The typical primary audience for IEPs are the developers of ISCC implementations.
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.
"},{"location":"iep-0000/#3-iep-workflow","title":"3. IEP workflow","text":"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.
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.
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).
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.
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.
"},{"location":"iep-0000/#31-transferring-iep-ownership","title":"3.1 Transferring IEP ownership","text":"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.
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.
"},{"location":"iep-0000/#32-iep-editors","title":"3.2 IEP editors","text":"The current IEP editors are:
The IEP editors subscribe to the IEP issue tracker. Correspondence outside the issue tracker should be sent (or CC'd) to the IEP editors.
For each new IEP that comes in an editor does the following:
Read the IEP to check if it is ready: sound and complete. The ideas must make technical sense.
The title should accurately describe the content.
Motivation and backward compatibility (when applicable) must be addressed.
Licensing terms must be acceptable for IEPs.
If the IEP isn't ready, the editor will send it back to the author for revision, with specific instructions.
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.
The IEP editor will:
The IEP editors are intended to fulfill administrative and editorial responsibilities. The IEP editors monitor IEP changes, and update IEP headers as appropriate.
"},{"location":"iep-0000/#4-iep-format-and-structure","title":"4. IEP format and structure","text":"IEPs should be written in Markdown format.
Each IEP should have the following parts:
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.
IEP: <IEP number, or \"?\" before being assigned>\n Title: <IEP title; maximum 44 characters>\n Author: <list of authors' names and email addresses>\n Comments: <link to issue page for comments>\n Status: <Draft | Deferred | Withdrawn | Proposed | Rejected | Stable | Obsolete>\n Type: <Core | Informational | Process>\n License: <abbreviation for approved license(s)>\n Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>\n Updated: <date updated on, in ISO 8601 (yyyy-mm-dd) format>\n* Replaces: <IEP number>\n* Superseded-By: <IEP number>\nThe 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
Random J. User <address@dom.ain>\nIf there are multiple authors, each should be on a separate line.
The Type header specifies the type of IEP: Core, Informational, or Process.
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.
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.
"},{"location":"iep-0000/#5-iep-types","title":"5. IEP Types","text":"There are three kinds of IEPs:
The typical paths of the status of IEPs are as follows:
flowchart LR\n B[Draft]\n B --> C[Poposed]\n B <--> D[Deferred]\n B <--> E[Withdrawn]\n C --> F[Stable]\n C --> G[Rejected]\n F --> H[Obsolete]\nChampions 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.
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.
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.
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.
Software authors are encouraged to publish summaries of what IEPs their software supports to aid in verification of status changes.
Should an IEP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Stable status.
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.
"},{"location":"iep-0000/#7-iep-licensing","title":"7. IEP licensing","text":"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.
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.
"},{"location":"iep-0000/#71-acceptable-licenses","title":"7.1 Acceptable licenses","text":"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.
"},{"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-28Note
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
"},{"location":"iep-0001/#1-abstract","title":"1. Abstract","text":"This document describes the coding scheme for the International Standard Content Code (ISCC).
"},{"location":"iep-0001/#2-motivation","title":"2. Motivation","text":"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:
The ISCC-HEADER is a variable sized bitstream composed of an ordered sequence of the 4 header-fields MainType, SubType, Version, Length.
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:
Table 1 \u2013 Variable length ISCC-HEADER field encoding
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-4679Header-field examples
0 = 0000\n1 = 0001\n\u2026\n7 = 0111\n8 = 1000 0000\n9 = 1000 0001\nThe interpretation of the integer value of a header-field shall be context dependent:
The MainType header-field shall signify the type of the ISCC.
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.
Note
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.
Table 2 \u2013 Reserved ISCC MainTypes
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":"The MainTypes META, DATA, and INSTANCE shall have a single default SubType NONE encoded with the bits 0000.
The MainTypes SEMANTIC, CONTENT, and ISCC shall have SubTypes that signify the perceptual mode.
Table 3 \u2013 Reserved SubTypes for MainTypes ISCC, SEMANTIC, and CONTENT
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 similarityTable 4 \u2013 Additional Reserved SubTypes for the MainType ISCC
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":"All ISCC-HEADERs shall have a version header-field of 0000 for the first edition of the standard.
Table 5 \u2013 Reserved ISCC Versions
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":"The encoding of the Length header-field shall be specific to the MainType.
"},{"location":"iep-0001/#441-length-of-iscc-units","title":"4.4.1 Length of ISCC-UNITs","text":"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.
Table 6 \u2013 Reserved length field values (multiples of 32 bit)
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":"For ISCC-CODEs the length value shall designate the composition of ISCC-UNITs.
The Data-Code and Instance-Code shall be mandatory 64-bit components of an ISCC-CODE.
The first data-bit shall designate the presence of a 64-bit Meta-Code.
The second data-bit shall designate the presence of a 64-bit Semantic-Code.
The third data-bit shall designate the presence of a 64-bit Content-Code.
The length of an ISCC-CODE shall be calculated as the number of active data-bits times 64 plus 128 bits of mandatory data.
Table 7 \u2013 Reserved length field values (for MainType ISCC)
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":"The printable canonical form of an ISCC shall be its RFC 4648 Base32 encoded representation without padding and prefixed with \u201cISCC:\u201d.
Canonical ISCC-CODE example
ISCC:KEC43HJLPUSHVAZT66YLPUWNVACWYPIV533TRQMWF2IUQYSP5LA4CTY
"},{"location":"iep-0001/#62-uri-encoding","title":"6.2 URI encoding","text":"<scheme>:<path>.URI encoded ISCC-CODE example
iscc:kec43hjlpushvazt66ylpuwnvacwypiv533trqmwf2iuqysp5la4cty
"},{"location":"iep-0001/#63-multiformats-encoding","title":"6.3 Multiformats encoding","text":"0xcc01.<multibase><multicodec><iscc-header><iscc-body>.ISCC shall support the following multibase encodings:
Table 8 \u2013 Supported multibase encodings
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 paddingTable 9 \u2013 Examples of ISCCs in multiformats encoding
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":"Example of human-readable ISCC-CODE
ISCC-IMAGE-V0-MCDI-cd9d2b7d247a8333f7b0b7d2cda8056c3d15eef738c1962e9148624feac1c14f
"},{"location":"iep-0001/#7-reference-implementation","title":"7. Reference implementation","text":"The reference implementation of this coding scheme is published in the iscc-core python package in the codec.py module.
"},{"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-28Note
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
"},{"location":"iep-0002/#1-meta-code","title":"1. Meta-Code","text":""},{"location":"iep-0002/#11-general","title":"1.1 General","text":"The Meta-Code is a similarity hash generated from referent seed metadata as defined in IEP-0012
"},{"location":"iep-0002/#12-purpose","title":"1.2 Purpose","text":"The Meta-Code shall support the following use cases:
The Meta-Code shall have the data format as illustrated in Figure 2:
Figure 2 - Data format of the Meta-Code
EXAMPLE: 64-bit Meta-Code in its canonical form:
ISCC:AAAUL6P7RMVNT4UJ
EXAMPLE: 256-bit Meta-Code in its canonical form:
ISCC:AADUL6P7RMVNT4UJJ4SMTDXBL5JFZ5XPCDKO42XYPJEVQ4L7PTYDORQ
"},{"location":"iep-0002/#14-inputs","title":"1.4 Inputs","text":"Seed metadata is the metadata that is used as the input to calculate the Meta-Code and has three possible elements:
NOTE 1
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.
NOTE 2
The identifier standards and their schemas defined by ISO/TC 46/SC 9 provide helpful guidance in selecting seed metadata.
"},{"location":"iep-0002/#141-name-element","title":"1.4.1 name element","text":"The text input for the name element shall be pre-processed before similarity hashing as follows:
Text input for the description element shall be pre-processed before similarity hashing as follows:
data:application/json;base64,<data>);data:application/ld+json;base64,<data>);data:application/xml;base64,<data>);data:application/xml;base64,<data>);data:application/vnd.iptc.g2.newsitem+xml;base64,<data>);data:application/octet-stream;base64,<data>);data:image/png;base64,<data>);data:audio/mp4;base64,<data>).Meta-Code processing shall generate the following output elements for inclusion into the produced ISCC metadata:
NOTE 1
The reference implementation uses a multihash 1 encoded BLAKE3 2 value for the metahash element.
NOTE 2
An ISCC processor may produce other custom output elements, which are helpful to identify the digital asset.
"},{"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":"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.
Figure 3 - Meta-Code processing logic
The Meta-Hash shall be constructed from the seed metadata by selecting input elements according to the algorithm illustrated in Figure 4.
Figure 4 - Meta-Hash processing logic
Bibliography
IETF, draft-multiformats-multihash-05 \u2014 The Multihash Data Format Available at https://datatracker.ietf.org/doc/html/draft-multiformats-multihash-05 \u21a9
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
Note
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
"},{"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-28Note
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
"},{"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-28Note
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
"},{"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-28Note
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
"},{"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-28Note
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
"},{"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-28Note
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
"},{"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-28Note
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
"},{"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-28Note
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
"},{"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-28Note
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
"},{"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":"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.
"},{"location":"iep-0013/#2-introduction","title":"2. Introduction","text":"The purpose of a decentralized content registry is to connect Actors to Digital Content in a permissionless decentralized environment and provide a global and verifiable data space for content identification and matching.
Actors authenticate themselves with their blockchain accounts which they use to sign ISCC-CODE declarations (ledger transactions). Digital Content is identified by ISCC-CODEs. The ISCC-ID is derived from an ISCC-CODE, a blockchain account and the history of previous declarations. ISCC-IDs are globally unique, persistent, authenticated, and resolve to at least exactly one ISCC-CODE and a blockchain account. The ISCC-IDs are not required to be generated or stored on the participating ledgers. ISCC-IDs are the result of processing the history of transactions according to the Minting Protocol.
"},{"location":"iep-0013/#3-protocol-overview","title":"3. Protocol Overview","text":"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.
To participate in the ISCC declaration protocol, a ledger MUST establish exactly one globally unique Ledger-ID (Variable Length Integer) that will be used as a prefix for ISCC-IDs that are minted from its ISCC declarations.
Note
An ISCC-ID comes into existence only after an ISCC declaration has been confirmed on a ledger that participates in the protocol.
The following minimal information (Declaration-Set) MUST be provided and made publicly available for a valid ISCC declaration:
We define the party that signs the ISCC declaration as the DECLARER.
Note
The DECLARER is merely the controller of the ISCC-ID minted from the declaration. The declarer is not required to be the creator or a rights-holder of the declared digital content.
An ISCC declaration MAY additionally include:
The on-chain link to ISCC metadata SHOULD point to a public and integrity preserving resource (e.g. IPFS CID or a hashlink URI). Permissioned, confidential or mutable data SHOULD be referenced from ISCC metadata via URI.
A ledger that wants to accept ISCC declarations and trigger the minting of valid ISCC-IDs MUST fulfill the following minimum requirements:
A participating ledger or framework MUST provide documentaation of its implementation of the declaration protocol.
TBD
"},{"location":"iep-0013/#6-resolution-protocol","title":"6. Resolution Protocol","text":"TBD
"},{"location":"iep-0013/#7-reference-implementation","title":"7. Reference Implementation","text":"Abstract
A DID method that identifies decentralized declarations of digital content using ISCC-IDs.
Status of This Document
This document is a draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organization.
"},{"location":"iep-0015/#1-introduction","title":"1. Introduction","text":""},{"location":"iep-0015/#11-preface","title":"1.1 Preface","text":"The ISCC DID method specification conforms to the requirements specified in the Decentralized Identifiers v1.0 Specification DID-CORE.
"},{"location":"iep-0015/#12-motivation","title":"1.2 Motivation","text":"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.
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.
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.
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.
"},{"location":"iep-0015/#13-the-iscc","title":"1.3 The ISCC","text":"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.
Example ISCC-CODE
ISCC:KECYCPU3OKIUDZ7TYBRK5HZ4JGPTILLAT2IW7TY7EYIJI4QSK5I353I\nDecoded: ISCC-IMAGE-V0-MCDI-813e9b729141e7f3c062ae9f3c499f342d609e916fcf1f26109472125751beed\nUsers 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.
Example ISCC-ID
ISCC:MIAGWPTV4J2Z57CI\nDecoded: ID-ETHEREUM-V0-64-6b3e75e2759efc48\nThe 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.
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.
Verifiable credentials discovered through the DID document service 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.
At the same time ISCC would bring open content identification to the Decentalized Identifiers ecosystem.
"},{"location":"iep-0015/#2-method-syntax","title":"2. Method Syntax","text":""},{"location":"iep-0015/#21-method-name","title":"2.1 Method Name","text":"iscc.did:iscc:.The ISCC DID scheme conforms to the DID Syntax and is defined by the follwing ABNF:
ISCC DID scheme ABNF
iscc-did = \"did:iscc:\" iscc\niscc = 10*88(numbers / letters)\nnumbers = %x32-37 ; 2-7\nletters = %x61-7A ; a-z\n<MainType><SubType><Version><Length><ISCC-BODY>^did:iscc:[2-7a-z]{10,88}$DID representation of an ISCC-ID
did:iscc:miagwptv4j2z57ci\nThe ISCC DID MAY be updated or deactivated in accordence with the chain specific implementation of the ISCC declaration protocol.
"},{"location":"iep-0015/#4-verifiable-data-registry","title":"4. Verifiable Data Registry","text":"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.
Figure 1 - ISCC Verifiable Data Registry"},{"location":"iep-0015/#5-did-document","title":"5. DID Document","text":"
DID documents are sourced from on-chain metadata and optionally from immutably or mutably referenced off-chain metadata.
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.
Minimal ISCC DID Document example
{\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}\nid-property) MUST be the ISCC-ID in DID representation.controller-property) MUST be constructed deterministically by converting the blockchain account that signed the declaration transaction to a did:pkh.alsoKnownAs-property MUST be set to the ISCC-CODE registered by the transaction.service-property with type \"IsccMetadata\". The referenced serviceEndpoint SHOULD return a document of type http://purl.org/iscc/context.Info
Properties like verificationMethod, authentication, assertionMethod etc. are left out intentionally, as their autoritative values are managed by the DID document associated with the controller that can be resolved separately.
To be defined
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 service.
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.
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.
"},{"location":"iep-0015/#8-privacy-considerations","title":"8. Privacy Considerations","text":"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.
"},{"location":"iep-0015/#9-reference-implementation","title":"9. Reference Implementation","text":"An end-to-end reference implementation of the decentralized content registry is manifested by the following modules:
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.
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.
Because the IEPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
"},{"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":"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.
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.
Because the IEPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
"},{"location":"iep-0000/#2-iep-audience","title":"2. IEP audience","text":"The typical primary audience for IEPs are the developers of ISCC implementations.
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.
"},{"location":"iep-0000/#3-iep-workflow","title":"3. IEP workflow","text":"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.
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.
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).
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.
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.
"},{"location":"iep-0000/#31-transferring-iep-ownership","title":"3.1 Transferring IEP ownership","text":"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.
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.
"},{"location":"iep-0000/#32-iep-editors","title":"3.2 IEP editors","text":"The current IEP editors are:
The IEP editors subscribe to the IEP issue tracker. Correspondence outside the issue tracker should be sent (or CC'd) to the IEP editors.
For each new IEP that comes in an editor does the following:
Read the IEP to check if it is ready: sound and complete. The ideas must make technical sense.
The title should accurately describe the content.
Motivation and backward compatibility (when applicable) must be addressed.
Licensing terms must be acceptable for IEPs.
If the IEP isn't ready, the editor will send it back to the author for revision, with specific instructions.
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.
The IEP editor will:
The IEP editors are intended to fulfill administrative and editorial responsibilities. The IEP editors monitor IEP changes, and update IEP headers as appropriate.
"},{"location":"iep-0000/#4-iep-format-and-structure","title":"4. IEP format and structure","text":"IEPs should be written in Markdown format.
Each IEP should have the following parts:
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.
IEP: <IEP number, or \"?\" before being assigned>\n Title: <IEP title; maximum 44 characters>\n Author: <list of authors' names and email addresses>\n Comments: <link to issue page for comments>\n Status: <Draft | Deferred | Withdrawn | Proposed | Rejected | Stable | Obsolete>\n Type: <Core | Informational | Process>\n License: <abbreviation for approved license(s)>\n Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>\n Updated: <date updated on, in ISO 8601 (yyyy-mm-dd) format>\n* Replaces: <IEP number>\n* Superseded-By: <IEP number>\nThe 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
Random J. User <address@dom.ain>\nIf there are multiple authors, each should be on a separate line.
The Type header specifies the type of IEP: Core, Informational, or Process.
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.
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.
"},{"location":"iep-0000/#5-iep-types","title":"5. IEP Types","text":"There are three kinds of IEPs:
The typical paths of the status of IEPs are as follows:
flowchart LR\n B[Draft]\n B --> C[Poposed]\n B <--> D[Deferred]\n B <--> E[Withdrawn]\n C --> F[Stable]\n C --> G[Rejected]\n F --> H[Obsolete]\nChampions 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.
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.
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.
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.
Software authors are encouraged to publish summaries of what IEPs their software supports to aid in verification of status changes.
Should an IEP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Stable status.
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.
"},{"location":"iep-0000/#7-iep-licensing","title":"7. IEP licensing","text":"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.
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.
"},{"location":"iep-0000/#71-acceptable-licenses","title":"7.1 Acceptable licenses","text":"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.
"},{"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-28Note
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
"},{"location":"iep-0001/#1-abstract","title":"1. Abstract","text":"This document describes the coding scheme for the International Standard Content Code (ISCC).
"},{"location":"iep-0001/#2-motivation","title":"2. Motivation","text":"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:
The ISCC-HEADER is a variable sized bitstream composed of an ordered sequence of the 4 header-fields MainType, SubType, Version, Length.
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:
Table 1 \u2013 Variable length ISCC-HEADER field encoding
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-4679Header-field examples
0 = 0000\n1 = 0001\n\u2026\n7 = 0111\n8 = 1000 0000\n9 = 1000 0001\nThe interpretation of the integer value of a header-field shall be context dependent:
The MainType header-field shall signify the type of the ISCC.
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.
Note
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.
Table 2 \u2013 Reserved ISCC MainTypes
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":"The MainTypes META, DATA, and INSTANCE shall have a single default SubType NONE encoded with the bits 0000.
The MainTypes SEMANTIC, CONTENT, and ISCC shall have SubTypes that signify the perceptual mode.
Table 3 \u2013 Reserved SubTypes for MainTypes ISCC, SEMANTIC, and CONTENT
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 similarityTable 4 \u2013 Additional Reserved SubTypes for the MainType ISCC
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":"All ISCC-HEADERs shall have a version header-field of 0000 for the first edition of the standard.
Table 5 \u2013 Reserved ISCC Versions
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":"The encoding of the Length header-field shall be specific to the MainType.
"},{"location":"iep-0001/#441-length-of-iscc-units","title":"4.4.1 Length of ISCC-UNITs","text":"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.
Table 6 \u2013 Reserved length field values (multiples of 32 bit)
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":"For ISCC-CODEs the length value shall designate the composition of ISCC-UNITs.
The Data-Code and Instance-Code shall be mandatory 64-bit components of an ISCC-CODE.
The first data-bit shall designate the presence of a 64-bit Meta-Code.
The second data-bit shall designate the presence of a 64-bit Semantic-Code.
The third data-bit shall designate the presence of a 64-bit Content-Code.
The length of an ISCC-CODE shall be calculated as the number of active data-bits times 64 plus 128 bits of mandatory data.
Table 7 \u2013 Reserved length field values (for MainType ISCC)
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":"The printable canonical form of an ISCC shall be its RFC 4648 Base32 encoded representation without padding and prefixed with \u201cISCC:\u201d.
Canonical ISCC-CODE example
ISCC:KEC43HJLPUSHVAZT66YLPUWNVACWYPIV533TRQMWF2IUQYSP5LA4CTY
"},{"location":"iep-0001/#62-uri-encoding","title":"6.2 URI encoding","text":"<scheme>:<path>.URI encoded ISCC-CODE example
iscc:kec43hjlpushvazt66ylpuwnvacwypiv533trqmwf2iuqysp5la4cty
"},{"location":"iep-0001/#63-multiformats-encoding","title":"6.3 Multiformats encoding","text":"0xcc01.<multibase><multicodec><iscc-header><iscc-body>.ISCC shall support the following multibase encodings:
Table 8 \u2013 Supported multibase encodings
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 paddingTable 9 \u2013 Examples of ISCCs in multiformats encoding
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":"Example of human-readable ISCC-CODE
ISCC-IMAGE-V0-MCDI-cd9d2b7d247a8333f7b0b7d2cda8056c3d15eef738c1962e9148624feac1c14f
"},{"location":"iep-0001/#7-reference-implementation","title":"7. Reference implementation","text":"The reference implementation of this coding scheme is published in the iscc-core python package in the codec.py module.
"},{"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-28Note
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
"},{"location":"iep-0002/#1-general","title":"1. General","text":"The Meta-Code is a similarity hash generated from referent seed metadata as defined in IEP-0012
"},{"location":"iep-0002/#2-purpose","title":"2. Purpose","text":"The Meta-Code shall support the following use cases:
The Meta-Code shall have the data format as illustrated in Figure 2:
Figure 2 - Data format of the Meta-Code
EXAMPLE: 64-bit Meta-Code in its canonical form:
ISCC:AAAUL6P7RMVNT4UJ
EXAMPLE: 256-bit Meta-Code in its canonical form:
ISCC:AADUL6P7RMVNT4UJJ4SMTDXBL5JFZ5XPCDKO42XYPJEVQ4L7PTYDORQ
"},{"location":"iep-0002/#4-inputs","title":"4. Inputs","text":"Seed metadata is the metadata that is used as the input to calculate the Meta-Code and has three possible elements:
NOTE 1
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.
NOTE 2
The identifier standards and their schemas defined by ISO/TC 46/SC 9 provide helpful guidance in selecting seed metadata.
"},{"location":"iep-0002/#41-name-element","title":"4.1 name element","text":"The text input for the name element shall be pre-processed before similarity hashing as follows:
Text input for the description element shall be pre-processed before similarity hashing as follows:
data:application/json;base64,<data>);data:application/ld+json;base64,<data>);data:application/xml;base64,<data>);data:application/xml;base64,<data>);data:application/vnd.iptc.g2.newsitem+xml;base64,<data>);data:application/octet-stream;base64,<data>);data:image/png;base64,<data>);data:audio/mp4;base64,<data>).Meta-Code processing shall generate the following output elements for inclusion into the produced ISCC metadata:
NOTE 1
The reference implementation uses a multihash 1 encoded BLAKE3 2 value for the metahash element.
NOTE 2
An ISCC processor may produce other custom output elements, which are helpful to identify the digital asset.
"},{"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":"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.
Figure 3 - Meta-Code processing logic
The Meta-Hash shall be constructed from the seed metadata by selecting input elements according to the algorithm illustrated in Figure 4.
Figure 4 - Meta-Hash processing logic
Bibliography
IETF, draft-multiformats-multihash-05 \u2014 The Multihash Data Format Available at https://datatracker.ietf.org/doc/html/draft-multiformats-multihash-05 \u21a9
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
Note
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
"},{"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-28Note
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
"},{"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-28Note
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
"},{"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-28Note
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
"},{"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-28Note
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
"},{"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-28Note
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
"},{"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-28Note
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
"},{"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-28Note
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
"},{"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-28Note
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
"},{"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":"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.
"},{"location":"iep-0013/#2-introduction","title":"2. Introduction","text":"The purpose of a decentralized content registry is to connect Actors to Digital Content in a permissionless decentralized environment and provide a global and verifiable data space for content identification and matching.
Actors authenticate themselves with their blockchain accounts which they use to sign ISCC-CODE declarations (ledger transactions). Digital Content is identified by ISCC-CODEs. The ISCC-ID is derived from an ISCC-CODE, a blockchain account and the history of previous declarations. ISCC-IDs are globally unique, persistent, authenticated, and resolve to at least exactly one ISCC-CODE and a blockchain account. The ISCC-IDs are not required to be generated or stored on the participating ledgers. ISCC-IDs are the result of processing the history of transactions according to the Minting Protocol.
"},{"location":"iep-0013/#3-protocol-overview","title":"3. Protocol Overview","text":"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.
To participate in the ISCC declaration protocol, a ledger MUST establish exactly one globally unique Ledger-ID (Variable Length Integer) that will be used as a prefix for ISCC-IDs that are minted from its ISCC declarations.
Note
An ISCC-ID comes into existence only after an ISCC declaration has been confirmed on a ledger that participates in the protocol.
The following minimal information (Declaration-Set) MUST be provided and made publicly available for a valid ISCC declaration:
We define the party that signs the ISCC declaration as the DECLARER.
Note
The DECLARER is merely the controller of the ISCC-ID minted from the declaration. The declarer is not required to be the creator or a rights-holder of the declared digital content.
An ISCC declaration MAY additionally include:
The on-chain link to ISCC metadata SHOULD point to a public and integrity preserving resource (e.g. IPFS CID or a hashlink URI). Permissioned, confidential or mutable data SHOULD be referenced from ISCC metadata via URI.
A ledger that wants to accept ISCC declarations and trigger the minting of valid ISCC-IDs MUST fulfill the following minimum requirements:
A participating ledger or framework MUST provide documentaation of its implementation of the declaration protocol.
TBD
"},{"location":"iep-0013/#6-resolution-protocol","title":"6. Resolution Protocol","text":"TBD
"},{"location":"iep-0013/#7-reference-implementation","title":"7. Reference Implementation","text":"Abstract
A DID method that identifies decentralized declarations of digital content using ISCC-IDs.
Status of This Document
This document is a draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organization.
"},{"location":"iep-0015/#1-introduction","title":"1. Introduction","text":""},{"location":"iep-0015/#11-preface","title":"1.1 Preface","text":"The ISCC DID method specification conforms to the requirements specified in the Decentralized Identifiers v1.0 Specification DID-CORE.
"},{"location":"iep-0015/#12-motivation","title":"1.2 Motivation","text":"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.
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.
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.
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.
"},{"location":"iep-0015/#13-the-iscc","title":"1.3 The ISCC","text":"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.
Example ISCC-CODE
ISCC:KECYCPU3OKIUDZ7TYBRK5HZ4JGPTILLAT2IW7TY7EYIJI4QSK5I353I\nDecoded: ISCC-IMAGE-V0-MCDI-813e9b729141e7f3c062ae9f3c499f342d609e916fcf1f26109472125751beed\nUsers 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.
Example ISCC-ID
ISCC:MIAGWPTV4J2Z57CI\nDecoded: ID-ETHEREUM-V0-64-6b3e75e2759efc48\nThe 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.
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.
Verifiable credentials discovered through the DID document service 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.
At the same time ISCC would bring open content identification to the Decentalized Identifiers ecosystem.
"},{"location":"iep-0015/#2-method-syntax","title":"2. Method Syntax","text":""},{"location":"iep-0015/#21-method-name","title":"2.1 Method Name","text":"iscc.did:iscc:.The ISCC DID scheme conforms to the DID Syntax and is defined by the follwing ABNF:
ISCC DID scheme ABNF
iscc-did = \"did:iscc:\" iscc\niscc = 10*88(numbers / letters)\nnumbers = %x32-37 ; 2-7\nletters = %x61-7A ; a-z\n<MainType><SubType><Version><Length><ISCC-BODY>^did:iscc:[2-7a-z]{10,88}$DID representation of an ISCC-ID
did:iscc:miagwptv4j2z57ci\nThe ISCC DID MAY be updated or deactivated in accordence with the chain specific implementation of the ISCC declaration protocol.
"},{"location":"iep-0015/#4-verifiable-data-registry","title":"4. Verifiable Data Registry","text":"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.
Figure 1 - ISCC Verifiable Data Registry"},{"location":"iep-0015/#5-did-document","title":"5. DID Document","text":"
DID documents are sourced from on-chain metadata and optionally from immutably or mutably referenced off-chain metadata.
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.
Minimal ISCC DID Document example
{\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}\nid-property) MUST be the ISCC-ID in DID representation.controller-property) MUST be constructed deterministically by converting the blockchain account that signed the declaration transaction to a did:pkh.alsoKnownAs-property MUST be set to the ISCC-CODE registered by the transaction.service-property with type \"IsccMetadata\". The referenced serviceEndpoint SHOULD return a document of type http://purl.org/iscc/context.Info
Properties like verificationMethod, authentication, assertionMethod etc. are left out intentionally, as their autoritative values are managed by the DID document associated with the controller that can be resolved separately.
To be defined
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 service.
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.
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.
"},{"location":"iep-0015/#8-privacy-considerations","title":"8. Privacy Considerations","text":"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.
"},{"location":"iep-0015/#9-reference-implementation","title":"9. Reference Implementation","text":"An end-to-end reference implementation of the decentralized content registry is manifested by the following modules: