Manifest Assertions & Actions

Overview

Manifest Assertions and Actions are core components of Que Manifests, providing the granular detail about an asset's provenance. Assertions are structured metadata entries that describe when, where, and how an asset was created or transformed, or details about its content. Actions, a specific type of assertion, detail the sequence of events and modifications applied to an asset throughout its lifecycle.

Together, they allow you to build a comprehensive, verifiable history for any digital asset, crucial for maintaining trust and transparency in its origin and evolution.

Assertions

Assertions are key-value pairs embedded within a Que Manifest. They declare specific pieces of information about the asset, its history, or its content.

In the JSON manifest structure that Que uses, each assertion is represented by a ManifestAssertion object. These objects are typically placed within an assertions array. A ManifestAssertion requires a label (a string identifier) and data (arbitrary information in JSON-LD format). Optional properties like kind and instance offer further control.

The standard form of an assertion in a JSON manifest looks like this:

{
  "label": "Label string",
  "data": {
    // Arbitrary data, often in JSON-LD format
  },
  "kind": "Json" // Optional: "Cbor", "Json", "Binary", or "Uri"
  // "instance" : 0 // Optional and rarely used
}

Metadata Assertions

Metadata assertions provide standardized ways to embed descriptive or technical information about an asset. They must include one or more @context properties in the data object, as specified by JSON-LD.

Creative Work Assertion (`stds.schema-org.CreativeWork`)

What is it? This assertion states that an asset is the product of creative effort, such as an original photograph or artwork. It leverages Schema.org's CreativeWork type to describe properties like author, publisher, and publication date.
Why use it? It provides fundamental attribution and contextual information about the asset's creation, enhancing its discoverability and establishing its creative origin.
How to get started: Include this assertion with relevant details about the creative work.

{
  "label": "stds.schema-org.CreativeWork",
  "data": {
    "@context": "https://schema.org",
    "@type": "CreativeWork",
    "url": "https://example.com/my-original-photo"
  },
  "kind": "Json"
}

Exif Assertion (`stds.exif`)

What is it? This assertion allows you to embed Exchangeable Image File (Exif) metadata within the manifest. Exif includes technical details captured by digital cameras, like make, model, shutter speed, ISO, and GPS location.
Why use it? It cryptographically links verifiable camera and device information to the asset, providing concrete evidence of its capture details.
How to get started: Use the stds.exif label and populate the data field with Exif properties.

{
  "label": "stds.exif",
  "data": {
    "@context": {
      "exif": "http://ns.adobe.com/exif/1.0/"
    },
    "exif:GPSVersionID": "2.2.0.0",
    "exif:GPSLatitude": "39,21.102N",
    "exif:GPSLongitude": "74,26.5737W",
    "exif:GPSTimeStamp": "2019-09-22T18:22:57Z"
  }
}

IPTC Metadata Assertion (`stds.iptc`)

What is it? This assertion incorporates properties from the IPTC Photo Metadata Standard and Video Metadata Standard. It describes ownership, rights, and rich descriptive metadata for images and videos.
Why use it? It allows you to embed widely recognized and standardized professional metadata, ensuring comprehensive and portable information about the asset's content, rights, and usage.
How to get started: Use the stds.iptc label with JSON-LD formatted data adhering to IPTC standards.

Avoid using the IPTC plus:DataMining property. Instead, use the Que "Do Not Train" assertion for explicit data mining and AI/ML training permissions.

{
  "label": "stds.iptc",
  "data": {
    "@context": {
      "Iptc4xmpCore": "http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/",
      "dc": "http://purl.org/dc/elements/1.1/",
      "photoshop": "http://ns.adobe.com/photoshop/1.0/"
    },
    "photoshop:DateCreated": "Aug 31, 2022",
    "dc:creator": ["Julie Smith"],
    "dc:rights": "Copyright (C) 2022 Example. All Rights Reserved.",
    "photoshop:Credit": "Julie Smith/Example Photo"
  }
}

Que Standard Assertions

The C2PA Technical Specification defines a set of standard assertions that Que integrates and supports. In addition, you can define custom assertions for specific application needs.

Here are some of the most important standard assertions you'll use with Que:

Assertion	Label	Description
Actions	`c2pa.actions`	Records creation, edits, and other modifications applied to an asset, such as cropping, color adjustments, or generative AI transformations.
"Do Not Train"	`c2pa.training-mining`	Indicates permissions regarding the use of an asset for data mining, AI/ML training, or inference.
Creative Work	`stds.schema-org.CreativeWork`	Identifies the asset as a product of creative effort, providing authorship and context.
Exif Information	`stds.exif`	Embeds camera and device metadata, linking technical capture details to the asset.
Content Bindings	`c2pa.hash.*`, `c2pa.soft-binding`	Cryptographically links portions of an asset to its assertions, ensuring integrity and preventing tampering.
IPTC Metadata	`stds.iptc`	Provides professional metadata describing ownership, rights, and descriptive information for image and video assets.

Do Not Train Assertion (`c2pa.training-mining`)

What is it? Assertions with the c2pa.training-mining label define whether permission is granted to use an asset for data mining, machine learning (ML) training, or inference (sometimes referred to as "do not infer").
Why use it? This is crucial for creators and rights holders to explicitly control how their content is used in emerging AI and data processing contexts.
How to get started: Specify entries within the data object for different types of use, each with a use property.

The use property can have one of three values:

allowed: Permission is granted for this type of use.
notAllowed: Permission is NOT granted for this type of use.
constrained: Permission is not unconditionally granted. You can provide more details (e.g., contact information) in the constraints_info text property.

For more information, see the C2PA Technical Specification on Training and Data Mining.

{
  "label": "c2pa.training-mining",
  "data": {
    "entries": {
      "c2pa.ai_generative_training": { "use": "notAllowed" },
      "c2pa.ai_inference": { "use": "notAllowed" },
      "c2pa.ai_training": { "use": "notAllowed" },
      "c2pa.data_mining": {
        "use": "constrained",
        "constraint_info": "Contact legal@example.com for more info."
      }
    }
  }
}

Content Bindings (`c2pa.hash.*`)

What is it? Content bindings are standard assertions, such as c2pa.hash.boxes and c2pa.hash.data, that cryptographically identify specific portions of an asset. They ensure that the assertions are immutably linked to the content they describe.
Why use it? These bindings are fundamental to verifying the integrity of the asset and its provenance. If the content changes in a way not accounted for by the manifest, the bindings will fail verification.
How to get started: While Que automatically manages many content bindings during signing, understanding their structure is important for advanced verification and debugging. The exclusions property, for example, denotes parts of the asset intentionally excluded from the hash calculation (like the manifest itself).

For more information on content bindings, see the C2PA Technical Specification.

{
  "label": "c2pa.hash.data",
  "data": {
    "alg": "sha256",
    "exclusions": [
      {
        "length": 51179,
        "start": 20
      }
    ],
    "hash": "DcGR4k9M6aLXXCeDii4tSdX45rrIM5HSr1Wy/czQ6ro=",
    "name": "jumbf manifest",
    "pad": "<omitted>"
  }
}

Custom Assertions

What are they? When standard assertions do not cover your specific use cases, Que allows you to define custom assertions.
Why use them? They provide the flexibility to embed unique, application-specific data into the manifest, ensuring that all relevant provenance information can be recorded.
How to get started: A custom assertion uses a label string with reverse domain name notation syntax (e.g., com.mycompany.myproduct).

{
  "label": "com.mycompany.myproduct",
  "data": {
    "git_hash": "023bb51",
    "lib_name": "Que Integration Library",
    "lib_version": "1.0.0",
    "target_spec_version": "1.2"
  },
  "kind": "Json"
}

Actions

Actions are a specialized type of assertion that specifically record events related to an asset's creation, edits, or other significant modifications. They are expressed as an array of objects within a c2pa.actions assertion.

What are they? Actions provide a chronological record of what happened to an asset, by whom, and with what tools.
Why use them? They build a transparent and verifiable history, which is critical for establishing authenticity and understanding the transformations an asset has undergone.
How to get started: Include an actions array within the data of a c2pa.actions assertion, with each object detailing a specific event.

{
  "label": "c2pa.actions",
  "data": {
    "actions": [
      {
        "action": "c2pa.created",
        "digitalSourceType": "http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia",
        "softwareAgent": "Que AI Tool"
      }
    ]
  }
}

Each object in the actions array has the following standard properties:

Property	Required?	Description	Example
`action`	Yes	The specific action performed (e.g., `c2pa.created`, `c2pa.cropped`). See Action Names.	`c2pa.created`
`digitalSourceType`	No	A URL identifying how an asset was created or modified, using an IPTC term. See Digital Source Type.	`http://cv.iptc.org/newscodes/digitalsourcetype/digitalCapture`
`softwareAgent`	No	The software or hardware (tool, service, or device) used to perform the action.	`"Que Editor"`
`parameters`	No	Additional, action-specific information. This is often used to link actions to ingredients.	`{"ingredientIds": ["instance-id-123"]}`

Action Names

The action property's value must be one of the pre-defined standard C2PA action strings (e.g., c2pa.created, c2pa.cropped, c2pa.resized). You can also define custom action names using reverse domain name notation.

The set of standard C2PA actions includes fundamental events like c2pa.created for when an asset is initially generated, and various others for content modifications.

Digital Source Type

What is it? The digitalSourceType property specifies how an asset was created or modified (e.g., "digital capture," "digitized from negative," or "trained algorithmic media").
Why use it? It provides critical context about the method of creation, helping to classify and understand the nature of the asset (e.g., whether it's an original photo or AI-generated).
How to get started: Use a URL from the International Press Telecommunications Council (IPTC) NewsCodes Digital Source Type scheme.

The value is typically of the form http://cv.iptc.org/newscodes/digitalsourcetype/<CODE>, where <CODE> is one of the types below:

Code	Description
`algorithmicallyEnhanced`	Minor augmentation or correction by algorithm.
`algorithmicMedia`	Media created purely by an algorithm not based on any sampled training data.
`composite`	Mix or composite of several elements, any of which may or may not be generative AI.
`compositeCapture`	Mix or composite of several elements that are all captures of real life.
`compositeSynthetic`	Mix or composite of several elements, at least one of which is synthetic.
`digitalCreation`	Media created by a human using non-generative tools.
`digitalCapture`	Digital media captured from a real-life source using a digital camera or recording device.
`humanEdits`	Augmentation, correction or enhancement by one or more humans using non-generative tools.
`screenCapture`	A capture of the contents of a computer or mobile device screen.
`trainedAlgorithmicMedia`	Digital media created algorithmically using a model derived from sampled content (e.g., by generative AI tools).
`virtualRecording`	Live recording of a virtual event based on synthetic and optionally captured elements.

This table provides a summary. For the authoritative and most up-to-date list, always refer to the IPTC NewsCodes Digital Source Type scheme (controlled vocabulary).

Generative AI Action

To specify that an asset was created or significantly modified using generative AI, use the c2pa.created action with a digitalSourceType that indicates algorithmic media.

trainedAlgorithmicMedia: For an asset created entirely by generative AI tools.
compositeWithTrainedAlgorithmicMedia: For an asset that incorporates one or more elements created by generative AI tools (e.g., inpainting, outpainting).

{
  "label": "c2pa.actions",
  "data": {
    "actions": [
      {
        "action": "c2pa.created",
        "digitalSourceType": "http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia",
        "softwareAgent": "Que Generative Service"
      }
    ]
  }
}

Where "Que Generative Service" is the name of the generative AI tool or service used.

Parameters

What are they? The parameters property within an action object can contain any data that provides more details on the action.
Why use them? They allow for highly specific contextual information to be attached to an action, enhancing the granularity of the provenance record.
How to get started: Add an object to the parameters property with your custom data. A common use case is to link actions to ingredients using ingredientIds.

{
  "action": "c2pa.color_adjustments",
  "parameters": {
    "com.example.color_profile": "sRGB IEC61966-2.1",
    "com.example.brightness_value": "26"
  }
}

Important for Multi-Part Assets

The C2PA specification requires that certain actions (such as c2pa.transcoded, c2pa.repackaged, c2pa.opened, or c2pa.placed) must have one or more associated ingredients. This is achieved by including the ingredientIds parameter within the parameters object, containing an array of instance_id values from the relevant ingredients.

Linking to Ingredients (`instance_id`)

When an action involves other assets (like an image being composited onto another), these are referred to as ingredients. The instance_id property uniquely identifies an ingredient within a manifest.

To associate an action with an ingredient, the parameters object for that action must include an ingredientIds property, which is an array containing the instance_id values of the ingredients involved.

{
  "ingredients": [
    {
      "title": "background.jpeg",
      "format": "image/jpeg",
      "instance_id": "xmp.iid:813ee422-9736-4cdc-9be6-4e35ed8e41cb",
      "relationship": "parentOf"
    }
  ],
  "assertions": [
    {
      "label": "c2pa.actions",
      "data": {
        "actions": [
          {
            "action": "c2pa.placed",
            "parameters": {
              "ingredientIds": [
                "xmp.iid:813ee422-9736-4cdc-9be6-4e35ed8e41cb"
              ]
            }
          }
        ]
      }
    }
  ]
}

In this example, the c2pa.placed action is explicitly linked to the ingredient identified by "xmp.iid:813ee422-9736-4cdc-9be6-4e35ed8e41cb", showing that background.jpeg was incorporated into the asset.

Assets in Que

Manifests

Asset management

Utility

Manifest Assertions & Actions

On this page