Skip to content

Latest commit

 

History

History
210 lines (155 loc) · 11 KB

SEP-001.md

File metadata and controls

210 lines (155 loc) · 11 KB

SEP-001: Multimedia Metadata in Decentralized Systems

Status: Draft | Category: Standards

Introduction

The purpose of this document is to propose a standard for transmitting and managing multimedia resources over decentralized systems. The goal of this standard is to achieve interoperability, security, and federation of such resources.

"JWTs represent a set of claims as a JSON object that is encoded in a JWS and/or JWE structure."

The proposed standard uses JSON Web Token (JWT) as the standard container for metadata. It extends JWT with additional claims to represent the structural, descriptive, and technical metadata of the resources.

Summary

In general, the proposed standard extends the JWT standard by adding additional claims to embed metadata related to media resources and aims to group as many media types as possible into a common subset of tags that apply to all media and then reduce them to write specific fields with the ultimate goal of promoting interoperability and federation of multimedia resources in decentralized systems.

Motivation

Currently, the majority of media resources are transmitted through centralized systems that are managed by a central authority. This authority controls the consumption, transmission, and management of the resources. However, in decentralized environments such as IPFS, there is a lack of standardization or specification defining the metadata structure for multimedia resources.

The absence of standardization presents significant challenges in managing resources, ensuring their security, ownership, and transmitting resources among all participating nodes. Additionally, managing digital rights of resources transmitted across the network presents another substantial challenge, as there are no organic action mechanisms in place to establish proof of ownership of digital resources.

Rationale

  1. Why JWT?

Interoperability is a key benefit of using the JWT standard. JWT is a widely recognized and supported standard in many programming languages, frameworks, and tools. We strongly believe that JSON Web Tokens (JWT) can serve as a foundation for our current standard and progress towards becoming a robust and secure standard by implementing JSON Web Signature (RFC7515) and JSON Web Encrypted (RFC7516).

  1. Why does it need to be signed?

By allowing verification of the data origin through a digital signature, it becomes possible to provide "proof of ownership".

Imagine a scenario in which the signature of a JWT token can be verified by multiple nodes in a network, rather than relying on a centralized machine for validation. This would create a decentralized identity system that allows any entity within the network to verify the authenticity of the media resource. For example, the verification process could be executed by leveraging a trusted identity provider within the network, such as a Decentralized Identifier (DID).

Requirements and Expectations

This standard is governed by the principles established in RFC2119, which means that it uses the following keywords to indicate the level of requirement:

  1. MUST: indicates an absolute requirement.
  2. SHOULD: indicates a strong recommendation, but not mandatory.
  3. MAY: indicates an option that may be considered, but is not mandatory.

Structure of JSON Web Token

The JSON Web Token (JWT) serves as a structured container for metadata and must adhere to the format outlined in the RFC7519 specification.

JOSE Header

In the context of the implementation, the typ header parameter MUST be included to establish the specific format of the associated multimedia resource, following the guidelines provided by IANA MediaTypes.

{
    "typ": "image/jpeg",
    "alg": "ES256"
}

Additional Claims

The proposed standard introduces additional claims that represent the structural, descriptive, and technical metadata of multimedia resources. These claims serve as a starting point for a set of useful and interoperable claims. To maintain a compact representation, all names are kept short.

  1. "s" structural metadata

    Structural metadata MUST represent information that describes the internal structure of a multimedia resource. The following fields MUST be included in the "s" claim and interoperates according to the way the resources are stored:

    {
      "s": {
        "cid": "string",
        "path": "string"
      }
    }
    • "cid": It MUST be a string representing the Content Identifier (CID) of the multimedia resource or resource directory.
    • "path": This field MAY be used to describe how to get to the resource if the CID points to a directory.

    For each multimedia resource being transmitted over decentralized systems, the JWT metadata payload MUST include the "s" claim..

  2. "d" descriptive metadata

    Descriptive metadata MUST represent information that describes the content of a multimedia resource. The following fields MUST be included in the "d" claim, and custom fields MAY be added to include any other relevant information related to the resource description:

    {
      "d": {
        "title": "string",
        "description": "string"
      }
    }
    • "title": It MUST be a string expressing the title of the multimedia resource.
    • "description": It MUST be a string expressing the description of the multimedia resource.

    For each multimedia resource being transmitted over decentralized systems, the JWT metadata payload MUST include the "d" claim..

  3. "t" technical metadata

    Technical metadata MUST represent information that describes the technical characteristics of a multimedia resource. The following fields SHOULD be included in the "t" claim, and custom fields MAY be added to include any other relevant information related to the technical characteristics:

    {
      "t": {
        "size": "integer",
        "width": "integer",
        "height": "integer",
        "length": "integer"
      }
    }
    • "size": The size of the resource. It MUST be expressed in bytes.
    • "width": The horizontal resolution of the resource. It MUST be expressed in pixels.
    • "height": The vertical resolution of the resource. It MUST be expressed in pixels.
    • "length": The duration of the audio/video. It MUST be expressed in milliseconds.

    For each multimedia resource being transmitted over decentralized systems, the JWT metadata payload MAY include the "t" claim.

Serialization

JSON Web Tokens (JWTs) are tokens used for authentication and authorization. There are two main types of JWTs: signed JWTs (also known as JSON Web Signatures, or JWS) and encrypted JWTs (also known as JSON Web Encryption, or JWE).

Both JWS and JWE can be serialized in various ways. The most common serialization formats include:

  1. JSON Compact Serialization: This is the default serialization format for JWTs. It represents digitally signed or MACed content as a compact, URL-safe string.

  2. JSON Serialization: The JWS JSON Serialization represents digitally signed or MACed content as a JSON object. This representation is neither optimized for compactness nor URL-safe. There are two variations of this serialization format:

As the chosen serialization format, General JSON Syntax MUST be used along with DAG-JOSE. DAG-JOSE provides a more secure and robust serialization format that aligns with the IPLD ecosystem.

When using the JSON Compact Serialization format, the claims SHOULD use a CID as its value, which refers to the corresponding JSON format. This approach preserves the compact and lightweight design of the JWT signature:

{
  "s": "bafkreiaa3ituempaoi4jl2dor5kksnx6fu4km53oea3kt6oaib36kljcpa",
  "d": "bafkreifn5y37s3xi2jh5x47xvci542354hb4x5iacz6lr2y7s7qbsxarrm",
  "t": "bafkreib5asheycuvwids6s3e4r6xpywgpmagcbb7d3cmq7woodkxryu3iq",
}

Standard Implementation Example

{
   "header": {
      "typ": "video/mp4",
      "alg": "ES256",
      "jwk": {
        "crv": "P-256",
        "kty": "EC",
        "x": "v6dEOAoc6yqgwz0tqdS9MuKNDViU1JM-Z330v2Vfcy4",
        "y": "XFdf6GP_TMm7U2P0xJ1G5OfustcfOeHfcvxrQsyQOyo"
      }
   },
   "payload": {
      "s": {
         "cid": "QmZG1jK2zYyzdHZtkZb9f9Uu3qQ2Ru6yvLjWFRV8ZuM6aM",
         "path": "/videos/example_video.mp4"
      },
      "d": {
         "title": "A Brief Tour of the Solar System",
         "desc": "This video provides an overview of the planets and other objects in our solar system.",
         "author": "NASA",
         "location": "Outer Space",
         "tags": [
            "solar system",
            "planets",
            "NASA"
         ],
         "language": "English"
      },
      "t": {
         "size": 1024576,
         "width": 1280,
         "height": 720,
         "codec": "h.264",
         "length": 180000,
         "fps": "30fps"
      }
   }
}

Conclusion

This standard defines a mechanism for encoding and transmitting metadata related to multimedia resources over decentralized systems. The use of JSON Web Tokens as the container structure for metadata enables interoperability, security and federation of such resources. The proposed standard defines the necessary additional claims to represent the structural, descriptive, and technical metadata of multimedia resources. The implementation of this standard MUST follow the specifications and expectations defined in this document.

References

  • RFC2119: Key words for use in RFCs to Indicate Requirement Levels
  • RFC7519: JSON Web Token (JWT)
  • RFC7515: JSON Web Signature (JWS)
  • RFC7516: JSON Web Signature (JWE)
  • DAG-JOSE: DAG-JOSE codec specification