Skip to content

ISCC DID Method#

IEP: 0015
Title: ISCC DID Method
Author: Titusz Pan tp@iscc.io
Comments: https://github.com/iscc/iscc-ieps/issues/20
Status: Draft
Type: Core
Standard: IEP
License: CC-BY-4.0
Created: 2022-09-28
Updated: 2026-07-03

Abstract

A DID method that identifies digital content declarations using ISCC-IDs issued by ISCC-HUBs in accordance with the ISCC Discovery Protocol (IDP).

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.

1. Introduction#

1.1 Preface#

The ISCC DID method specification conforms to the requirements specified in the Decentralized Identifiers (DIDs) v1.1 specification DID, which builds on the Controlled Identifiers v1.0 specification CID.

1.2 Motivation#

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.

1.3 The ISCC#

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
Decoded: ISCC-IMAGE-V0-MCDI-813e9b729141e7f3c062ae9f3c499f342d609e916fcf1f26109472125751beed

Users can also declare ISCC-CODEs at an ISCC-HUB of their choice to obtain a short and globally unique ISCC-ID. A declaration is a signed statement (IsccNote) that binds an ISCC-CODE and a cryptographic content hash to the declarer's public key. The receiving hub verifies the declaration, issues an ISCC-ID, and commits the declaration to a public, append-only transparency log. The ISCC-ID is under the control of the declarer and resolves to the declared ISCC-CODE, the declaration record, and optional external metadata. ISCC-IDs are globally unique even if the same ISCC-CODE is declared multiple times by different entities. The authenticity of an ISCC-ID can be verified by anybody against the signed declaration and the transparency log of the issuing hub.

Example ISCC-ID

ISCC:MEIGKV5N6NTVF4AB
Decoded: ID-REALM_1-V1-64-1782836079523119-1

1.4 ISCC-ID as DID#

The ISCC DID method creates a mechanism to reference digital content with a globally unique persistent identifier that does not require a centralized registration authority. Instead, the ISCC Discovery Protocol defines an open and voluntary declaration protocol operated by a federation of independent ISCC-HUBs that authenticate declarations with digital signatures and record them in verifiable transparency logs.

Integrating ISCC with the DID system improves ISCC interoperability. DID documents provide standardized ways to discover services related to the referenced content and its declarer. Hubs issue declaration receipts as verifiable credentials that serve as independently verifiable proof of a declaration.

At the same time ISCC brings open content identification to the Decentralized Identifiers ecosystem.

2. Method Syntax#

2.1 Method Name#

  1. The name that shall identify this DID method is: iscc.
  2. A DID that uses this method MUST begin with the following prefix: did:iscc:.
  3. According to the DID specification, this string MUST be in lowercase.

2.2 Method Specific Identifier#

The ISCC DID scheme conforms to the DID Syntax and is defined by the following ABNF:

ISCC DID scheme ABNF

iscc-did = "did:iscc:" iscc
iscc     = 16(numbers / letters)
numbers  = %x32-37  ; 2-7
letters  = %x61-7A  ; a-z
  1. The data structure of the ISCC is <MainType><SubType><Version><Length><ISCC-BODY>
  2. The method specific identifier is a lower-cased base32 representation of the ISCC structure.
  3. The regular expression for this DID method is ^did:iscc:[2-7a-z]{16}$
  4. The ISCC MUST be an ISCC-IDv1 with header MAINTYPE = 0110 (ID), SUBTYPE = REALM, VERSION = 0001 (V1), and LENGTH = 0000 (64-bit). The method specific identifier of an ISCC-IDv1 is always exactly 16 characters.

The 64-bit body of an ISCC-IDv1 is the concatenation of:

  • 52-bit timestamp - time of issuance in microseconds since 1970-01-01T00:00:00Z
  • 12-bit HUB-ID - identifier of the issuing ISCC-HUB (0-4095)

The SUBTYPE of an ISCC-IDv1 designates the realm in which the identifier was issued. Realm 0 is the sandbox realm (testnet) intended for testing and development. Realm 1 is the first operational realm (mainnet) for production use. HUB-IDs are scoped per realm.

Note

Legacy version 0 ISCC-IDs (VERSION = 0000), which were derived from blockchain declarations, are not supported by this method and do not resolve.

2.3 ISCC DID Example#

DID representation of an ISCC-ID

did:iscc:meigkv5n6ntvf4ab

3. Method Operations#

3.1 Create#

  1. An ISCC DID MUST be created by submitting a signed declaration (IsccNote) of an ISCC-CODE to an ISCC-HUB in accordance with the ISCC Discovery Protocol (IEP-0013).
  2. The IsccNote MUST be signed with the declarer's Ed25519 key in accordance with IEP-0019 (ISCC Signature).
  3. The hub validates the declaration, issues the ISCC-ID, appends the declaration to its transparency log, and provides a signed IsccReceipt (a W3C Verifiable Credential) as durable proof of the declaration.
  4. The initial controller of a newly created ISCC DID MUST be the DID referenced by the controller field of the declaration signature or, if no controller is given, the did:key representation of the declarer's public key.

3.2 Read#

A DID document is implicitly created with every ISCC declaration and MUST be deterministically derived from the declaration record of the issuing hub:

  1. Decode the ISCC-IDv1 and extract the realm (SUBTYPE) and the HUB-ID (the low 12 bits of the body).
  2. Look up the base URL of the issuing hub by HUB-ID in the HUB-LIST of the realm.
  3. Request the declaration record from the hub (GET {hub-url}/{method-specific-id} with header Accept: application/json).
  4. Transform the declaration record into a DID document (see DID Document).

3.3 Update#

ISCC-IDs and their logged declarations are immutable. The properties of an ISCC DID document cannot be updated. Mutable metadata about the referenced content is managed at the gateway service endpoint referenced by the DID document and can change without affecting the DID document itself.

3.4 Deactivate#

  1. An ISCC DID MAY be deactivated by submitting a signed deletion request (IsccNoteDelete) to the issuing hub. The deletion request MUST be signed with the same key as the original declaration.
  2. The hub appends the deletion as a new entry to its transparency log and excludes the ISCC-ID from resolution.
  3. Resolution of a deactivated ISCC DID returns a notFound error.

4. Verifiable Data Registry#

The verifiable data registry or "target system" for ISCC DIDs is a federation of ISCC-HUBs as defined by the ISCC Discovery Protocol. Each hub:

  • accepts signed ISCC-CODE declarations and issues globally unique ISCC-IDs,
  • maintains an append-only, cryptographically verifiable transparency log (IEP-0014) of all declaration and deletion entries,
  • resolves the ISCC-IDs it has issued to their declaration records.

The HUB-LIST is the authoritative routing table of the federation. It maps the (realm, HUB-ID) pair encoded in every ISCC-IDv1 to the base URL of the issuing hub. Each hub's Ed25519 public key is published in the DID document of its domain (did:web).

5. DID Document#

DID documents are derived deterministically from hub declaration records. All information required to construct a valid DID document is available from the issuing hub and can be dynamically transformed and presented as a DID document by a DID driver implementation.

ISCC DID Document example

{
  "@context": [
    "https://www.w3.org/ns/did/v1.1"
  ],
  "id": "did:iscc:meigkv5n6ntvf4ab",
  "controller": "did:web:titusz.org",
  "alsoKnownAs": [
    "ISCC:MEIGKV5N6NTVF4AB"
  ],
  "service": [
    {
      "id": "did:iscc:meigkv5n6ntvf4ab#gateway",
      "type": "IsccGateway",
      "serviceEndpoint": "https://titusz.org/iscc/gateway/meigkv5n6ntvf4ab.json"
    }
  ]
}
  1. The DID subject (id-property) MUST be the ISCC-ID in DID representation.
  2. The DID controller (controller-property) MUST be the controller given in the declaration signature or, if absent, MUST be constructed deterministically as did:key:<pubkey> from the declarer's multibase-encoded Ed25519 public key.
  3. The alsoKnownAs-property MUST list the canonical ISCC-ID.
  4. If the declaration includes a gateway endpoint the DID document MUST include it via an entry in the service-property with type "IsccGateway". The referenced serviceEndpoint SHOULD return metadata or service descriptors related to the referenced content.

Info

Properties like verificationMethod, authentication, assertionMethod etc. are left out intentionally, as their authoritative values are managed by the DID document associated with the controller that can be resolved separately.

Resolvers SHOULD expose declaration data that is not part of the DID document via didDocumentMetadata:

ISCC DID Document Metadata example

{
  "created": "2026-06-30T16:14:39.523119Z",
  "hub": "did:web:iscc.id",
  "iscc_code": "ISCC:KADT6NPTBFIU53VEUP3BSQ4YHYFYD3C5RT5EQPSTES3V5G2VJ52JAJOPS65J2VAOK5SQ",
  "datahash": "1e20cf97ba9d540e5765f8e47fb42136fb4ff667e8f20d439bcd7ead098fad095a92",
  "metahash": "1e20388260ef011e520c6514f29d68039d8b0c5af12f20b3b72a2f2117068483ea64"
}
  1. created - the hub-attested declaration timestamp (also encoded in the ISCC-ID itself)
  2. hub - the DID of the issuing hub
  3. iscc_code - the declared ISCC-CODE describing the referenced content
  4. datahash - a cryptographic hash (BLAKE3 multihash) of the referenced content
  5. metahash - an optional cryptographic hash (BLAKE3 multihash) of associated metadata

6. Resolving DIDs#

  1. An ISCC DID can be resolved by anybody without permission using public infrastructure: the HUB-LIST and the HTTP APIs of the ISCC-HUBs.
  2. A hosted DID driver that implements DID Resolution is available at https://did.iscc.id and integrates with the DIF Universal Resolver.
  3. The authenticity of a resolution result can be verified independently of the resolver: the hub's log entry contains the signed IsccNote, whose signature re-verifies from the entry alone, the IsccReceipt is signed by the hub, and inclusion of the declaration can be proven against a signed log checkpoint.

7. Security Considerations#

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 method operations are authenticated with the declarer's Ed25519 signature over the canonicalized declaration or deletion request. The authenticity of a declaration can be verified offline from the log entry itself, and its inclusion in the log can be proven against a hub-signed checkpoint. Hubs cannot forge declarations on behalf of declarers, and the append-only transparency log makes tampering with or retroactively modifying declarations detectable.

8. Privacy Considerations#

ISCC declarations do not publish descriptive metadata to hubs. A declaration carries only the ISCC-CODE, cryptographic content and metadata hashes, the declarer's public key, and optional controller and gateway references. Personal data may however surface through the controller DID document and through metadata hosted at the gateway endpoint. The assumption is that creators have an interest in proper attribution. Note that transparency logs are public and append-only: deactivation excludes an ISCC-ID from resolution but does not erase the original declaration from the log. Applications that implement ISCC declarations are advised to inform users about any privacy related matters specific to their application.

9. Reference Implementation#

An end-to-end reference implementation of the ISCC Discovery Protocol is manifested by the following modules:

10. References#