Media Registry

Documentation

DIDs, DID Documents & DIDComm: The Backbone of Our Decentralized Ecosystem

The OCME Media Registry leverages cutting-edge decentralized identity technologies to create a secure, transparent ecosystem for content attribution and rights management. This document explains how these technologies work together to enable our decentralized media attribution and royalty payments system, without requiring you to be a blockchain expert.

Understanding Decentralized Identity

Traditional digital identity systems rely on centralized authorities like Google, Facebook, or Twitter to verify who you are. Decentralized identity puts control back in your hands through three key technologies:

  • DIDs (Decentralized Identifiers): Unique, permanent identifiers that you control
  • DID Documents: Digital passports that contain verification methods and service endpoints
  • DIDComm: A secure messaging protocol that enables private, authenticated communication between DID owners

Together, these technologies allow us to build a media ecosystem where content ownership, attribution, and rights can be verified without relying on a central authority.

DIDs: The Foundation of Digital Identity

What Are DIDs?

A Decentralized Identifier (DID) is like a digital social security number that you control completely. Unlike traditional usernames or email addresses that are controlled by service providers, DIDs:

  • Are globally unique (no two are the same)
  • Are persistent (they don't change or disappear over time)
  • Are cryptographically verifiable (they can prove who created them)
  • Are decentralized (not controlled by any single organization)

How We Use DIDs

In the OCME Media Registry, we create unique DIDs for:

  • Media files: Each video, audio track, or media asset gets its own DID that serves as its permanent digital identifier
  • Content records: The creative work metadata associated with media files
  • Creators: Artists, musicians, directors, and other contributors
  • Split sheets: Records of rights ownership and revenue allocation

Real-World Example

When a creator uploads a music video to the Media Registry, we automatically generate a DID for the video file. This DID becomes the permanent identifier for that video, allowing us to track its usage, attribute it correctly, and ensure royalties flow to the right people—even if the file is renamed, the metadata changes, or it's used across different platforms.

The Key Hierarchy in Our DID System

How Keys and Digital Identities Work Together

Our registry uses a hierarchical key system that enables secure, verifiable digital identities with different permission levels for various stakeholders in the ecosystem.

Three-Tier Key Structure

The OCME Media Registry uses a three-tier key structure:

  • Admin Keys: The highest level of authority in our system. Admin keys can generate other keys, sign any DID document, and manage the entire registry.
  • Creator Keys: Issued to content creators and rights holders. Creator keys can only sign content that the creator owns, establishing verifiable ownership and attribution.
  • Curator Keys: Special-purpose keys that grant viewing and download access to all content in the registry, but without signing capabilities.

All keys in our system are built on secure RSA 2048-bit cryptography, ensuring robust protection for valuable media assets.

The DID Creation Process

When a new entity is added to our registry, the process works like this:

  1. Key Authorization: The appropriate key (admin or creator) is used based on the action
  2. DID Assignment: A unique decentralized identifier is created following our did:webvh method
  3. Document Creation: A DID document is generated with all relevant entity information
  4. Cryptographic Signing: The document is signed by the appropriate key, establishing its authenticity

Each signature in our system creates a cryptographic seal that confirms:

  • Who created or modified the document
  • That the document hasn't been altered since signing
  • The authority level of the signing key

Verification Without Centralization

This key hierarchy enables our registry to maintain security and trust without requiring centralized authority. Any party can verify signatures against the public keys in our system, creating transparency while preserving appropriate access controls.

The combination of admin, creator, and curator keys ensures that our ecosystem balances security, ownership rights, and appropriate content access in a cryptographically verifiable way.

Understanding the did:webvh Method

What is did:webvh?

The did:webvh method is a specialized variant of the did:web method developed by the Decentralized Identity Foundation to support hierarchical identifiers with verifiable history. While did:web was designed primarily for web domains, did:webvh extends this approach to support hierarchical paths and entity types, which is crucial for our media attribution system.

The did:webvh Format

The official specification for did:webvh provides a comprehensive framework for hierarchical identifiers. Our current implementation uses a simplified but compliant approach focused on entity types:

did:webvh:<domain>:<entity-type>:<unique-id>

Where:

  • <domain>: The fully qualified domain hosting the DID documents (did.ocmeregistry.com)
  • <entity-type>: The type of entity (media, content, creator, splitsheet)
  • <unique-id>: A cryptographic hash-based identifier unique to the entity

In our implementation, we use a structured format: did:webvh:did.ocmeregistry.com:<entity-type>:<unique-id>

For example: did:webvh:did.ocmeregistry.com:media:7ac7285d4c9d17e3

Key Advantages of Our did:webvh Implementation

  • Entity-based hierarchy: Our implementation clearly separates different entity types (media, content, creators)
  • Cryptographic verification: Each DID document is signed with RSA keys for tamper-evident verification
  • Unique identifiers: Uses cryptographic hashing to generate collision-resistant unique IDs
  • No blockchain dependency: Works with standard web infrastructure while providing strong security
  • Standardized resolution: Resolves through well-understood HTTP mechanisms
  • W3C compliance: Follows W3C DID standards for interoperability
  • Extensibility: Designed to support future enhancements like DIDComm messaging

Based on Industry Standards

Our implementation is inspired by the DID Web Variant for Hierarchical Identifiers specification created by the Identity Foundation. We've adopted key concepts while implementing a focused solution for our specific use case.

Our current implementation enables us to:

  • Create unique, persistent identifiers for all entities in our ecosystem
  • Store comprehensive metadata in structured DID documents
  • Verify the integrity of our DID documents through RSA cryptographic signatures
  • Establish a foundation for future enhancements like verifiable history and DIDComm

DID Documents: Digital Passports

What Are DID Documents?

A DID Document is like a digital passport that contains important information about the DID. While the DID itself is just an identifier, the DID Document contains:

  • Verification methods (cryptographic keys) that can prove control of the DID
  • Service endpoints where you can interact with the DID owner
  • Metadata specific to the entity the DID represents
  • Cryptographic proofs that verify the document hasn't been tampered with

How We Use DID Documents

In the OCME Media Registry, DID Documents serve as the authoritative record for:

  • Technical metadata: File formats, resolution, duration, hash values
  • Content attribution: Who created what and their specific roles
  • Rights management: Who owns what percentage of rights
  • Verification: Cryptographic proofs that ensure data hasn't been altered

Real-World Example

When a music video is registered in our system, its DID Document contains complete technical information about the file (format, resolution, hash values), along with attribution data. If someone later questions who directed the video or who owns the rights, the DID Document provides cryptographically verified proof that can resolve the dispute. This is much more reliable than traditional metadata that can be easily altered or lost.

DIDComm: Future Secure Communication Capabilities

Future Enhancement: The DIDComm capabilities described in this section represent planned functionality that will build upon our existing DID infrastructure.

What Is DIDComm?

DIDComm (DID Communication) is a secure messaging protocol that will allow DID owners to communicate with each other privately and with authentication. It's like having an encrypted, verified direct message system between any two entities with DIDs. Our existing DID implementation provides the foundation for adding these capabilities in the future.

Planned Features of DIDComm

  • End-to-end encryption: Messages will only be readable by the intended recipient
  • Authentication: Both parties will be able to verify each other's identity
  • Asynchronous: Messages can be sent even if the recipient is offline
  • Transport agnostic: Will work over HTTP, Bluetooth, or any other channel
  • Forward secrecy: Even if keys are compromised in the future, past messages will remain secure

Planned Application: DIDComm for Social Viewing

Creating Secure Viewing Communities

One of the most exciting planned applications of DIDComm in our ecosystem will be enabling secure watch parties—social viewing experiences where viewers can watch content together while chatting in real-time. These watch parties will leverage the Voyager Suite's DID infrastructure to provide several key benefits:

  • Authenticated participation: Only verified participants with valid DIDs will be able to join a watch party
  • Private communication: All messages will be encrypted end-to-end between participants
  • Content verification: The content being viewed will be verified against its DID document
  • Creator engagement: Creators will be able to join watch parties and interact directly with viewers
  • Attribution transparency: Viewers will see who created the content they're watching
How Watch Parties Will Work
  1. A host will create a watch party for a specific piece of content
  2. The watch party will get its own DID for authentication and tracking
  3. Participants will join using their creator or viewer DIDs
  4. The content's DID will be verified to ensure authenticity
  5. DIDComm will facilitate encrypted messaging among participants
  6. All viewing data will be properly attributed back to the original content and creators
Planned Technical Implementation

Behind the scenes, a watch party will leverage:

  • DID service endpoints for message delivery
  • Encrypted peer-to-peer communication channels
  • Content DID verification to ensure everyone sees the same media
  • Timestamped messages secured through the participants' verification keys
  • Synchronized playback with secure play position sharing

Example DIDComm Message Format

{
  "id": "1234567890",
  "type": "https://didcomm.org/watchparty/1.0/message",
  "from": "did:webvh:did.ocmeregistry.com:creator:b2c3d4e5f6g7h8i9",
  "to": ["did:webvh:did.ocmeregistry.com:watchparty:d4e5f6g7h8i9j0k1"],
  "created_time": "2025-04-24T15:30:45Z",
  "body": {
    "content": "This scene was filmed in one continuous take!",
    "timestamp": "00:03:45",
    "contentId": "did:webvh:did.ocmeregistry.com:content:a1b2c3d4e5f6g7h8"
  },
  "attachments": []
}

When implemented, messages like this will be encrypted before transmission using the watch party's public key, ensuring that only authenticated participants can read them. The timestamp field will allow messages to be synchronized with specific moments in the content.

Future Applications of DIDComm in Our Ecosystem

Beyond watch parties, our planned DIDComm implementation will enable several other powerful applications in our ecosystem:

Creator Collaboration Spaces

Secure spaces for creators to collaborate on projects, with all communication encrypted and authenticated. Project discussions, file sharing, and decision-making will happen in a trusted environment with perfect attribution.

Automated Rights Clearance

DIDComm-enabled negotiations between systems to automatically clear rights for content usage. When a curator wants to include content in programming, automated DIDComm messages will be able to request and receive permission from all rights holders.

Cross-Platform Verification

Systems outside the Voyager Suite will be able to use DIDComm to verify content and rights with our Media Registry. This will enable legitimate usage across platforms while maintaining proper attribution and compensation.

Building Our Decentralized Future

Our current DID implementation provides the foundation for these future DIDComm capabilities. By establishing a robust DID infrastructure today, we're laying the groundwork for a truly decentralized ecosystem for content creators, curators, and consumers. This approach ensures that as we expand our capabilities, creators will maintain control of their work, receive proper attribution, and be fairly compensated—no matter where or how their content is used.

Learn More About Our Current DID Implementation

Interested in the technical details of our current DID implementation? Check out our complete DID technical specification for a deep dive into how we've implemented these powerful technologies and how they provide the foundation for our future DIDComm capabilities.

View DID Technical Specification
Previous: Voyager Suite Integration Next: Key Management