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
License: CC-BY-4.0
Created: 2022-09-28
Updated: 2024-11-30

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.

1. Introduction#

1.1 Preface#

The ISCC DID method specification conforms to the requirements specified in the Decentralized Identifiers v1.0 Specification DID-CORE.

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 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
Decoded: ID-ETHEREUM-V0-64-6b3e75e2759efc48

1.4 ISCC-ID as DID#

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.

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.

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 follwing ABNF:

ISCC DID scheme ABNF

iscc-did = "did:iscc:" iscc
iscc     = 10*88(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]{10,88}$

2.3 ISCC DID Example#

DID representation of an ISCC-ID

did:iscc:miagwptv4j2z57ci

3. Method Operations#

3.1 Creation#

  1. 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.
  2. The initial controller of a newly created ISCC DID MUST be the did:pkh representation of the blockchain account that signed the declaration transaction.
  3. The controller MAY set a custom DID Document at declaration time by embedding or referencing it from ISCC Metadata

3.2 Read#

  1. A basic DID document is implicitly created with every ISCC declaration and MUST be deterministicaly derived from on-chain metadata.
  2. Extended DID document properties MAY be imported from externaly referenced ISCC Metadata

3.3 Update & Deactivate#

The ISCC DID MAY be updated or deactivated in accordence with the chain specific implementation of the ISCC declaration protocol.

4. Verifiable Data Registry#

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

Figure 1 - ISCC Verifiable Data Registry

5. DID Document#

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

{
  "@context": "https://www.w3id.org/ns/did/v1"
  "id": "did:iscc:miagwptv4j2z57ci",
  "controller": "did:pkh:eip155:1:0x901ee44e3bddf4bc1c08a2ed229498512f8bcfdc",
  "alsoKnownAs": "iscc:kecycpu3okiudz7tybrk5hz4jgptillat2iw7ty7eyiji4qsk5i353i",
  "service": [{
    "id":"did:iscc:miagwptv4j2z57ci#iscc-metadata",
    "type": "IsccMetadata", 
    "serviceEndpoint": "ipfs://bafybeiccys7kilr3rynlhoelrdn6ragpbfoti73h4e3oszbgd5inthicja/iscc-metadata/43.json"
  }]
}
  1. The DID subject (id-property) MUST be the ISCC-ID in DID representation.
  2. The DID controller (controller-property) MUST be constructed deterministically by converting the blockchain account that signed the declaration transaction to a did:pkh.
  3. The alsoKnownAs-property MUST be set to the ISCC-CODE registered by the transaction.
  4. If the original ISCC declaration includes a link to off-chain metadata the DID document MUST include the reference via an entry into the 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.

6. Resolving DIDs#

  1. An ISCC DID can be resolved by querying an instantiation of an ISCC content registry.
  2. The authenticity of the response can be verified through the referenced on-chain transaction.

Figure 2 - ISCC DID Architecture

Figure 2 - ISCC DID Architecture

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 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.

8. Privacy Considerations#

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.

9. Reference Implementation#

An end-to-end reference implementation of the decentralized content registry is manifested by the following modules:

10. References#

ISCC DID Method is registerd at https://www.w3.org/TR/did-extensions-methods/