Overview

For every digital asset a unique identifier can be generated through hashing its raw data. A publicly registered key pair can sign this identifier with their private key to produce a signature which can be stored publicly. A consumer can use the signature and the unique identifier to recover the signers public key. These signatures act as a mechanism for an identity to claim ownership of a asset and an end user to verify the authenticity of a asset.

The publisher can register the asset and signature, by creating a token with the same unique identifier of an asset in a public data store, in the form of a smart contract. This smart contract will give the publisher the right to manage the ownership, metadata, and license associated with the asset. While making the audit trail of these actions immutable and public.

Content Signing

Creating a Unique Id for a Digital Asset

The unique identifier for a digital asset is generated by hashing the raw data with the keccak256 (opens in a new tab) hashing algorithm. This creates a 256 bit unique identifier. This id will also be the id of the token created in publishing the asset to VERIFY. Keccak256 is used as it is supported natively by the EVM allowing for ease of computation in EVM smart contracts. This id is also included in the corresponding metadata file for the asset, binding the metadata file to the asset when signed by the publisher.

Input: Hello World
keccak256256 Output: 0x592fa743889fc7f92ac2a37bb1f5ba1daf2a5c84741ca0e0061d243a2e6707ba

Metadata Binding

Next a metadata file that follows the schema specification for assets is created. This in the creation of the metadata file the asset id is provided in the content binding field. For our example "Hello World" it would look like the following:

{
    data: {
        ...,
        "contentBinding": {
            "algo": "keccak256",
            "hash": "0x592fa743889fc7f92ac2a37bb1f5ba1daf2a5c84741ca0e0061d243a2e6707ba"
        }
    }
    signature: {...}
}

The data field of the asset metadata file is then hashed using the same keccak256 algorithm to provide a digest to be used in a signature from the publisher. the digest from the above example would be 0x9ba9e1d2f22961518702ca8d51af87f31d29b0b46bd895ae4f832029ce027d5f

Creating the Signature

The digest created from hashing the data field of the asset metadata file is then signed using a publicly registered secp256k1 key pair. The signature is stored in the metadata file along with the digest and algorithm used to generate it. See the asset metadata schema for more detail.

NOTE: By providing the asset id in the metadata file and then signing the metadata contents, the publisher is attesting to both the contents of the metadata file and the asset.

Licensing Content on VERIFY

The ContentGraph has a common interface for attaching licenses to content. This means that the complex functionality that can be expressed in the licenses is simplified for those attempting to access the underlying content.

Once a token is created in the ContentGraph, the access and reference license can be set by using one of the addresses of the smart contract licenses deployed on VERIFY. A list of the available licenses on VERIFY can be seen in Licensing. Their respective addresses can be found on the Smart Contracts page.

Access to a piece of content can be checked through the ContentGraph.sol method:

auth(bytes32 id, address user)

Each license on VERIFY has the same method and the call made on the ContentGraph will be delegated to the respective license.

By protecting your content either through a distributed key management protocol such as the lit protocol (opens in a new tab) or via a gateway that authenticates a user utilizing the ContentGraph's auth() method, you can ensure the party accessing your content is respecting the license that you have configured.

Each smart contract license has a distinct set of methods that allow the content owner to configure that license's functionality. There is only one instance of each license type. This ensures that systems that interface with these licenses, either for configuration or for gaining access, can determine their interface solely by their address.

See Licensing for more detail

Publishing on VERIFY

Once the asset id has been created and included in a signed metadata file the publisher can store this in VERIFY through minting a corresponding asset token via a transaction with the ContentGraph smart contract.

The publisher with a wallet registered to their identity mints a token through the publish method of the ContentGraph smart contract. Ownership of an asset is modeled as ownership of a token with the same unique id as a digital asset.

Each asset token has a uri to the metadata associated with the asset. Additionally the owner/publisher of a token has the right to set a license for accessing and referencing the corresponding asset.

As these identifiers are unique and solely based on the asset, there is no duplication of content. Meaning there is a 1:1 relationship between a digital asset and an identity which owns it.

Get started with publishing.

Consuming Content

An end consumer of the digital content can index directly or over all the tokens in the ContentGraph to get the associated metadata and identity of the publisher of that asset.

Consume content on VERIFY

Example

Alice has found an image on a social platform along with some claims from a user. Alice wants to verify the claims about the image from the user.

Alice can recover the unique id x of the image through hashing using keccak256.
Alice queries the smart contract for token x, and finds:
- a uri for the metadata file, which Alice downloads
- a transaction from a wallet registered to a major news publication
Alice verifies that the metadata file is bound to the asset and to the publication through its signature.
Alice disproves the claim from the user, as the image was taken years before the time social platform user claimed in their post.

Introduction Overview