Metadata Assertion

The C2PA technical specification allows actors in a workflow to make cryptographically signed assertions about the produced C2PA asset.

This specification describes a C2PA assertion referred to here as the metadata assertion, binding metadata from standards such as XMP, IPTC, and Exif to a C2PA Manifest in a tamper-evident way.

Unlike the c2pa.metadata assertion from the C2PA technical specification, this specification places no restrictions on which metadata fields may be included. This flexibility allows it to support a broader set of use cases and makes it well-suited for use in gathered_assertions in the C2PA Claim schema, where the signer of the C2PA Manifest does not attest to the accuracy of the provided metadata but still ensures the integrity of the C2PA Manifest.

Version 1.2 Draft 15 August 2025 · Version history

License

This specification is subject to the W3C Patent Policy (2004).

For sample or reference code included in the specification itself, that code is subject to the Apache 2.0 license, unless otherwise designated. In the case of any conflict or confusion within this specification repository between the W3C Patent Policy (2004) or other designated license, the terms of the W3C Patent Policy (2004) shall apply.

These terms are inherited from the Decentralized Identity Foundation Project Charter.

Contributing

This section is non-normative.

This specification is an active working draft. If you wish to contribute to its development, please view the CAWG contributing guide.

Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. No party shall be held responsible for identifying any or all such patent rights.

Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.

This document was prepared by the Creator Assertions Working Group, a working group of the Decentralized Identity Foundation.

THESE MATERIALS ARE PROVIDED “AS IS.” The Contributors and Licensees expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. IN NO EVENT WILL THE CONTRIBUTORS OR LICENSEES BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS DELIVERABLE OR ITS GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER MEMBER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Table of contents

1. Introduction

This section is non-normative.

1.1. History

In versions 1.3 and earlier of the C2PA technical specification, there were individual assertions for each metadata standard (e.g., IPTC, Exif). These were coalesced into a single “common” metadata assertion in version 1.4 of the specification. In version 2.x of the C2PA technical specification, new restrictions were added as to which metadata content could be reflected in the built-in c2pa.metadata assertion.

This specification is not a product of the C2PA, but provides a mechanism for metadata that can no longer be expressed in the c2pa.metadata assertion to be included in a C2PA Manifest.

2. Normative references

3. Standard terms

The key words “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,” “RECOMMENDED,” “NOT RECOMMENDED,” “MAY,” and “OPTIONAL” in this document are to be interpreted as described in BCP 14, RFC 2119, and RFC 8174 when they appear in any casing (upper, lower, or mixed).

4. Assertion definition

A CAWG metadata assertion SHALL have a label of cawg.metadata and SHALL follow the format for metadata assertions as described below:

Each metadata assertion shall contain a single JSON content type box containing the JSON-LD serialization of one or more metadata values. The @context property within the JSON-LD object shall be included, and used to provide context / namespaces for the metadata standards being specified. The recommended procedure to create this JSON-LD object is to first create an XMP Data Model representation of the metadata and then serialize that to JSON-LD using the JSON-LD serialization of XMP. The JSON-LD would then be stored as a JSON content type box.
— Section 18.16.2, “Metadata: Common Requirements,” of the C2PA technical specification version 2.2
The restrictions expressed in Appendix B, “Implementation Details for c2pa.metadata,” in the C2PA technical specification SHALL NOT apply to this assertion.

4.1. Examples

This section is non-normative.

An example of an common metadata assertion for an image:

{
	"@context" : {
		"exif": "http://ns.adobe.com/exif/1.0/",
		"exifEX": "http://cipa.jp/exif/2.32/",
		"tiff": "http://ns.adobe.com/tiff/1.0/",
		"Iptc4xmpCore": "http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/",
		"Iptc4xmpExt": "http://iptc.org/std/Iptc4xmpExt/2008-02-29/",
		"dc" : "http://purl.org/dc/elements/1.1/",
		"photoshop" : "http://ns.adobe.com/photoshop/1.0/"
	},
	"photoshop:DateCreated": "Aug 31, 2022", 
	"Iptc4xmpExt:DigitalSourceType": "https://cv.iptc.org/newscodes/digitalsourcetype/digitalCapture",
	"Iptc4xmpExt:LocationCreated": { 
	  "Iptc4xmpExt:City": "San Francisco"
	},
	"Iptc4xmpExt:PersonInImage": [ 
	  "Erika Fictional"
	],
	"Iptc4xmpCore:AltTextAccessibility": "Photo of Erika Fictional standing in front of the Golden Gate Bridge at sunset.",
	"exif:GPSVersionID": "2.2.0.0",
	"exif:GPSLatitude": "39,21.102N",
	"exif:GPSLongitude": "74,26.5737W",
	"exif:GPSAltitudeRef": 0,
	"exif:GPSAltitude": "100963/29890",
	"exif:GPSTimeStamp": "2019-09-22T18:22:57Z",
	"exif:GPSSpeedRef": "K",
	"exif:GPSSpeed": "4009/161323",
	"exif:GPSImgDirectionRef": "T",
	"exif:GPSImgDirection": "296140/911",
	"exif:GPSDestBearingRef": "T",
	"exif:GPSDestBearing": "296140/911",
	"exif:GPSHPositioningError": "13244/2207",
	"exif:ExposureTime": "1/100",
	"exif:FNumber": 4.0,
	"exif:ColorSpace": 1,
	"exif:DigitalZoomRatio": 2.0,
	"tiff:Make": "CameraCompany",
	"tiff:Model": "Shooter S1",
	"exifEX:LensMake": "CameraCompany",
	"exifEX:LensModel": "17.0-35.0 mm",
	"exifEX:LensSpecification": { "@list": [ 1.55, 4.2, 1.6, 2.4 ] }
  
}

An example of an common metadata assertion for a PDF:

{
	"@context" : {
	  "dc" : "http://purl.org/dc/elements/1.1/",
	  "xmp" : "http://ns.adobe.com/xap/1.0/",
	  "pdf" : "http://ns.adobe.com/pdf/1.3/",
	  "pdfx": "http://ns.adobe.com/pdfx/1.3/"
	},
	"dc:created": "2015 February 3", 
	"dc:title": [
		"This is a test file"
	],
	"xmp:CreatorTool": "TeX",
	"pdf:Producer": "pdfTeX-1.40.14",
	"pdf:Trapped": "Unknown",
	"pdfx:PTEX.Fullbanner": "This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013) kpathsea version 6.1.1"
}

5. Use with identity assertion

When a CAWG metadata assertion is included in gathered_assertions in the C2PA Claim schema, meaning that the provided metadata is not attributed to the signer of the C2PA Manifest, it is RECOMMENDED to include this assertion as a referenced assertion within a CAWG identity assertion.

This reference SHALL constitute an attestation by the named actor of that identity assertion to the accuracy of the provided metadata.

6. Use with media industry identifiers

6.1. Use case

This section is non-normative.

A work of digital media (recorded music, motion picture, stock photography, etc.) may have a large number of contributors who should be identified as contributors to a single C2PA asset. Various media industries have well-established identifiers for various individual talent professionals (musicians, actors, directors, etc.), organizations (production companies, record labels, news organizations, etc.), and content (motion picture releases or individual recorded audio tracks, etc.).

It is often not feasible to have each individual contributor generate their own identity assertion because:

  1. It is often not logistically feasible to have individual contributors involved in the content signing process, and

  2. These identifiers are often not provisioned with corresponding private key materials for signing purposes.

6.2. Use of externally-defined identifiers

To the maximum extent feasible, existing IANA-issued namespace and field names SHOULD be used to describe the media and various participants/contributors to the media. The use of items in the Dublin Core elements namespace, typically prefixed as dc, is RECOMMENDED. Some examples of preferred items in the Dublin Core namespace are:

  • dc:contributor - An entity responsible for making contributions to the resource.

  • dc:creator - An entity primarily responsible for making the resource.

  • dc:publisher - An entity responsible for making the resource available.

  • dc:identifier - An unambiguous reference to the resource within a given context.

This list is not intended to be exhaustive; implementers are encouraged to refer directly to the Dublin Core documentation for a more complete list.

A CAWG metadata assertion MAY also contain other metadata not directly described in this section.

6.3. Reference external data sources

When possible, the use of data sources hosted by trusted industry entities, such as (TO DO: name one or two) is RECOMMENDED in preference to exhaustively listing all potential participants in a work of digital media. Such data sources SHOULD be unambiguously resolvable via an IETF-registered URN scheme, such as EIDR or DOI. (TO DO: Are these appropriate examples? If so, include links?)

6.4. Attestation for a media industry metadata assertion

A metadata assertion containing media industry identifiers as described in this section SHOULD be used in combination with a CAWG identity assertion, as described in Section 5, “Use with identity assertion”, signed by a trusted industry entity to vouch for the validity of the identifiers in the metadata assertion. A trusted industry entity in this context means an entity, such as a registrar or media packager, that is trusted within the industry to accurately record the identifiers in question.

6.5. Example

This section is non-normative.

The following is an example of the CAWG metadata assertion using globally-unique, standards-based identifiers that can be freely resolved by visiting the Digital Object Identifier (DOI) Foundation web site to obtain additional authoritative information about the media asset.

Example of a CAWG metadata assertion with EIDR and HAND identifiers
{
   "@context" : {
        "dc" : "http://purl.org/dc/elements/1.1/",
   },
   "dc:contributor" : ["Edwin Stanton Porter", "urn:doi:10.23/EF98-D5B3-1931-90A8-F50C"],
   "dc:identifier" : ["The Great Train Robbery", "urn:eidr:10.5240/7791-8534-2C23-9030-8610-5"],
   "dc:date" : "1903-12-01",
   "dc:type" : "MovingImage",
}

Appendix A: Version history

This section is non-normative.

20 May 2025

16 June 2025

  • Updated C2PA technical spec references to use version 2.2.

  • Restored missing link to IETF standard terms.

  • Recommend use of identity assertion to attest to metadata authorship.

15 August 2025

  • Fix a JSON syntax error in one of the examples.