Date: 2025-08-08

ISO/IEC DIS 21617-1:2025(en)

ISO/TC JTC 1/SC 29/WG 1

Secretariat: JISC

Information technology — JPEG Trust — Part 1: Core foundation

© ISO 2025

All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.

ISO copyright office

CP 401 • Ch. de Blandonnet 8

CH-1214 Vernier, Geneva

Phone: +41 22 749 01 11

Email: copyright@iso.org

Website: www.iso.org

Published in Switzerland

Contents

Foreword v

Introduction vi

1 Scope 1

2 Normative references 1

3 Terms and definitions 2

4 JPEG Trust framework 7

4.1 Description 7

4.2 Overview 7

4.3 Trust Record 8

4.4 Trust Manifests 9

4.4.1 General 9

4.4.2 Components of a Trust Manifest 10

4.4.3 Details of a Trust Manifest 10

4.4.4 Trust Declaration 11

4.5 Trust Indicators 11

4.5.1 General 11

4.5.2 Trust Indicator Set 12

4.6 Trust Profile 12

4.7 Trust Report 12

4.7.1 General 12

4.7.2 Trust Report generation procedure 13

4.7.3 Trust Report Assertion 14

5 Assertions 14

5.1 Overview 14

5.1.1 Description 14

5.2 Assertion metadata 15

5.2.1 General 15

5.2.2 When (date and time) 15

5.2.3 Extent of modification(s) 15

5.3 Actions 16

5.3.1 Description 16

5.3.2 Type of modification 16

5.3.3 Region of interest 16

5.3.4 Purpose of modification(s) 16

5.3.5 How was it created 16

5.3.6 Category of modifications 17

5.4 Bindings (hashes) 17

5.4.1 General 17

5.4.2 Hard bindings 17

5.4.3 Soft bindings 17

5.5 Using existing metadata standards 17

5.5.1 Exif 17

5.5.2 IPTC 18

5.6 Intellectual property rights 18

5.6.1 General 18

5.6.2 Identity 18

5.6.3 Rights 20

5.6.4 IPR Examples 23

6 Embedding and referencing 24

6.1 Use of JUMBF 24

6.2 Embedding manifests into JPEG assets 24

6.2.1 Embedding manifests into JPEG 1 and JPEG XT 24

6.2.2 Embedding manifests into JPEG XL 24

6.2.3 Embedding manifests into JPEG 2000 25

6.2.4 Embedding manifests into JPEG XS 25

6.3 Embedding manifests into other asset types 25

6.4 External manifests 26

6.5 Embedding a reference to the active manifest 26

7 Media asset content binding 26

7.1 General 26

7.2 Cryptographic binding to content 26

7.3 Content hash 26

7.4 Use of digital signatures 27

7.5 Use of timestamps 27

7.6 Validation 27

8 Privacy and Protection 28

8.1 General 28

8.2 Anonymisation 28

8.2.1 Redaction 28

8.3 Obfuscation 29

8.3.1 General 29

8.3.2 Protecting an assertion 29

8.3.3 Protecting the media asset content 31

Annex A (normative) Serialisation of Trust Indicator Sets 33

Annex B (normative) Serialisation of Trust Profiles 43

Annex C (normative) Serialisation of Trust Reports 54

Annex D (informative) Using Dublin Core metadata with JPEG Trust 59

Annex E (informative) Relationship between this document (JPEG Trust) and Content Credentials 63

Annex F (informative) Threat vectors 64

Annex G (informative) Change History 67

Bibliography 68

Foreword

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.

The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see https://www.iso.org/directives or https://www.iec.ch/members_experts/refdocs).

ISO and IEC draw attention to the possibility that the implementation of this document may involve the use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not received notice of (a) patent(s) which may be required to implement this document. However, implementers are cautioned that this may not represent the latest information, which may be obtained from the patent database available at https://www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not 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.

For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO’s adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see https://www.iso.org/iso/foreword.html. In the IEC, see https://www.iec.ch/understanding-standards.

This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 29, Coding of audio, picture, multimedia and hypermedia information.

A list of all parts in the ISO 21617 series can be found on the ISO and IEC websites.

Any feedback or questions on this document should be directed to the user’s national standards body. A complete listing of these bodies can be found at https://www.iso.org/members.html and https://www.iec.ch/national-committees.

Introduction

Current technologies permit the modification or synthetic creation of media assets. Some, like deep learning methods, can create media assets that are hard for people to distinguish from natural media assets. These technologies open new, creative opportunities that are useful for business and research usage. However, these technologies can also lead to issues relating to the use of manipulated media to spread misinformation or disinformation. Misuse of manipulated media can cause social unrest, spread rumours for political gain, or encourage hate crimes.

Media modifications are not always negative as they are increasingly a normal and legal component of many production pipelines. However, in many application domains, creators need or want to declare the type of modifications that were performed on the media asset. A lack of such declarations in these situations may reveal the lack of trustworthiness of media assets or the intention to hide the existence of manipulations. To address such problems and attempt to avoid negative impacts, some companies, including social media platforms and news outlets, are developing mechanisms to clearly detect and annotate manipulated media when they are shared.

There is a need to have a standardized way to annotate media assets (regardless of the intent) and securely link the assets and annotations together. This document (JPEG Trust) ensures interoperability between a wide range of applications dealing with media asset creation and modification, providing a set of standard mechanisms to describe and embed information about the creation and modification of media assets.

Furthermore, a key aspect of understanding the trustworthiness of a media asset is the nature of trust itself. No single trust model can accommodate all the expressions of media asset trust in society so this document (JPEG Trust) requires a flexible architecture for accommodating diverse trust models. Through the mechanism of user-defined trust profiles, this document empowers various communities to define trust models that meet the specific demands of their trust requirements.

This document (JPEG Trust) provides a comprehensive framework for individuals, organizations, and governing institutions interested in establishing an environment of trust for the media that they use, and to support trust in the media they share online. This framework addresses aspects of providing provenance information, assertion rights, extracting and evaluating trust indicators, and handling privacy and security concerns.

This is the second edition of this document (JPEG Trust). It has been updated to reflect the latest developments in the field of media provenance and to provide a framework for the declaration of intellectual property rights. Details of the changes made in this edition can be found in Annex G.

Information technology — JPEG Trust — Part 1: Core foundation

This document specifies a framework for establishing trust in media. This framework includes aspects of authenticity, provenance, attribution, intellectual property rights, and integrity through secure and reliable annotation of the media assets throughout their life cycle.

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO/IEC 10646, Information technology — Universal coded character set (UCS)

ISO/IEC 10918‑1, Information technology — Digital compression and coding of continuous-tone still images: Requirements and guidelines

ISO/IEC 15444‑1:2024, Information technology — JPEG 2000 image coding system — Part 1: Core coding system

ISO 16684‑3:2021, Graphic technology — Extensible metadata platform (XMP) specification — Part 3: JSON-LD serialization of XMP

ISO/IEC 18181‑2:2024, Information technology — JPEG XL image coding system — Part 2: File format

ISO/IEC 18477‑1, Information technology — Scalable compression and coding of continuous-tone still images — Part 1: Core coding system specification

ISO/IEC 18477‑3, Information technology — Scalable compression and coding of continuous-tone still images — Part 3: Box file format

ISO/IEC 19566‑4, Information technologies — JPEG systems — Part 4: Privacy and security

ISO/IEC 19566‑5:2023, Information technologies — JPEG systems — Part 5: JPEG universal metadata box format (JUMBF)

ISO/IEC 19566‑6, Information technologies — JPEG systems — Part 6: JPEG 360

ISO/IEC 19566‑7, Information technologies — JPEG systems — Part 7: JPEG linked media format (JLINK)

ISO/IEC 19566‑8, Information technologies — JPEG systems — Part 8: JPEG Snack

ISO/IEC 21122‑1, Information technology — JPEG XS low-latency lightweight image coding system — Part 1: Core coding system

IETF RFC 3161, C. ADAMS, P. CAIN, D. PINKAS and R. ZUCCHERATO. Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). RFC Series. ^[1]

IETF RFC 4122, P. LEACH, M. MEALLING and R. SALZ. A Universally Unique IDentifier (UUID) URN Namespace. RFC Series. ^[2]

IETF RFC 4648, S. JOSEFSSON. The Base16, Base32, and Base64 Data Encodings. RFC Series. ^[3]

IETF RFC 8141, P. SAINT-ANDRE and J. KLENSIN. Uniform Resource Names (URNs). RFC Series. ^[4]

W3C Recommendation JSON-LD, JSON-LD 1.1, https://www.w3.org/TR/json-ld11/

ODRL Information Model. ODRL Information Model 2.2, https://www.w3.org/TR/odrl-model/

Vocabulary  Expression O.D.R.L. ODRL Vocabulary & Expression 2.2, https://www.w3.org/TR/odrl-vocab/

C2PA Technical Specification, C2PA Technical Specification 2.1, Coalition for Content Provenance and Authenticity, https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html

json-formula, json-formula: A Query Language for JSON with Spreadsheet Functions, https://opensource.adobe.com/json-formula/

For the purposes of this document, the following terms and definitions apply.

ISO and IEC maintain terminology databases for use in standardization at the following addresses:

— ISO Online browsing platform: available at https://www.iso.org/obp

— IEC Electropedia: available at https://www.electropedia.org

3.1

actor

actors

human or non-human (hardware or software) that is participating in the media ecosystem

EXAMPLE camera (capture device), generation or editing software, cloud service or the person using such tools

3.2

anonymisation

process of altering data in a media asset with the aim to protect the privacy of an actor (3.1) by obscuring identifiable features

3.3

assertion

data structure which represents a statement asserted by an actor (3.1) concerning the media asset (3.19)

Note 1 to entry: This data is a part of the trust manifest (3.40)

[SOURCE: C2PA Technical Specification]

3.4

authentic media asset

media asset (3.19) that is verifiable (3.45) or trustworthy (3.44) or both

3.5

author

human whose creativity led to a work being created or modified

3.6

claim

digitally signed and tamper-evident data structure that references one or more assertion (3.3) by one or more actors (3.1), concerning a media asset (3.19), and the information necessary to represent the content binding. If any assertion was redacted, then a declaration to that effect is included

Note 1 to entry: This data is a part of the trust manifest (3.40)

[SOURCE: C2PA Technical Specification]

3.7

claim signature

digital signature on the claim (3.6) using the private key of an actor (3.1)

Note 1 to entry: The claim_signature is a part of the trust manifest (3.40)

[SOURCE: C2PA Technical Specification]

3.8

composed media asset

media asset (3.19) composed of multiple media assets

3.9

content binding

Information that associates media asset content (3.20) to a specific trust record (3.42) associated with a specific media asset (3.19), either as a hard binding (3.13) or a soft binding (3.36)

[SOURCE: C2PA Technical Specification]

3.10

coordinate system

method of representing points in a space of given dimensions by coordinates

3.11

fingerprint

set of inherent properties computable from media asset content (3.20) that identifies the content or near duplicates of it

[SOURCE: C2PA Technical Specification]

3.12

generative AI media asset

synthetic media asset

media asset (3.19) created by means of artificial intelligence (AI) and machine learning (ML)

3.13

hard binding

One or more cryptographic hashes that uniquely identifies either the entire media asset (3.19) or a portion thereof

[SOURCE: C2PA Technical Specification]

3.14

intellectual property rights

IPR

exclusive rights of the actor (3.1) to the intellectual work of their creation

3.15

invisible watermark

Information incorporated in a substantially human imperceptible way into the media asset content (3.20) of an media asset (3.19) which can be used, for example, to uniquely identify the media asset or to store a reference to a trust record (3.42)

[SOURCE: C2PA Technical Specification]

3.16

JPEG 1

common image compression data format and means of reference to ISO/IEC 10918-1:1994

3.17

JUMBF

universal format to embed any type of metadata in any box-based JPEG file format and means of reference to ISO/IEC 19566-5:2023

3.18

manipulated media asset

manipulated media

media asset (3.19) that has been changed with the intention to induce misinterpretation

3.19

media asset

digital assets including images, videos, audio or text

3.20

media asset content

portion of a media asset (3.19) that represents the actual content, such as the pixel data of an image, along with any additional technical metadata required to understand or render the content (e.g., a colour profile or encoding parameters)

3.21

media asset integrity

lack of corruption of a media asset (3.19)

3.22

media asset metadata

portion of a media asset (3.19) that represents non-technical information about the media asset or its content, such as location, creator, annotations or IPR information

3.23

media asset original

media asset (3.19) produced by a device or method without any modifications

3.24

media asset provenance

set of information about a media asset (3.19) including the trail of modifications starting from an actor (3.1)

EXAMPLE the media asset origin

Note 1 to entry: Modifications that are missing from the asset’s provenance are treated the same as an invalid or unverifiable provenance chain

3.25

media asset source

non-human actor (3.1) that created the media asset original (3.23)

3.26

modified media asset

media asset (3.19) that has been changed

3.27

natural media asset

sensor acquired media asset

3.28

obfuscation

process of altering data in a media asset with the aim to protect unauthorized access

3.29

provenance

logical concept of understanding the history of a media asset (3.19) and its interaction with actor (3.1)s and other media assets, as represented by the provenance data (3.30)

[SOURCE: C2PA Technical Specification]

3.30

provenance data

set of trust record (3.42)s for a media asset (3.19) and, in the case of a composed asset, its ingredients

[SOURCE: C2PA Technical Specification]

3.31

region of interest

ROI

subset within the media asset content (3.20) identified for a particular purpose

EXAMPLE the face portion of a portrait image, an extracted foreground object(s) or scene cuts of a video

3.32

registrar

actor (3.1) that performs a registration

3.33

registration

process of storing information (e.g. media asset, metadata or provenance) about a media asset (3.19), separate from the media asset itself

3.34

signer

actor (3.1) who digitally signs a media asset (3.19)

3.35

signing

process that establishes the relation between an actor (3.1) and a media asset (3.19) in a tamper-evident manner

3.36

soft binding

content identifier that is either (a) not statistically unique, such as a fingerprint (3.11), or (b) embedded as an invisible watermark (3.15) in the identified media asset content (3.20)

[SOURCE: C2PA Technical Specification]

3.37

trust declaration

specific type of trust manifest (3.40) that, when present, is always first in the trust record (3.42)

Note 1 to entry: It represents the actor (3.1) that created the media asset (3.19) and contains only mandatory assertions

3.38

trust indicators

information derived from a combination of the media asset (3.19) and the trust record (3.42) that indicate a level of trustworthiness of a media asset in a given context

3.39

trust indicator set

set of trust indicators (3.38) that are derived from a media asset (3.19) and its trust record (3.42)

3.40

trust manifest

set of information about the media asset provenance (3.24) of a media asset (3.19)

Note 1 to entry: A trust manifest is part of a trust record (3.42)

3.41

trust profile

set of expressions that are used to evaluate each trust indicators (3.38) in an given trust indicator set (3.39) to indicate a level of trustworthiness for a given media asset (3.19)

3.42

trust record

collection of one or more trust manifest (3.40) that can either be embedded into a media asset (3.19) or be external to its media asset

3.43

trust report

result of evaluating a trust indicator set (3.39) against a trust profile (3.41)

3.44

trustworthy

able to be relied on as being what it is asserted to be

3.45

verifiable

able to be checked

3.46

visible watermark

perceptible component of the media asset content (3.20) carrying some human consumable information about the provenance of the media asset (3.19)

[SOURCE: C2PA Technical Specification]

This document describes a framework for establishing trust in media that complies with the JPEG standards developed by ISO/IEC JTC1 SC 29/WG 1 including (ISO/IEC 10918 (JPEG 1), ISO/IEC 15444-1 (JPEG 2000), ISO/IEC 18477-1 (JPEG XT), ISO/IEC 18181-2 (JPEG XL), ISO/IEC 21122-1 (JPEG XS), ISO/IEC 19566-6 (JPEG 360), ISO/IEC 19566-7 (JLINK) and ISO/IEC 19566-8 (JPEG Snack)). The core components of the framework are built on the JPEG Universal Metadata Box Format (JUMBF), as described in 6.1. Therefore, the core principles can also be applied on other types of media that can embed JUMBF containers. The model for storing and accessing cryptographically verifiable information about a media asset is aligned with the technical aspects of Content Credentials.

NOTE For more information about the relationship between this document (JPEG Trust) and Content Credentials, see Annex E.

The JPEG Trust framework establishes that a media asset consists of the media asset content, media asset metadata, and a Trust Record. The Trust Record (4.3) is a tamper-evident unit consisting of a one or more Trust Manifests. The Trust Manifests contain a series of statements, called assertions, that cover areas such as asset creation, creation device details, authorship, edit actions, bindings to content and other information associated with the media asset.

A set of Trust Indicators (4.5) can be derived from the trust record as well as from other metadata or the media asset content. These Trust Indicators are gathered together into a Trust Indicator Set (4.5.2), which can be used to assess the trustworthiness of a media asset in a given context through the use of a specified Trust Profile (4.6). The result of this evaluation is documented in a Trust Report (4.7).

The framework and its core components are illustrated in Figure 1.

Figure 1 — Trust Framework

The Trust Record is a JUMBF superbox composed of a series of other JUMBF boxes and superboxes, each identified by their own JUMBF type UUID and label in their JUMBF Description box. The Trust Record Description box shall have a label of c2pa, a JUMBF type UUID of 0x63327061-0011-0010-8000-00AA00389B71 (c2pa) and shall contain one or more Trust Manifest superboxes (which may be a Trust Manifest or a Trust Declaration). The Trust Record may also contain JUMBF boxes and superboxes whose JUMBF type UUIDs are not defined in this document.

NOTE Allowing other boxes and superboxes enables custom extensions to this document (JPEG Trust) as well as enabling the addition of new boxes in future versions of this document without breaking compatibility.

A Trust Record (see Figure 2) shall contain at least one Trust Manifest. The set of Trust Manifests, as stored in the asset’s Trust Record, represents its Media Asset Provenance.

Figure 2 — Trust Record

A Trust Manifest (see Figure 3) is the set of information about the media asset provenance, while a Trust Declaration is a special type of Trust Manifest with only mandatory assertions that always comes first in the Trust Record.

Figure 3 — Trust Manifest

Each Trust Manifest may contain an Assertions Store (containing one or more assertions), a Claim, and a Claim Signature.

Assertions are statements about the media asset provenance of a given media asset; such as asset creation, capture device details, authorship, edit actions, and bindings to content. Assertions are wrapped up with additional information into a digitally signed entity called a Claim.

Together, these Assertions, Claims, and Signatures are all bound together into the Trust Manifest by a hardware or software component called a Claim Generator.

The Trust Manifest is a JUMBF superbox composed of a series of other JUMBF boxes and superboxes, each identified by their own JUMBF type UUID and label in their JUMBF Description box. Depending on the type of manifest, as listed in C2PA Technical Specification, 11.2 and extended by 4.4.4, the associated JUMBF type UUID for each Trust Manifest shall be used. In order to enable uniquely identifying each Trust Manifest, they shall be labelled with a IETF RFC 8141 URN) from the c2pa URN namespace. The Requestable and Label Present toggles shall both be set in the JUMBF Description box of the Trust Manifest’s JUMBF superbox.

Examples:  

— urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4

— urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4:acme

— urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4:acme:2_1

— urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4::2_1

NOTE More information about the JUMBF structure of Trust Manifests can be found in C2PA Technical Specification.

A Trust Declaration is a specific type of Trust Manifest (which is specified using the JUMBF type UUID of 0x63326D64-0011-0010-8000-00AA00389B71 (c2md)) that shall only be defined during creation of a media asset and shall only contain a specific set of mandatory assertions, as well as the Claim and Claim Signature.

These mandatory Assertions are:

— exactly one hard binding assertion;

— either a c2pa.hash.data, c2pa.hash.boxes, c2pa.hash.bmff.v2 or c2pa.hash.bmff.v3 based on the type of asset and version for which the manifest is destined;

— exactly one actions assertion;

— consisting of a single c2pa.created action that specifies the time of creation and a digitalSourceType field whose values indicate if it was created by a camera, software tool, human or generative AI.

NOTE The digitalSourceType field will have the value https://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia when the media asset is created from scratch by generative AI. When a generative AI uses existing media assets in addition to newly created ones, then the value of https://cv.iptc.org/newscodes/digitalsourcetype/compositedWithtrainedAlgorithmicMedia is used.

If a specific workflow requires additional assertions, those requirements can be reflected through the use of a Trust Profile that may be used to evaluate the Trust Indicator Set of the media assets. For example, a workflow could require that a media asset contain the date, time and location when it is created.

Trust Indicators are parameters that may be used to assess the trustworthiness of a media asset in a given context. Trust Indicators are derived from at least one or more of the following sources: media asset content, the trust record, and the media asset metadata. In addition, other sources of Trust Indicators may be used, such as a GenAI usage detection algorithm.

NOTE While some Trust Indicators are declared in this document, new Trust Indicators can be defined at any time to suit specific workflows.

There are no required Trust Indicators, per se, though there are some that come from required assertions in a Trust Manifest, such as information about the validation of the hard binding.

A Trust Indicator Set consists of Trust Indicators extracted from sources such as the media asset content, the trust record (if present), and the media asset metadata (if present) of a given media asset.

The Trust Indicator Set should be serialised into a W3C Recommendation JSON-LD object, with fields representing groupings of the Trust Indicators, as described in Annex A. Additionally, this document describes how to map well known serialisations to JSON-LD for the purposes of consistent processing by a validator.

NOTE Other serialisations, whether ephemeral or persistent, are possible, but are not specified in this document.

A Trust Profile enables the generation of a Trust Report from a Trust Indicator Set. A Trust Profile contains a block of information about the Trust Profile and a set of statements that are evaluated against a Trust Indicator Set. Each statement has an expression/formula that takes one or more Trust Indicators as an input and produces a single output value. The Trust Profile shall be expressed as a series of YAML documents as described in Annex B.

NOTE Other serialisations, whether ephemeral or persistent, are possible, but are not specified in this document.

A Trust Report is produced from the combination of a Trust Profile and a Trust Indicator Set, thereby documenting the result of evaluating the Trust Indicator Set against the Trust Profile. The evaluation helps to assess trustworthiness for a given media asset.

A Trust Report contains a block of information, which is extracted from and identifies the associated Trust Profile, and a list of statements that are the results of evaluating the statements in the associated Trust Profile against a given media asset’s Trust Indicator Set.

The Trust Report is serialised as a series of YAML documents, with fields representing the block of information and the list of statements, as described in Annex C.

A Trust Report assertion can be generated based on the Trust Report, which is then added to a new Trust Manifest. The new Trust Manifest can be added to update the trust record of the media asset to further enhance the trustworthiness of the media asset.

Figure 4 — Trust Report Generation Procedure

— The Trust Report generation procedure is illustrated in Figure 4, and the detailed procedure is as follows:

— The Trust Profile definition phase involves the creation of one or more Trust Profiles, which may be created by governments, media platforms, users, etc;

NOTE It can happen at any time prior to the trust establishment phase.

— The trust establishment phase starts with media assets, consisting of the media asset content and metadata (including both Trust Record and media asset metadata).

— The media asset (1) is passed to an extraction algorithm (2), which extracts Trust Indicators from the metadata (including both Trust Record and other metadata) and content of the media asset.

— The extracted Trust Indicators are then used to generate the Trust Indicator Set (3) for this media asset.

— Next, the Trust Indicator Set is sent to the verification process (4) along with the predefined Trust Profile.

— Using that Trust Profile, the verification algorithm checks whether Trust Indicators in the Trust Indicator Set satisfy the Trust Indicators’ requirements in the predefined Trust Profile.

— The verification algorithm then generates a Trust Report (5), which documents the result of the evaluation of a Trust Indicator Set against a Trust Profile.

— Afterwards, a new Trust Manifest may be generated based on the Trust Report.

— The Trust Record in the media asset should then be updated by adding in the new Trust Manifest.

A Trust Report Assertion is an embedded data assertion (C2PA Technical Specification, 18.12) containing a Trust Report, that is the result of evaluating a specific Trust Indicator Set against a specific Trust Profile. The Trust Report assertion shall have the label, jpt.report. If there are multiple instances of the jpt.report assertion, each instance shall be labelled as described in C2PA Technical Specification, 6.4.

Since the actual media asset content nor the media asset metadata is not modified, the Trust Report assertion should be added as part of an Update Manifest (C2PA Technical Specification, 11.2.3).

This document establishes media asset life cycle annotations to facilitate the production, distribution and consumption of media assets in a trustworthy manner. This is based on the use of JUMBF to serialize the various annotations — called assertions — into many different media asset formats. The use of these annotations is expected to improve trust in media consumption by expressing the provenance of a media asset throughout its lifecycle while ensuring media integrity and authenticity.

Reliable association of the media lifecycle annotations with the corresponding media asset is essential for ensuring that no information is tampered with. This enables detection capabilities in the events of alteration of the media asset. This document specifies that to achieve a wide adoption of such an annotation ecosystem, interoperability is essential.

Figure 5 — JPEG Trust Assertions

In addition, this document identifies that media assets consist of at least two parts — content and metadata. Figure 5 provides an overview of the media life cycle annotations, represented in the trust record aspects of the media asset metadata.

In this framework, an annotation for representing information about the provenance of a media asset is called an assertion. An assertion is labelled data representing a statement made by an actor about a media asset. Each of the actors in the system that creates or processes an asset should produce one or more assertions about when, where, and how the asset originated or was transformed. Actors may be human, thus adding human-generated information (i.e., copyright) or machines (software/hardware) providing the information they generated (i.e., camera type or lens details). An assertion may also include information about the actors themselves.

In various scenarios it is necessary or useful to provide additional information about an assertion, such as the actors, when (date and time) it was generated, or other data that may help users to make informed decisions about the provenance or veracity of the assertion data.

An ISO 8601-1 formatted date and time string may be included as the value of the dateTime field of the assertion metadata assertion.

Description

This assertion is used to provide a means to signal the extent of modifications of this asset compared to a reference version of the asset by providing one or more of the following objective similarity metrics:

— Root mean square error (RMSE).

— Peak signal-to-noise ratio (PSNR).

NOTE Additional metrics such as^[22],^[20] and^[21] can also be used.

An extent of modification assertion shall have a label of jpt.mod-extent.

Metadata structure

The extent of modification is expressed in this CBOR-serialised assertion by signalling the existence of an objective metric, type of objective metric and an associated value. Table 1 gives an overview of the fields of the mod-extent-map.

Table 1 — Extent of Modification fields

Schema

The schema for this type is defined by the mod-extent-map rule in Figure 6:

mod-extent-map = {

  ? "compliance" : bool,

  ? "metric" : tstr .size (1..max-tstr-length),

  ? "score" : float

}

Figure 6 — Extent of Modification Schema

This assertion records an array of actions that are carried out during the creation or subsequent modification of the media asset. While the creation refers to the activity relating to the media asset source, a modification involves any type of change to the media asset including the media asset content and media asset metadata.

Each action element within the Actions assertion provides information on the type of modification performed on a media asset including but not limited to transcoding, editing, adjustment of contrast, brightness or colour temperature, or adding annotations, etc. The current version of the Actions assertion follows the structure defined by C2PA Technical Specification, 16.12.

For each action, it is possible to identify a region of interest (ROI) within the media asset. This region can either be defined spatially (e.g., a bounding box) or temporally (e.g., time). The ROI could be used for identifying a modification region, target region for privacy perseverance or any other reasons. The details of how this is represented is defined by the region of interest metadata.

Each action may also provide a reason field that provides a free text description of the purpose of the modification. This field is optional and may be used to provide additional information about the modification.

The ‘reason’ field is explicitly defined in the c2pa.actions schema

Since the actor performing a given action could be either a human or a machine, it is important to provide information about how the action was performed and what additional tools were used in the process. The information may contain (not limited to):

— a camera capture original media asset;

— a partly modified camera capture media asset;

— a composite of two or more media assets;

— a digitized version of a physical media asset;

— a modified version of a digitized media asset;

— a synthetically generated media asset including drawing;

— a synthetically generated media asset using machine learning models, such as generative AI;

— a combination of some or all of the other items in this list.

This information is recorded using the IPTC Digital Source Type.

The category of modification can be determined by examining the values of the Actions assertions, such as the action itself. Figure 7 shows a test that can be added to a Trust Profile to determine if the image was resized in some way.

-   # Resize type of action?

    # Checks the value of each action for one of the possible values

  id: resized

  description: Was the image resized or re-oriented

  expression: >

    contains(manifest[0].assertions.'c2pa.actions.v2'actions[*].action, "c2pa.cropped") ||

    contains(manifest[0].assertions.'c2pa.actions.v2'actions[*].action, "c2pa.resized") ||

    contains(manifest[0].assertions.'c2pa.actions.v2'actions[*].action, "c2pa.orientation")

  report_text:

    "true":

      en: This media asset was resized or re-oriented

      de: Translation in German

      es: Translation in Spanish

      jp: Translation in Japanese

    "false":

      en: This media asset did not change size or orientation

      zn: Translation in Simplified Chinese

Figure 7 — Trust Profile fragment for testing resize actions

In order to establish the integrity of the media asset content and media asset metadata, a series of assertions exist to establish both hard and soft bindings between the trust record and the media asset.

This is a category of assertions as described in C2PA Technical Specification, 9.2 which ensure data integrity through established cryptographic hashing algorithms applied to specific portions of the data of the media asset. At least one of them is required to be present in any Trust Manifest and Trust Declaration. 7.2 contains more details on hard bindings.

Soft bindings refer to a methodology for verifying data integrity even when some bits are changed due to processing of the media asset such as format changes or enhancements. This is typically managed by techniques such as digital fingerprinting and digital watermarking. C2PA Technical Specification, 16.9 provides more details about how to use a soft binding, as well as a list of predefined algorithms that can be used to generate one.

The c2pa.metadata assertion and the CAWG Metadata Assertion may be used to ensure that Exif information, for example about the capture device or the location where an asset was created, is added to the asset in a way that can be validated cryptographically.

The c2pa.metadata assertion and the CAWG Metadata Assertion may be used to provide additional location information (such as IPTC location information) in addition to IPR information such as identification, attribution and rights information.

This document provides for a series of assertions that enable the declaration of intellectual property rights (IPR) by actors who may wish:

— to share a media asset through web services or other means;

— to find if a media asset is being used unlawfully;

— to find if, and how, a media asset can be used lawfully;

— to protect and/or monetize the IPR related to a media asset.

While there could be multiple levels of information that can be included in these assertions, the following basic information is proposed as a minimum:

— attribution by single or multiple actors concerning the media asset;

— rights on the media asset held by actor(s);

— genre or type of media asset, for example, artistic, style, journalistic, product or other genre(s).

In specific cases where assets are created through digitization of physical assets, clarifications are expected about the copyright ownership whether and how the ownerships are shared among the original owner of the asset and the new owner of the asset.

Identity assertion

The key component of IPR assertions is identity. As such, it is necessary to utilize an assertion that enables the identification of the actor(s) who are asserting the IPR, along with the ability for them to securely represent their relationship to the media asset and the specific IPR assertions they wish to make. This is accomplished through the use of standard cryptographic techniques to sign (at least) the trust record’s hard binding assertion, along with any other assertions that contain relevant information about or from the actor. An identity assertion should be used to provide attribution information about the media asset.

The credential holder’s signature should generally be construed as reflective of the named actor’s authorization of or active participation in the production of the media asset in which it appears. This signature should include an IETF RFC 3161-compliant timestamp to provide an additional, independent signal as to when the identity claims aggregator generated the identity assertion.

One such identity assertion that could be used is the CAWG identity assertion (as described in CAWG Identity Assertion), though other identity assertions can be used. The CAWG identity assertion allows a named actor to document their relationship to a media asset created or produced by them or on their behalf independently from the C2PA claim generator, and to allow consumers of a media asset to independently verify that the received asset was in fact produced by the named actor and has not been tampered with. Each CAWG identity assertion instance allows exactly one credential holder to sign a data structure, which among other things includes a list of assertions and a signature from the credential holder over that payload. These provide a tamper-evident binding, which also supports non-repudiation, between the named actor and the list of assertions, while also binding the identity assertion to a specific media asset. An example of a CAWG identity assertion is shown in Figure 8.

{

  "@context": [

    "https://www.w3.org/ns/credentials/v2",

    "https://cawg.io/identity/1.1/ica/context/"

  ],

  "type": [

    "VerifiableCredential",

    "IdentityClaimsAggregationCredential"

  ],

  "issuer": "did:web:connected-identities.identity.example.com",

  "validFrom": "2024-05-27T11:40:40Z",

  "credentialSubject": {

    "id": "did:web:connected-identities.identity.example.com:user:jsadkfnaksdnj",

    "verifiedIdentities": [

      {

        "name": "First-Name Last-Name",

        "type": "cawg.document_verification",

        "provider": {

          "id": "https://example-id-verifier.com",

          "name": "Example ID Verifier",

        },

        "verifiedAt": "2024-07-26T22:30:15Z"

      }

    ],

    "c2paAsset": {

      "referenced_assertions": [

        {

          "url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.hash.data",

          "hash": "U9Gyz05tmpftkoEYP6XYNsMnUbnS/KcktAg2vv7n1n8="

        }

      ],

      "sig_type": "cawg.identity_claims_aggregation"

    },

  },

  "credentialSchema": [

    {

      "id": "https://cawg.io/identity/1.1/ica/schema/",

      "type": "JSONSchema"

    }

  ]

}

Figure 8 — Example of a CAWG Identity Assertion

Attribution

Assigning a role

An identity assertion should be used to provide attribution information about the media asset. For example, the CAWG identity assertion includes a role field where the credential holder is able to stipulate their relationship(s) with the media asset including whether they are the creator, the publisher, or a contributor. An example of a CAWG identity assertion with an associated role is shown in Figure 9.

{

  "signer_payload": {

    "sig_type": "cawg.x509.cose",

    "referenced_assertions": [

      {

        "url": "self#jumbf=c2pa/urn:c2pa:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.hash.data",

        "hash": b64'U9Gyz05tmpftkoEYP6XYNsMnUbnS/KcktAg2vv7n1n8='

      },

      {

        "url": "self#jumbf=c2pa/urn:c2pa:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/cawg.metadata",

        "hash": b64'Yzag4o5jO4xPyfANVtw7ETlbFSWZNfeM78qbSi8Abkk='

      }

    ],

    "role": ["cawg.creator"],

  },

  "signature": b64'....', // COSE signature

}

Figure 9 — Example of a CAWG Identity Assertion with a Role

Associating metadata

In addition, a CAWG metadata assertion (as described in CAWG Metadata Assertion) should be used to provide additional information about the media asset, including that found in common vocabularies such as the Dublin Core metadata element set (ISO 15836-1) or the IPTC Photo Metadata Standard. If one is used in the same Trust Record as a CAWG identity assertion, then the CAWG metadata assertion shall be included in the list of referenced assertions in signer_payload of the CAWG identity assertion.

An example of a CAWG metadata assertion is shown in Figure 10.

NOTE Additional information about using the Dublin Core in conjunction with this document is provided in Annex D.

{

"@context" : {

"Iptc4xmpCore": "http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/",

"Iptc4xmpExt": "http://iptc.org/std/Iptc4xmpExt/2008-02-29/",

"dc" : "https://purl.org/dc/elements/1.1/",

"dcterms" : "https://purl.org/dc/terms/",

},

"Iptc4xmpExt:LocationCreated": {

  "Iptc4xmpExt:City": "San Francisco"

},

  "Iptc4xmpCore:copyrightNotice": "Copyright © 2021 Example Corp. News",

  "dcterms:dateCopyrighted": "2021-05-20",

  "dcterms:license": "https://creativecommons.org/licenses/by/4.0/",

  "dc:subject": ["San Francisco", "Golden Gate Bridge"],

}

Figure 10 — Example of a CAWG Metadata Assertion

It is recommended that any metadata that is added to a media asset should comply with the FAIR principles (see FAIR Principles).

Rights expression

The rights holder of a media asset may wish to assert their rights and permissions for the media asset. To do so, a rights expression assertion is used.

When used, a rights expression assertion shall have a label of jpt.rights and shall consist of a single JSON content type box containing the JSON-LD serialisation of an ODRL rights expression, as described in ODRL Vocabulary  Expression. If there are multiple instances of the jpt.rights assertion, each instance shall be labelled as described in C2PA Technical Specification, 6.4.

An example of a simple rights expression assertion is shown in Figure 11. An example of a more complex rights expression can be found in Figure 12, showing the assertion of royalty splits.

{

  "@context": "https://www.w3.org/ns/odrl.jsonld",

  "@type": "Agreement",

  "uid": "http://example.com/policy:42",

  "profile": "http://example.com/odrl:profile:09",

  "obligation": [{

    "assigner": "http://example.com/org:43",

    "assignee": "http://example.com/person:44",

    "action": [{

      "rdf: value": {

        "@id": "odrl: compensate"

      },

      "refinement": [{

        "leftOperand": "payAmount",

        "operator": "eq",

        "rightOperand": { "@value": "5.00", "@type": "xsd:decimal" },

        "unit": "https://dbpedia.org/resource/Euro"

      }]

    }]

  }]

}

Figure 11 — Example of a Rights Expression Assertion

{

  "@context": "https://www.w3.org/ns/odrl.jsonld",

  "@type": "Agreement",

  "uid": "http://example.com/policy:42",

  "profile": "http://example.com/odrl:profile:09",

  "obligation": [{

    "assigner": "self#jumbf=c2pa.assertions/cawg.identity",

      "@type": "PartyCollection",

      "source": "http://example.com/org:43/rightsholders",

      "refinement": [{

        "rightsholder":"Stéphane",

        "role":"photographer",

        "percentage":"75"

                     },{

        "rightsholder":"Jeanne",

        "role":"editor",

        "percentage":"25"

                     }],

    "assignee": "http://example.com/org:43",

    "action": [{

      "rdf: value": {

        "@id": "odrl: compensate"

      },

      "refinement": [{

        "leftOperand": "payAmount",

        "operator": "eq",

        "rightOperand": { "@value": "5.00", "@type": "xsd:decimal" },

        "unit": "https://dbpedia.org/resource/Euro"

      }]

    }]

  }]

}

Figure 12 — Example of a Rights Expression Assertion with royalty splits

Dynamic alteration of rights

Unlike those attribution assertions which are relatively static and can be embedded in the media asset, some types of rights assertions can be highly dynamic. In those cases, they should be referenced via URL.

Training and data mining

An actor may wish to provide information about whether the media asset may be used as part of a data mining or AI/ML training workflow. For example, the actor may wish to assert:

— whether the media asset’s use is allowed or not allowed for training other machine learning models;

— whether the media asset’s use is allowed but in a constrained manner where permission is not unconditionally granted for this usage. In this case consumers could contact the right holder, or respect the terms and conditions stipulated in a linked rights assertion;

— whether the AI generated media asset used only copyright free media assets, obtained all necessary usage permission or a combination of both during the training of the machine learning models that was used to produce the current media asset.

To express the first two items in the above mentioned list as part of a Trust Record, a CAWG Training and Data Mining Assertion (see CAWG Training and Data Mining Assertion) may be used. An example of one is shown in Figure 13.

{

  "entries":

"cawg.ai_training": {

"use": "allowed"

},

"cawg.ai_generative_training": {

"use": "notAllowed"

},

"cawg.data_mining": {

"use": "constrained",

"constraint_info": "may only be mined with permission from the rights holder"

}

}

Figure 13 — Example of a CAWG Training and Data Mining Assertion

It is also possible to reference a specific rights assertion in the constraint_info field of the CAWG Training and Data Mining Assertion using a JUMBF URI (as described in ISO/IEC 19566-5:2023, Annex C). This is shown in the fragment in Figure 14.

{

"cawg.data_mining": {

"use": "constrained",

"constraint_info": "self#jumbf=c2pa.assertions/jpt.rights"

  }

}

Figure 14 — Example of using constraint_info with a rights assertion reference

Figure 15 shows how the various assertions described in this clause are inter-connected to provide information about the rights and permissions of a media asset.

Figure 15 — Attribution via the CAWG Identity Assertion

In order to support many of the requirements of this document (JPEG Trust), it is necessary to store (serialize) Trust Manifests into a structured binary data store that enables some specific functionality including:

— ability to store multiple manifests (e.g., parents and ingredients) in a single container;

— ability to refer to individual elements (both within and across manifests) via URIs;

— ability to clearly identify the parts of an element to be hashed;

— ability to store pre-defined data types (e.g., JSON and CBOR);

— ability to store arbitrary data formats (e.g., XML, JPEG, etc.).

In addition to supporting all of the requirements in the list above, the chosen container format (JUMBF, ISO/IEC 19566-5:2023) is also natively supported by the JPEG standards developed by ISO/IEC JTC1 SC 29/WG 1 and is compatible with the box-based model (i.e., ISOBMFF) used by many common image and video file formats. Using JUMBF enables all the same benefits of other native box-based formats but with a few additional benefits, such as URI References, in addition to being able to work with the various JPEG standards as well as other formats.

NOTE 1 The JUMBF serialised format can be used when the Trust Records are stored separately from the asset, such as in a separate file or URI location.

A Trust Manifest consumer shall never process an assertion, assertion store, claim, claim signature or Trust Manifest that is not contained inside of a Trust Record. Additionally, when a Trust Manifest Consumer encounters a JUMBF box or superbox whose UUID it does not recognize, it shall skip over (and ignore) its contents.

NOTE 2 This means that the Trust Manifest Consumer can process private boxes that it knows about, but ignore ones of which it is unaware.

The Trust Record shall be embedded as the data contained in an APP11 Marker as defined in ISO/IEC 18477-3.

Since a single marker segment in JPEG 1 cannot be larger than 64K bytes, it is likely that multiple APP11 segments will be required, and they shall be constructed as per ISO/IEC 10918-1:1994 and ISO/IEC 19566-5:2023, D.2. When writing multiple segments, they shall be written in sequential order, and they shall be contiguous (i.e., one segment immediately following the next).

NOTE This requirement is specific to this document (JPEG Trust), as JPEG 1 allows the segments to be written in any order and does not require them to be contiguous.

As described in ISO/IEC 18181-2:2024, Clause 4, JPEG XL supports two different formats for the data. It may use a box structure that is compatible with JPEG 2000 and JPEG XS or it may be a direct JPEG XL codestream without the box structure. A JPEG XL file that uses the box structure shall contain at most one JUMBF (jumb) superbox (ISO/IEC 18181-2:2024, 9.3) containing a Trust Record Description box, which contains the Trust Record as described in C2PA Technical Specification, 12.1. A JPEG XL file that is only a codestream is unable to include an embedded Trust Record.

Figure 16 shows an example of a Trust Manifest embedded in a JPEG XL image.

Figure 16 — A Trust Manifest embedded in a JPEG XL image

The JPEG 2000 file format, as codified in ISO/IEC 15444-1:2024, Annex I, provides a box-based container format for storing data similar to ISO/IEC 14496-12 (ISO BMFF). The Trust Record shall be embedded into a JPEG 2000 file (i.e., J2C, JP2 or JPX) as the data of a box whose TBox shall have a value of jumb as described in 6.2.2 and in (ISO/IEC 18181-2:2024, 9.3).

The jumb box may appear anywhere in the file, though it is recommended to put it earlier in the file to improve retrieval. There shall be only one jumb box, containing a Trust Record Description box (4.3), in a JPEG 2000 file.

As JPEG XS (ISO/IEC 21122-1) uses the same box format as JPEG 2000, the same approach as described in 6.2.3 shall be used.

The jumb box may appear anywhere in the file, though it is recommended to put it earlier in the file to improve retrieval. There shall be only one jumb box, containing a Trust Record Description box (4.3), in a JPEG XS file.

JUMBF can be embedded into assets that are not JPEG, including other raster image formats, vector formats, audio and video formats and more. Details can be found in C2PA Technical Specification, 11.3.

In some cases, it is not possible (or practical) to embed a Trust Record in an asset. In those cases, keeping the Manifests external to the asset is an acceptable model for providing providence to assets. The manifest should be stored in a location, referred to as a manifest repository, that is easily locatable by a manifest consumer working with the asset, such as by reference or URI. As the Trust Record is a JUMBF box, it shall be served with the Media Type: application/c2pa.

Some common reasons to use an external manifest are:

— It is not practical, such as when the size of the Trust Record is larger than the asset’s digital content.

— It is not appropriate, such as when it will modify an asset that should not be modified.

NOTE An example of this is creating a manifest for a pre-existing asset.

If the asset has embedded XMP (ISO 16684-1), it is recommended that the claim generator add a dcterms:provenance key to the XMP, the value (a URI reference) being where to locate the Active Manifest. The URI shall either be a JUMBF URI for an embedded Manifest or a standard URI for any non-embedded scenarios, whether stored remotely or locally on the same storage system as the asset itself.

An example JUMBF URI is shown in Figure 17:

<dcterms:provenance>

self#jumbf=c2pa/urn:c2pa:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4

</dcterms:provenance>

Figure 17 — Example JUMBF URI

Any media asset may contain a Trust Manifest which is bound to the media asset using a signed cryptographic hash. A content hash may also be created as an additional method for binding the asset to the Trust Manifest. Trust manifests are validated by a process that tests the validity of the associated claim signature as well as the time stamp and any included credential revocation information.

A validator may also evaluate each of the assertions in the Trust Manifest, and those results become new Trust Indicators that are added to the full list of Trust Indicators (for a given asset) and compiled together into a Trust Indicator Set. This Trust Indicator Set may also then undergo evaluation and reporting in alignment with the requirements of a provided Trust Profile(s).

A key aspect to a Trust Manifest is that is cryptographically bound to a uniquely identifiable media asset. This is accomplished through the use of standard cryptographic hashes, such as SHA2-256. These hashes also enable a validator to detect if the asset has been modified since the Trust Manifest was constructed.

Because media assets can be packaged in various well-known formats, that may differ in how the data contained therein is serialised — there are multiple approaches to how to perform and then store the results of the hashing algorithm used. For example, a JPEG 1 file could be hashed using a simple data hash assertion while a JPEG 2000 file could be hashed using a general box hash. However, either could be used for the other format, and the results stored in the Trust Manifest.

While cryptographic binding focuses on security, ensuring data integrity and preventing tampering, they are not suitable for media asset content integrity verification for changes in file formats (e.g., JPEG to PNG), compression ratios, or minimal editing. This is addressed though the use of content hashing that focuses on identifying and comparing media content, allowing for approximate matching of similar content. Algorithms tightly bound with the content features are designed to generate hash values that are similar for perceptually similar content, even if the content has undergone minor modifications such as resizing, compression, or color adjustments.

Content hashes can be generated by various well established algorithms, but may differ in representations and therefore requires a common representation. This is achieved using ISO 24138: International Standard Content Code (ISCC). The ISCC defines the hash creation process for metadata and the content including text, image, audio and video. For the purpose of content hashing in the context of JPEG Trust, only media content-related information is serialised. This content hash could be stored using a new assertion to the media content.

A Trust Manifest is signed by the claim generator of the manifest, using a certificate for a specific actor. This signature is used to not only ensure that the manifest has not been tampered with since it was created, but also to clearly identify (and enable validation of) the actor that claims to have created it. This is accomplished through the use of standard digital signatures algorithms and key types, such as RSA or ECDSA.

Because the majority of assertions in a Trust Manifest are serialised into CBOR, which enables native binary data, the signature is also serialised into CBOR — specifically COSE. This enables the signature to be stored in the Trust Manifest in a compact and efficient manner that is also compatible with the rest of the assertions and claim in the manifest.

The COSE signature, that will appear as the Claim Signature in the Trust Record, should include an IETF RFC 3161-compliant timestamp (as described in C2PA Technical Specification) to provide an additional, independent signal as to when the Claim Generator generated the Trust Record. However, there are workflows where it may not be possible to obtain the timestamp at the time of signing; for those situations, a TimeStamp Manifest may be added later.

All timestamps present in a Trust Record, whether as part of the Claim Signature or an identity assertion such as the CAWG identity assertion, shall use a version 2 timestamp as defined in C2PA Technical Specification.

The determination of whether the Trust Record for a given media asset is valid is accomplished through the use of the standard validation process. The process works by first determining if the Claim Signature of the active Trust Manifest is valid, including validation of an associated time stamp and included credential revocation information. If there are no problems with the active Trust Manifest, then each of the assertions in the Trust Manifest is validated, including checking its associated hash provided in the Claim. If any of the assertions are invalid, then the entire Trust Manifest is considered invalid. The results of each of these validations are expressed as Trust Indicators which will then make their way out to the Trust Indicator Set, as described in 4.5.2.

Once the integrity of the Trust Record has been validated, then information contained in the Claim Signature’s certificate should be evaluated, and the information expressed as Trust Indicators, which will then make their way out to the Trust Indicator Set, as described in Clause A.4. This approach enables a given Trust Profile to evaluate the trustworthiness of the signing certificate against a trust model specific to that profile.

The need to ensure privacy is equally important to establishing trust in media. Various parts of a media asset can disclose privacy-related information: the media asset content, the media asset metadata, as well as the Trust Record. In principle, An actor shall be able to control the level of privacy of a media asset. This document provides the mechanisms to anonymise a media asset and control access to sensitive information. It allows an actor to apply these privacy-enhancing capabilities in different places of a media asset.

The identity of an actor or a location can be signalled in various parts of the Trust Record. An actor shall have the mechanisms to anonymise such privacy-related information according to their use case(s).

Information about the identity of an actor or a location can be found in Assertions of past Trust Manifests within a Trust Record. Each redaction action shall be signalled accordingly in the Claim of a Trust Manifest, as shown in Figure 18. This functionality follows the redaction mechanism.

Figure 18 — Redacting Assertions of past Trust Manifests

Apart from anonymising a media asset, it is also essential to enhance privacy by allowing an actor to control the access to sensitive information, either within the media asset content or outside of it. Protection mechanisms for the JPEG standards developed by ISO/IEC JTC1 SC 29/WG 1 have been defined in ISO/IEC 19566-4. These mechanisms are also applicable to all JPEG box-based formats. This document is aligned with ISO/IEC 19566-4 to allow the protection of Assertions that contain privacy-related information.

Assertions may disclose sensitive information. An actor shall be able to protect the entire Assertion — or part of it — to ensure privacy within a Trust Declaration or a Trust Manifest. This ensures that only authorized users can reveal and consume the protected Assertion.

The mechanisms specified in ISO/IEC 19566-4 enable the protection of any JUMBF serialised data. Given that the Assertion data model is serialised using JUMBF, this document uses those mechanisms to enable the protection of privacy-related Assertions. Figure 19 illustrates a Trust Record with all its assertions in plaintext.

Content binding Assertions (5.4) shall not be protected as they are used to associate a Trust Declaration and Trust Manifests with media asset content. Equivalently, action Assertions shall not be protected, given that they describe direct modifications that are taking place to media asset content.

NOTE To strike a balance between privacy and enabling trust, not all Assertions can be protected.

Figure 19 — Trust Manifest with a metadata Assertion

Assuming that an actor wants to protect an Assertion, they shall encrypt the Assertion JUMBF Box and place it in a Protection Content type JUMBF box as shown in Figure 20. The Protection Content type JUMBF box is placed within the Assertion Store. Following ISO/IEC 19566-4, the encrypted Assertion shall be placed in a Binary Data box, while all the necessary information to decrypt the ciphertext is located in the Protection Description box. When protecting an Assertion, an actor may select to pass the JUMBF Description box label to that of the Protection Content type JUMBF box. With this, an actor discloses the type of information that is protected. Otherwise, in case that an actor does not want to disclose any type of information related to the protected Assertion, the label ‘jpt.protected_assertion’ shall be used. Finally, the hash and the URI Reference of the Protection box shall be also included as part of the Claim data structure of the Trust Manifest.

Figure 20 — Protecting an Assertion

One additional functionality of the Protection Content type JUMBF box is its ability to signal access rules which accompany the protected resource. According to ISO/IEC 19566-4, within the Protection Description box there is a field, namely ‘AR Label’, which allows an actor to define a URI reference to a JUMBF Box that contains the access rules. This is an application-specific field and allows a consumer of the Protection Content type JUMBF box to decide on whether an entity is authorized to access the protected resource based on a given set of policies. Provided that an actor decides to use this functionality, both the Protection Content type JUMBF box and the associated JUMBF Box with the access rules shall be included in the Assertion Store, as shown in Figure 21. This ensures the integrity and authenticity of the access rules referenced by the Protection box, as the hash and the URI reference of the respective JUMBF box are included in the Trust Manifest’s Claim box.

NOTE Different assertions can use different keys and different access rules. Alternatively, multiple protected assertions can reference a single set of access rules.

Figure 21 — Applying access rules to an Assertion

The case for protecting the media asset content arises when an actor wants to protect a privacy-related region of interest (e.g., the face of an individual). The mechanisms for protecting specific regions of interests of a media asset content and replacing this with placeholder content are thoroughly described in ISO/IEC 19566-4. Along with the protection of the media asset content, an actor shall provide a Trust Manifest to be included in the Trust Record. The entire flow is described in Figure 22. The new Trust Manifest shall have a new Ingredient Assertion linking back to the latest Trust Manifest of the unprotected media asset. The means to express such an assertion follow the ingredient assertion schema.

Figure 22 — Updating the Trust Record during the protection of a media asset content

1. 
   (normative)
   
   Serialisation of Trust Indicator Sets
   1. Use of @context

The Trust Indicator Set’s JSON-LD serialisation shall contain a JSON-LD standard @context field whose value shall be either an object or an array listing terms (also known as namespaces) that are used in the Trust Indicator Set. In the case of an object, the terms shall be listed as key-value pairs, where the key is the term name and the value is the URI of the term. As described in W3C Recommendation JSON-LD, 4.1.2, the @vocab key can be used for the default vocabulary, as shown in Figure A.1. In the case of an array, only the URI is required since it shall apply to all terms not otherwise identified by a specific term, as shown in Figure A.2.

{

  "@context": {

    "@vocab": "https://jpeg.org/jpegtrust/",

    "extras": "https://jpeg.org/jpegtrust/extras/",

  }

}

Figure A.1 — Example of an object-based JSON-LD @context field

{

  "@context": [

    "https://jpeg.org/jpegtrust/"

  ]

}

Figure A.2 — Example of an array-based JSON-LD @context field

Since a Trust Indicator Set may contain values that are specific to a given workflow, it is important that each one of these terms shall be defined in the @context field. This allows the Trust Indicator Set to be self-describing and non-conflicting ensuring that any consumer of the Trust Indicator Set can understand the meaning of each term.

Since a @context element can appear inside of any object in JSON-LD, it is possible to have custom values, and their associated @context elements in multiple places throughout a single JSON-LD document, where the terms are localized to that specific object, such as in Figure A.5.

• 1. Trust Indicator Set for media asset content

A Trust Indicator Set may contain a field named content whose value is an object containing information that represents the Trust Indicators derived from the media asset content. There are currently no pre-defined fields of the content object, but workflow-centric Trust Indicators may be added to the content object along with their associated @context. For example, Figure A.3 shows a content object that contains information about the image, such as its width and height.

"content": {

  "@context": {

    "myimg": "http://example.com/images/",

    "myalgos": "http://example.com/algorithms"

  },

  "myimg:width": 612,

  "myimg:height": 792,

  "myalgos:aigc_probability": 0.95

}

Figure A.3 — Custom content Trust Indicators

• 1. Trust Indicator Set for media asset metadata

To represent various types of media asset metadata, it is necessary to serialize the information into JSON-LD, for inclusion in the Trust Indicator Set structure. The data, if present, shall be the value of the metadata field of the Trust Indicator Set.

The JSON-LD object may also contain other properties, from other metadata schemas contained within the media asset metadata, provided that they are serialised as JSON-LD.

The @context property within the JSON-LD object shall be present, as it is required to provide context and namespaces for all used metadata schemas.

An example can be found in Figure A.4.

"metadata" : {

"@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/",

},

"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 ] }

}

Figure A.4 — Example of JSON-LD serialised XMP

NOTE The various terms and context namespaces in Figure A.4 are defined as part of other grammars such as IPTC Photo Metadata Standard and Exif.

• 1. Trust Indicator Set for Trust Manifests
     1. General

As described in 4.4, a Trust Manifest consists of, at least, a set of Assertions, Claims, and Signatures that are bound together into a single entity. If a Trust Declaration is present, its Trust Indicators shall be represented as fields of the declaration object. For any Trust Manifests present, there shall be an array whose value consists of zero or more objects representing the Trust Indicators from the Manifest. The order of the Manifests in the array shall match the order that they are found in the Manifest Store.

NOTE 1 This ensures that the expression manifest[0], when used in a Trust Profile, will reference the active manifest.

Each manifest object shall contain a field named label, whose value is a string that identifies the Trust Manifest using the label of its JUMBF box, such as urn:c2pa:2702fc84-a1ae-44d1-9825-dd86311e980b. Additional fields of the manifest object shall consist of Trust Indicators derived from the Trust Manifest.

It is possible to produce a Trust Indicator Set for a media asset that contains neither a Trust Declaration nor any Trust Manifests. In such a case, the Trust Indicator Set shall not contain a declaration object, and the manifests array shall be empty.

NOTE 2 This is a valid state and the lack of a Trust Declaration or any Trust Manifests serves as a valid Trust Indicator.

• • 1. Assertions
       1. General

Each manifest object shall contain an assertions field whose value is an array of objects, each of which represents a single Assertion in the Trust Manifest’s assertion store. Each assertion shall be represented as a key-value pair in a corresponding object within the assertions array. The key is the label of the Assertion and the value is an object containing the Trust Indicators derived from that Assertion. If it is not possible to derive any Trust Indicators from an assertion, then the key shall be present in the assertions object, but its value shall be an empty object.

• • • 1. JSON-LD serialised assertions

For any Assertion which is serialised into JSON-LD that will be incorporated into the Trust Indicator Set, the Trust Indicator shall be described using the same JSON-LD object. As both the CAWG Metadata Assertion and the C2PA Technical Specification c2pa.metadata assertion are expressed in XMP(ISO 16684-1), that XMP data shall be serialised according to the rules of the JSON-LD serialization of XMP.

An example cawg.metadata assertion (CAWG Metadata Assertion) is shown in Figure A.5.

"cawg.metadata": {

  "@context" : {

    "Iptc4xmpExt": "http://iptc.org/std/Iptc4xmpExt/2008-02-29/",

    "dc" : "https://purl.org/dc/elements/1.1/",

    "photoshop" : "http://ns.adobe.com/photoshop/1.0/"

  },

  "photoshop:DateCreated": "Aug 31, 2022",

  "dc:creator": [ "Julie Smith" ],

  "Iptc4xmpExt:LocationCreated": {

    "Iptc4xmpExt:City": "Beijing, China"

  }

}

Figure A.5 — A JSON-LD serialised assertion

NOTE The various terms and context namespaces in Figure A.5 are defined as part of IPTC Photo Metadata Standard.

• • • 1. CBOR serialised assertions

For each Assertion, which is serialised into CBOR, that will be incorporated into the Trust Indicator Set, the Trust Indicator shall be described as the same key name in the CBOR map and its value type shall be determined by Table A.1:

Table A.1 — Mapping from CBOR to JSON-LD

Since CBOR allows map keys of any type, whereas JSON-LD only allows strings as keys in object values, CBOR maps with keys other than UTF-8 strings shall have those keys converted to UTF-8 strings. An example of a CBOR serialised assertion is shown in Figure A.6, and its equivalent JSON-LD representation is shown in Figure A.7.

"c2pa.actions.v2": {

  "actions": [

    {

      "action": "c2pa.cropped",

      "when": 0("2020-02-11T09:30:00Z")

    },

    {

      "action": "c2pa.filtered",

      "when": 0("2020-02-11T09:00:00Z")

    }

  ]

}

Figure A.6 — CBOR Diagnostics for an actions.v2 assertion

"c2pa.actions.v2": {

  "actions": [

    {

      "action": "c2pa.cropped",

      "when": "2020-02-11T09:30:00Z"

    },

    {

      "action": "c2pa.filtered",

      "when": "2020-02-11T09:00:00Z"

    }

  ]

}

Figure A.7 — JSON-LD representation of Figure A.6

• • 1. Claim

A Claim shall be serialised in the same manner as a CBOR serialised assertion. It shall be named based on the label of the claim box (e.g., claim or claim.v2). An example is found in Figure A.8.

If there are no assertions listed in the claim’s gathered_assertions or redacted_assertions fields, then the corresponding object shall be present, but its value shall be an empty object.

"claim.v2": {

  "dc:title": "MIPAMS test image",

  "instanceID": "uuid:7b57930e-2f23-47fc-affe-0400d70b738d",

  "claim_generator": "MIPAMS GENERATOR 0.1",

  "alg": "SHA-256",

  "signature": "self#jumbf=c2pa.signature",

  "created_assertions": [

    {

      "url": "self#jumbf=c2pa.assertions/c2pa.actions.v2",

      "hash": "APqpWkPm91k98DD03sIQ+uYGspG+bxdy0c7+FMu8puU="

    },

    {

      "url": "self#jumbf=c2pa.assertions/c2pa.hash.data",

      "hash": "A8wNdhjiIyOOkGg8+GkJRSYJALG6orPQJRQKMFtq/rc="

    }

  ],

  "gathered_assertions": [],

  "redacted_assertions": []

},

Figure A.8 — A JSON-LD serialised claim

• • 1. Claim signature

The JSON-LD representation of the X.509 certificate (as defined in IETF RFC 5280) from the claim signature is based on a logical mapping of its ASN.1 serialisation as defined in IETF RFC 5280 into a JSON-LD serialized object whose key is claim_signature. An example certificate is in Figure A.9. Additional mappings, such as the mapping of the distinguished name (IETF RFC 4514) to JSON-LD should also be done in the most logical fashion possible.

NOTE An X.509 certificate can contain all sorts of information, but only the information that is relevant to the trust framework is included in the JSON-LD representation.

The value of the signature_algorithm field shall be one of the strings defined in C2PA Technical Specification, 13.2.1, such as “ES256” or “Ed25519”, or “Unknown” if it is not one of the defined values.

"claimSignature": {

  "signature_algorithm": "ES256",

  "subject": {

    "ST": "CA",

    "CN": "C2PA Signer",

    "C": "US",

    "L": "Somewhere",

    "OU": "FOR TESTING_ONLY",

    "O": "C2PA Test Signing Cert"

  },

  "issuer": {

    "ST": "CA",

    "CN": "Intermediate CA",

    "C": "US",

    "L": "Somewhere",

    "OU": "FOR TESTING_ONLY",

    "O": "C2PA Test Intermediate Root CA"

  },

  "validity": {

    "not_after": "2030-08-26T18:46:40Z",

    "not_before": "2022-06-10T18:46:40Z"

  }

}

Figure A.9 — Representation of an X.509 Certificate

An example of Trust Profile showing how to test some of these values can be found in B.4.4.

• • 1. Status

The manifest object shall contain a status field whose value is an object containing the status of the various parts of the Trust Manifest. The status object shall contain the following fields:

For the active Trust Manifest, the following additional fields shall also be present:

NOTE This is present only in the active Trust Manifest, since that is the only one that can be used to check the validity of the content bindings. This applies to both standard and update Trust Manifests.

An example of a status object is shown in Figure A.10.

"status": {

  "signature": "claimSignature.validated",

  "assertion": {

    "c2pa.actions.v2": "assertion.hashedURI.match",

    "c2pa.hash.data": "assertion.dataHash.match"

  },

  "content": "assertion.dataHash.match",

  "trust": "signingCredential.trusted",

  "trust_list": "https://example.com/trustlists/c2pa-trust-list.json"

}

Figure A.10 — Example status object

• 1. Asset Identification

In order to provide information about the asset itself that could be included by a Trust Profile in a Trust Report, the Trust Indicator Set should contain a field named asset_info. The value of this field shall be an object containing at least the following two fields hash, and alg that are consistent with a hashed URI (C2PA Technical Specification, 8.4.2). The value of the hash field shall be the result of the hash, encoded into Base64. The url field is optional, but recommended. An example is shown in Figure A.11.

NOTE Since the url field is a URI, it is possible to use a file URI to point to a local file. However, doing so can potentially expose personally identifiable information (PII) about the user, such as their username and file path.

"asset_info": {

  "url": "file://Users/janedoe/Desktop/12345.jpg",

  "hash": "BASE64_ENCODED_HASH_HERE",

  "alg": "sha256"

}

Figure A.11 — Example asset information

• 1. Example Trust Indicator Sets

This clause contains a series of example Trust Indicator Sets to illustrate how Trust Indicator Set can be constructed for different types of media assets.

• • 1. Camera

An example Trust Indicator Set for a JPEG image from a camera could look like Figure A.12:

{

  "@context": [

    "https://jpeg.org/jpegtrust/"

  ],

  "declaration": {

    "claim.v2": {

      "alg": "sha256",

      "claim_generator_info": [

        {

          "name": "Joe's Camera App"

        }

      ],

      "signature": "self#jumbf=c2pa/urn:c2pa:e8ea7712-2bc8-4ca0-848d-67b19434913f/c2pa.signature",

      "dc:format": "image/jpeg",

      "signature_status": "claimSignature.validated",

      "assertion_status": {

        "c2pa.hash.data": "assertion.hashedURI.match",

        "c2pa.actions": "assertion.hashedURI.match"

      }

    },

    "assertions": {

      "c2pa.hash.data": {

        "alg": "sha256",

        "pad": "",

        "hash": "Auxjtmax46cC2N3Y9aFmBO9Jfay8LEwJWzBUtZ0sUM8gA=",

        "name": "JUMBF manifest",

        "exclusions": [

          {

            "start": 9960,

            "length": 4213

          }

        ]

      },

      "c2pa.actions.v2": {

        "actions": [

          {

            "action": "c2pa.created",

            "when": "2023-02-11T09:00:00Z",

            "softwareAgent": {

              "name": "Joe's Camera App"

            },

            "digitalSourceType": "https://cv.iptc.org/newscodes/digitalsourcetype/digitalCapture"

          }

        ]

      }

    }

  },

  "manifests": [

    {

      "claim.v2": {

        "alg": "sha256",

        "claim_generator_info": [

          {

            "name": "Joe's Camera App"

          }

        ],

        "signature": "self#jumbf=c2pa/urn:c2pa:e8ea7712-2bc8-4ca0-848d-67b19434913f/c2pa.signature",

        "dc:format": "image/jpeg",

        "signature_status": "claimSignature.validated",

        "assertion_status": {

          "cawg.metadata": "assertion.hashedURI.match",

          "c2pa.hash.data": "assertion.hashedURI.match"

        },

        "content_status": "assertion.dataHash.match"

      },

      "assertions": {

        "cawg.metadata": {

          "@context": {

            "dc": "https://purl.org/dc/elements/1.1/",

            "exif": "http://ns.adobe.com/exif/1.0/",

            "Iptc4xmpExt": "http://iptc.org/std/Iptc4xmpExt/2008-02-29/"

          },

          "exif:GPSVersionID": "2.2.0.0",

          "exif:GPSLatitude": "39.918522630419034",

          "exif:GPSLongitude": "116.39726729279847",

          "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,

          "photoshop:DateCreated": "Aug 31, 2022",

          "dc:creator": [

            "Julie Smith"

          ],

          "Iptc4xmpExt:LocationCreated": {

            "Iptc4xmpExt:City": "Beijing, China"

          }

        }

      }

    }

  ],

  "content": {}

}

Figure A.12 — Example Trust Indicator Set from a Camera

• • 1. Generative AI

An example Trust Indicator Set for a JPEG image created by a generative AI could look like Figure A.13:

{

  "@context": [

    "https://jpeg.org/jpegtrust/"

  ],

  "declaration": {

    "claim.v2": {

      "alg": "sha256",

      "claim_generator": "Joe's Photo Editor/2.0 (Windows 10)",

      "claim_generator_info": [

        {

          "name": "Joe's Photo Editor",

          "version": "2.0",

          "schema.org.SoftwareApplication.operatingSystem": "Windows 10"

        }

      ],

      "signature": "self#jumbf=c2pa/urn:c2pa:5560f310-addc-4823-bce7-619e070fafa9/c2pa.signature",

      "dc:format": "image/png",

      "signature_status": "claimSignature.validated",

      "assertion_status": {

        "c2pa.hash.data": "assertion.hashedURI.match",

        "c2pa.actions.v2": "assertion.hashedURI.match"

      },

      "content_status": "assertion.dataHash.match"

    },

    "assertions": {

      "c2pa.hash.data": {

        "alg": "sha256",

        "pad": "",

        "hash": "Auxjtmax46cC2N3Y9aFmBO9Jfay8LEwJWzBUtZ0sUM8gA=",

        "name": "JUMBF manifest",

        "exclusions": [

          {

            "start": 9960,

            "length": 4213

          }

        ]

      },

      "c2pa.actions.v2": {

        "actions": [

          {

            "action": "c2pa.created",

            "when": "2023-02-11T09:00:00Z",

            "softwareAgent": {

              "name": "Joe's Photo Editor",

              "version": "2.0",

              "schema.org.SoftwareApplication.operatingSystem": "Windows 10"

            },

            "digitalSourceType": "https://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia"

          }

        ]

      }

    }

  },

  "content": {}

}

Figure A.13 — Example Trust Indicator Set from a Generative AI

• • 1. No Trust Manifests

An example Trust Indicator Set for a JPEG image without any Trust Manifests could look like Figure A.14:

{

"@context": [

"https://jpeg.org/jpegtrust/"

],

"asset_info": {

"alg": "sha256",

"hash": "na6lb3F/uIdiAhZtZp4Oa2aNCj1UvcHVxx/p5ISE2AA="

},

"content": {},

"manifests": []

}

Figure A.14 — Example Trust Indicator Set without any Trust Manifests

1. 
   (normative)
   
   Serialisation of Trust Profiles
   1. Introduction
      1. General

A Trust Profile shall be expressed as a series of YAML documents, where the first document shall be the Clause B.2 that contains metadata about the Trust Profile, and any subsequent documents contain a series of Clause B.3 that define the expressions to be evaluated against a set of Trust Indicators. Each statement contains information that will be output into the associated Trust Report, such as a description of the statement, the expression to be evaluated, and the text to be included in the report.

NOTE A YAML document is a section of a YAML file that is separated from the next section by a YAML document separator, which is a line containing three dashes (---). The first document in a YAML file is the one between the first and second separators.

• • 1. Expressions

Expressions are strings of json-formula, an expression grammar that operates on JSON documents. In the context of Trust Profiles, expressions are used to evaluate a Trust Indicator Set. As such, they take one or more Trust Indicators as an input and produce a single value as an output. The output value can be binary, numeric (floating point), textual (string), or a URI reference which can be internal (JUMBF reference) or external (URL).

For example, the simple expression declaration.claim.content_status == "assertion.dataHash.match" could be used to determine if the content status of a declaration matches the expected value of assertion.dataHash.match. The output of this expression would be a boolean value indicating whether the condition is true or false.

• • 1. Multilingual text

When a field is expressed in multiple languages, these multilingual fields use a mapping with IETF BCP 47 language tags as key and the text in the corresponding language as value as in Figure B.1. These types are indicated as ML Dict.

field_name:

  en: Text in English.

  es: Text in Spanish.

  fr: Text in French.

Figure B.1 — Example of multilingual fields

• 1. Information block

The Trust Profile information block is a YAML mapping that provides additional information about the specific Trust Profile. It shall contain at least one mapping with the key metadata that contains metadata about the Trust Profile, but may also contain additional mappings that provide further context or configuration for the Trust Profile. Additional mappings may either be defined by this document or may be custom to a specific use case.

All of the mappings present in the information block are made available to the expressions in the Trust Profile. For example, it is possible to use the metadata in expressions to provide context for the evaluation of the Trust Indicators, as shown in Figure B.2.

This media asset is compliant with '({{metadata.name}}, {{metadata.version}})'.

Figure B.2 — Example of using metadata in expressions

• • 1. Profile metadata

The metadata mapping contains key-value pairs that provide essential information about the Trust Profile, such as its name and date of issue, which is used to identify the Trust Profile and provide context for the statements it contains. The key for the mapping shall be metadata and it shall only contain the keys listed in Table B.1, some of which are mandatory and therefore shall always be present.

This information is copied into the associated Trust Report in a section called “profile_metadata”, which is the first section in the report. The metadata is also available to expressions and usable as a template value as metadata.

Table B.1 — Trust Profile metadata

• • 1. Globals
       1. General

In order to provide a common context for the evaluation of the expressions in the Trust Profile, the information block may contain a variables mapping as well as an expressions mapping.

• • • 1. Variables

The variables mapping contains key-value pairs that define variables that can be used in the expressions in the Trust Profile. The keys for these variables shall all begin with a $ and be unique within the Trust Profile. The values of the variables can be any valid JSON value, including strings, numbers, booleans, arrays, and objects. Some examples of variables are shown in Figure B.3.

variables:

"$creation_date": "2023-10-01T12:00:00Z"

"$creator": "John Doe"

"$days": [ "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday" ]

Figure B.3 — Example of variables in the Trust Profile

• • • 1. Expressions

The expressions mapping contains key-value pairs that define expressions that can be used in the Trust Profile. The keys for these expressions shall all begin with a _ and be unique within the Trust Profile. The values of the expressions are strings that follow the json-formula grammar. Some examples of expressions are shown in Figure B.4.

expressions:

_isUnmodified: '@.declaration.claim.content_status == "assertion.dataHash.match"'

_isAIGC: contains(@.declaration.assertions.'c2pa.actions'.actions[0].digitalSourceType, "trainedAlgorithmicMedia")

_dateOfWeek: "value($days, weekday(now(), 3))"

Figure B.4 — Example of expressions in the Trust Profile

• • 1. Custom information

Additional mappings may be added to the information block to provide further context or configuration for the Trust Profile or to provide values for use in expressions. These mappings are not defined by this document and may vary depending on the use case. The keys for these mappings shall be unique within the Trust Profile, and use appropriate namespacing syntax. Some examples of custom information are shown in Figure B.5.

"foo:info":

  description: This is a sample camera profile for testing purposes

  magic_number:  1234567890

Figure B.5 — Example of custom information in the Trust Profile

• 1. Statements
     1. General

Following the information block document is one or more documents known as a statement section (or just section for short). Each section contains a list of statements, where each statement is represented as mappings with predefined fields.

There are two types of statements that can be present, in any order or combination, in a section: information statements and expression statements. Information statements are used to provide additional context or information about the section, while expression statements are used to evaluate expressions against the Trust Indicator Set. Both types of statements provide a way to include human-readable report text that will be included in the associated Trust Report.

• • 1. Statement identifiers
       1. General

One of the fields that shall be present in all statements is the statement identifier (id). It shall have a value which can be any valid JSON identifier. If the identifier begins with the prefix jpt., then it represents one of the predefined identifiers described in B.3.2.2.

The identifier shall be unique within the Trust Profile, as it can be use in an expression to refer to the result of the evaluation of the statement. Figure B.6 shows an example of how to use the identifier in an expression.

expression: @.profile.aigc && @.profile.declaration_only

Figure B.6 — Example of using a statement identifier in an expression

• • • 1. Predefined statement IDs

This document defines some reserved statement identifiers that are used to signal that an expression statement is serving a particular purpose. Table B.2 gives an overview of these predefined IDs and a description of their purpose.

Table B.2 — Predefined statement IDs

• • 1. Templates

The text in the report that is generated by a statement, as specified in the report_text field of a statement, can contain template values that are replaced with the actual values when the Trust Report is generated. The template values are enclosed in double curly braces ({{ and }}) and can refer to the output value of the statement, the metadata of the Trust Profile, or other variables defined in the Trust Profile. For example, {{id}} refers to the result of an expression statement with that id, and {{metadata.name}} refers to the name field of the metadata mapping from the information block.

• • 1. Information statements

An information statement is used to provide some explicit text at a specific point in the report, without the need to evaluate any expression. The most common use for one is to provide a title and description of each section, which is why there should be an information statement as the first statement in any section. Table B.3 gives an overview of the structure of an information statements.

Table B.3 — Structure of information statements

• • 1. Expression statements

An expression statement is used to evaluate an expression against the Trust Indicator Set and produce a value that can be included in the associated Trust Report. Each expression statement shall have an identifier (id), an expression to be evaluated, and the text to be included in the report. The output value of the expression shall also be included in the Trust Report, and also recorded back into the Trust Indicator Set as a new Trust Indicator with the same identifier as the statement, as part of the profile section of the Trust Indicator Set. For example, if the identifier of the expression statement is isAIGC, then the output value of the expression can be referenced in a future expression via @.profile.isAIGC.

Table B.4 gives an overview of the structure of expression statements.

Table B.4 — Structure of expression statements

• 1. Example Trust Profiles

This clause contains a series of example Trust Profiles to illustrate how Trust Profiles can be constructed for different use case scenarios.

• • 1. Camera

An example Trust Profile for a JPEG image from a camera could look like Figure B.7:

# Example Trust Profile for evaluating camera_credential.json

---

metadata:

  name: Experimental Camera Profile

  issuer: JPEG Trust Committee

  date: 2025-07-05T10:20:25.844Z

  version: 2.0.0

  language: en

"foo:sample":

  description: This is a sample camera profile for testing purposes

  number: 1234567890

---

# Section 0 - Metadata Output

- id: metadata-output

  description: Section 0 - Metadata Output

  report_text: "{{foo:sample.description}} - {{foo:sample.number}}"

---

# Section 1

- id: generalInfo

  description: Section 1 - General Information

  title: General Information

  report_text: This section provides information about general stuff

- # check for content modification

  # description provides additional context that does not go into the report

  id: content

  description: content is unmodified

  expression: >

    manifests[0].'claim.v2'.content_status == "assertion.dataHash.match"

  report_text:

    "true":

      en: This content has not been modified

      es: Translation in Spanish

      zh: Translation in Simplified Chinese

    "false":

      en: This content has been modified

- # See if the asset has been modified after creation

  id: declaration_only

  description: is there a declaration and no manifests present?

  expression: contains(keys(@), "declaration") && !contains(keys(@), "manifest")

  report_text:

    "true":

      en: No modifications took place after it was created

    "false":

      en: This media asset was modified after creation, but with full provenance

---

# Section 2 - GPS & Location information

- id: location

  description: Section 2 - GPS & Location information

  title: Location Information

  report_text: This section provides information about where the image was taken

- # check the GPS location

  id: gps

  description: GPS location approximate to China's

  expression: >

    (manifests[0].assertions.'cawg.metadata'.'exif:GPSLatitude' > 20) &&

      (manifests[0].assertions.'cawg.metadata'.'exif:GPSLatitude' < 50) &&

      (manifests[0].assertions.'cawg.metadata'.'exif:GPSLongitude' > 80) &&

      (manifests[0].assertions.'cawg.metadata'.'exif:GPSLongitude' < 120)

  report_text:

    "true":

      en: The GPS information shows that the image was taken inside of China

      fr: Translation in French

      zh: Translation in Simplified Chinese

    "false":

      en: The GPS information shows that the image was taken outside of China

- # check the human entered value for the city

  id: city

  description: name of the city contains "China"

  expression: >

    contains(manifests[0].assertions.'cawg.metadata'

                                    .'Iptc4xmpExt:LocationCreated'

                                    .'Iptc4xmpExt:City'

            , "China")

  report_text:

    "true":

      en: The city is in China

      fr: Translation in French

      zh: Translation in Simplified Chinese

      jp: Translation in Japanese

    "false":

      en: The city is not in China

Figure B.7 — Example Trust Profile for a camera

• • 1. Generative AI

An example Trust Profile for a JPEG image created by generative AI could look like Figure B.8:

# Example Trust Profile for evaluating genai_credential.json

---

metadata:

  name: Experimental Generative AI Profile

  issuer: JPEG Trust Committee

  date: 2023-10-31T00:16:40.346Z

  version: 2.0.0

  language: en

---

# Section 1

- id: generalInfo

  description: Section 1 - General Information

  title: General Information

  report_text: This section provides information about general stuff

- # check for content modification

  # description provides additional context that does not go into the report

  id: content

  description: content is unmodified

  expression: >

    declaration.'claim.v2'.content_status == "assertion.dataHash.match"

  report_text:

    "true":

      en: This content has not been modified

      es: Translation in Spanish

      zh: Translation in Simplified Chinese

    "false":

      en: This content has been modified

---

# Section 2 - Is produced by Generative AI (AIGC)?

- id: genAI

  description: Section 2 - Is Generative AI?

  title: Generative AI Usage

  report_text: This section provides information about whether or not the media asset was produced by generative AI.

- # Is Generative AI?

  # Checks for 'trainedAlgorithmicMedia' which includes both regular and composited flavors.

  id: aigc

  description: Is AIGC?

  expression: >

    contains(declaration.assertions.'c2pa.actions.v2'.actions[0].digitalSourceType,

              "trainedAlgorithmicMedia")

  report_text:

    "true":

      en: This media asset was produced by generative AI

      de: Translation in German

      zh: Translation in Simplified Chinese

    "false":

      en: This media asset was not produced by generative AI

- # See if the asset has been modified after creation

  id: declaration_only

  description: is there a declaration and no manifests present?

  expression: contains(keys(@), "declaration") && !contains(keys(@), "manifest")

  report_text:

    "true":

      en: No modifications took place after it was created

    "false":

      en: This media asset was modified after creation, but with full provenance

---

# Section 3 - Compliance

- id: compliance

  description: Section 3 - Compliance

  title: Compliance

  report_text: This section provides the compliance status of the media asset with respect to this profile.

- # check compliance

  id: jpt:profile_compliance

  description: is the asset compliant with this profile?

  expression: >

    @.profile.aigc && @.profile.declaration_only

  report_text:

    "true":

      en: "Compliance Status: {{profile.jpt:profile_compliance}}"

    "false":

      en: This media asset is not compliant with this profile.

Figure B.8 — Example Trust Profile for generative AI

• • 1. No manifests

An example Trust Profile for a JPEG image without any Trust Manifests could look like Figure B.9:

# Example Trust Profile for evaluating no_manifests_credential.json

---

metadata:

  name: Experimental No Manifests Profile

  issuer: JPEG Trust Committee

  date: 2023-11-02T01:03:16.443Z

  version: 2.0.0

  language: en

---

# Section 1

- id: generalInfo

  description: Section 1 - General Information

  title: General Information

  report_text: This section provides information about general stuff

- # check for manifests

  id: manifests

  description: does the asset contain any manifests

  expression: hasProperty(@, "manifest") || hasProperty(@, "declaration")

  report_text:

    "true":

      en: This media asset has one or more Trust Manifests

      de: Translation in German

      zh: Translation in Simplified Chinese

    "false":

      en: No Trust Manifests found in this media asset

- # check compliance

  id: jpt:profile_compliance

  description: is the asset compliant with this profile?

  expression: >

    @.profile.manifests

  report_text:

    "true":

      en: This media asset is compliant with this profile.

    "false":

      en: This media asset is not compliant with this profile.

Figure B.9 — Example Trust Profile without any Trust Manifests

• • 1. Certificate validation

An example Trust Profile for checking the information about the X.509 certificate (as defined in IETF RFC 5280) from the Claim Signature could look like Figure B.10:

# Example Trust Profile for evaluating no_manifests_credential.json

---

metadata:

  name: Experimental Signature Validation Profile

  issuer: JPEG Trust Committee

  date: 2023-09-28T13:19:36.705Z

  version: 2.0.0

  language: en

---

# Section 1

- id: section1

  description: Section 1 - Date checks

  title: Validity checking based on dates

  report_text: This section checks the validity dates

- # check for `not_before`

  id: not_before

  description: check the current date is after `not_before`

  expression: toDate(manifests[0].signature.validity.not_before) < now()

  report_text:

    "true":

      en: The `not_before` date is prior to right now

      fr: Translation in French

      zh: Translation in Simplified Chinese

    "false":

      en: The certificate is not yet valid

- # check for `not_after`

  id: not_after

  description: check the current date is before `not_after`

  expression: toDate(manifests[0].signature.validity.not_after) > now()

  report_text:

    "true":

      en: The `not_after` date is after right now

    "false":

      en: The certificate is no longer valid

      fr: Translation in French

      zh: Translation in Simplified Chinese

---

# Section 2

- id: section2

  description: Section 2 - Check the CA/issuer

  title: Make sure the issuer is on our Trust List

  report_text: This section checks for valid issuers

- # check the issuer against a known TEST cert

  id: test_cert

  description: see if this was signed by a test certificate

  expression: >

    manifests[0].signature.issuer.OU="FOR TESTING_ONLY" ||

    manifests[0].signature.issuer.O="C2PA Test Intermediate Root CA"

  report_text:

    "true":

      en: The issuer is a test certificate

      fr: Translation in French

      zh: Translation in Simplified Chinese

    "false":

      en: The issuer is not trusted

- # check the issuer against known ones

  id: issuer

  description: see if the issuer is on our trust list

  expression: >

    (manifests[0].signature.issuer.CN="Alice's Trust Services" && manifests[0].signature.issuer.C="US")

    || (manifests[0].signature.issuer.CN="ЦСК НБУ" && manifests[0].signature.issuer.C="UA")

  report_text:

    "true":

      en: The issuer ({{expr "manifests[0].signature.issuer.CN"}}) is trusted

      fr: Translation in French

      zh: Translation in Simplified Chinese

    "false":

      en: The issuer ({{expr "manifests[0].signature.issuer.CN"}}) is not trusted

---

# Section 3 - Compliance

- # check compliance

  id: jpt:profile_compliance

  description: is the asset signed with a trusted certificate?

  expression: >

    profile.not_before && profile.not_after &&

    !profile.test_cert && profile.issuer

  report_text:

    "true":

      en: This media asset is signed with a trusted certificate.

    "false":

      en: This media asset is not signed with a trusted certificate.

Figure B.10 — Example Trust Profile for an X.509 certificate

1. 
   (normative)
   
   Serialisation of Trust Reports
   1. Introduction

This annex defines the serialisation of Trust Reports, which are the result of evaluating a specific Trust Indicator Set against a specific Trust Profile. The Trust Report is a structured document that contains the results of the evaluation, based on the provided report_text values from the Trust Profile.

The Trust Report is intended to be used as a means of conveying the results of the evaluation in a machine-readable format, allowing for further processing or analysis. It may also be used as the data source for visualisations or other representations (e.g., a PDF) of the trust evaluation results.

• 1. Structure of Trust Reports
     1. Serialisation

A Trust Report should be represented as a single YAML document, of the form of a mapping (also known as a dictionary or key/value pairs). It is also possible to represent the Trust Report as a JSON document or any other serialisation format that can represent the same structure.

• • 1. Metadata

As described in B.2.1, the Trust Report shall contain the key “profile_metadata”, which is a mapping that contains the metadata of the Trust Profile used to generate the report. This metadata includes information such as the name, version, and date of the Trust Profile, as shown in Figure C.1.

profile_metadata:

  name: Generative AI Profile

  issuer: JPEG Trust Committee

  date: 2023-10-31T00:16:40.346Z

  version: 1.0.0

  language: en

Figure C.1

• • 1. Sections

A Trust Report shall contain the key sections, which is an array of arrays, where each array represents a section (or document) of the Trust Profile YAML. Each section is an array of mappings, where each mapping represents a statement in the section, as defined in Table C.1.

Table C.1 — Structure of Trust Report statements

• 1. Example Trust Reports

This clause contains a series of example Trust Reports.

• • 1. Camera

An example Trust Report, which is the result of processing the example Trust Indicator Set for the JPEG image from a camera, using the example Trust Profile could look like Figure C.2:

profile_metadata:

  name: Experimental Camera Profile

  issuer: JPEG Trust Committee

  date: 2025-07-05T10:20:25.844Z

  version: 2.0.0

  language: en

sections:

  - - id: metadata-output

      report_text: This is a sample camera profile for testing purposes - 1234567890

  - - id: generalInfo

      title: General Information

      report_text: This section provides information about general stuff

    - id: content

      value: true

      report_text: This content has not been modified

    - id: declaration_only

      value: true

      report_text: No modifications took place after it was created

  - - id: location

      title: Location Information

      report_text: This section provides information about where the image was taken

    - id: gps

      value: true

      report_text: The GPS information shows that the image was taken inside of China

    - id: city

      value: true

      report_text: The city is in China

Figure C.2 — Example Trust Report for a camera

• • 1. Generative AI

An example Trust Report, which is the result of processing the example Trust Indicator Set for the JPEG image created by generative AI, using the example Trust Profile could look like Figure C.3:

profile_metadata:

  name: Experimental Generative AI Profile

  issuer: JPEG Trust Committee

  date: 2023-10-31T00:16:40.346Z

  version: 2.0.0

  language: en

sections:

  - - id: generalInfo

      title: General Information

      report_text: This section provides information about general stuff

    - id: content

      value: true

      report_text: This content has not been modified

  - - id: genAI

      title: Generative AI Usage

      report_text: This section provides information about whether or not the media

        asset was produced by generative AI.

    - id: aigc

      value: true

      report_text: This media asset was produced by generative AI

    - id: declaration_only

      value: true

      report_text: No modifications took place after it was created

  - - id: compliance

      title: Compliance

      report_text: This section provides the compliance status of the media asset with

        respect to this profile.

    - id: jpt:profile_compliance

      value: true

      report_text: "Compliance Status: true"

Figure C.3 — Example Trust Report for generative AI

• • 1. No manifests

An example Trust Report, which is the result of processing the example Trust Indicator Set for the JPEG image without any Trust Manifests, using the example Trust Profile could look like Figure C.4:

profile_metadata:

  name: Experimental No Manifests Profile

  issuer: JPEG Trust Committee

  date: 2023-11-02T01:03:16.443Z

  version: 2.0.0

  language: en

sections:

  - - id: generalInfo

      title: General Information

      report_text: This section provides information about general stuff

    - id: manifests

      value: false

      report_text: No Trust Manifests found in this media asset

    - id: jpt:profile_compliance

      value: false

      report_text: This media asset is not compliant with this profile.

Figure C.4 — Example Trust Report without any Trust Manifests

• • 1. Predefined statement IDs

An example Trust Report, to illustrate the usage of Predefined statement IDs:

profile_metadata:

  name: Associated Trust Report

  issuer: JPEG Trust Committee

  date: 2025-06-26T21:00:46.638Z

  version: 2.0.0

  language: en

sections:

# Section info

- - id: section1

    title: Example section title

    report_text: This is an example of a section description.

# Predefined 'jpt.profile_summary' statement ID, this is a reserved ID that can (optionally) be used to add a summary of the profile result.

  -

    id: jpt.profile_summary

    report_text: "This media asset is considered trustworthy according to this profile."

    value: "This media asset is considered trustworthy according to this profile."

# Predefined 'jpt.profile_compliance' statement ID, this is a reserved ID that can (optionally) be used to signal the result of an overall binary profile compliance test.

  -

    id: jpt.profile_compliance

    report_text: This media asset passed the compliance test of this profile.

    value: True

# Predefined 'jpt.profile_score' statement ID, this is a reserved ID that can (optionally) be used to signal the result of an overall binary profile compliance test.

  -

    id: jpt.profile_score

    report_text: This media asset scored a 0.8 compliance score according to this profile.

    value: 0.8

# Predefined 'jpt.profile_label' statement ID, this is a reserved ID that can (optionally) be used to assign a single label to the asset.

  -

    id: jpt.profile_label

    report_text: "This media asset is labeled as: Label."

    value: Label

# Example of a multilingual statement

  -

    id: example.multilingual

    report_text:

      en: Example of a multilingual statement.

      es: Ejemplo de una declaración multilingüe.

      fr: Exemple d’une déclaration multilingue.

      nl: Voorbeeld van een meertalig statement.

    value: null

Figure C.5 — Example Trust Report with predefined statement IDs

1. 
   (informative)
   
   Using Dublin Core metadata with JPEG Trust
   1. Introduction

As described in ISO 15836-1, the Dublin Core Metadata Element Set is a general-purpose metadata vocabulary for describing media assets of any type. It consists of 15 metadata elements for cross-domain resource description. Designed with minimal constraints, each element is optional and may be repeated to completely attribute authorship.

NOTE These elements are part of a larger set of metadata vocabularies maintained by the Dublin Core Metadata Initiative. Any Dublin Core metadata element (or term) can be used, not just the core elements.

• 1. List of Dublin Core core elements

Table D.1 lists each Dublin Core core element and its description.

Table D.1 — Dublin Core core elements

• 1. Using Dublin Core with JPEG Trust
     1. Use of the CAWG metadata assertion

A CAWG metadata assertion (as described in CAWG Metadata Assertion) is used to store the majority of the Dublin Core element set as part of a Trust Record, as shown in Figure D.4. The one exception is dc:format which is represented in the claim portion of the Trust Record, as described in C2PA Technical Specification, Clause 10.

As the Dublin Core terms includes information about actors (e.g., the creator or contributors), it is recommended that a CAWG identity assertion (as described in CAWG Identity Assertion) be used to assert the identity of these actors. These identity assertions could be referenced in the CAWG metadata assertion using JUMBF URIs (as described in ISO/IEC 19566-5:2023, Annex C), and it is recommended that the CAWG identity assertion reference the CAWG metadata assertion in the list of referenced_assertions in its signer_payload. Figure D.1 shows fragment of a CAWG metadata assertion that references a CAWG identity assertion.

{

"dc:creator" : "self#jumbf=c2pa.assertions/cawg.identity",

"dc:publisher" : "self#jumbf=c2pa.assertions/cawg.identity_1",

}

Figure D.1 — Example of a CAWG metadata assertion referencing a CAWG identity assertion

In a similar manner, a CAWG metadata assertion could reference a rights expression assertion from the dc:rights field using a JUMBF URI. Figure D.2 shows a fragment of a CAWG metadata assertion that references a rights expression assertion.

{

"dc:rights" : "self#jumbf=c2pa.assertions/jpt.rights",

}

Figure D.2 — Example of a CAWG metadata assertion referencing a rights expression assertion

• • 1. Example CAWG metadata assertion

The following example illustrates how the Dublin Core terms can be used represented in a CAWG metadata assertion. Figure D.3 is an image of French President Emmanuel Macron delivering his New Year wishes during an address to the nation from the Elysee Palace, in Paris, on December 31, 2020, and the corresponding Figure D.4 represents its information in a CAWG metadata assertion.

Figure D.3 — Emmanuel Macron, © STEPHANE DE SAKUTIN, AFP, with the kind permission of Agence France-Presse

{

   "@context" : {

   "dc" : "https://purl.org/dc/elements/1.1/",

   },

   "dc:creator" : ["Stéphane de Sakutin", "self#jumbf=c2pa.assertions/cawg.identity"],

   "dc:identifier" : "AFP_8XZ4ZA",

   "dc:title" : "Address to the nation",

   "dc:subject" : ["France","Politics","New Year"],

   "dc:description" : "This photograph shows a television screen broadcasting French President Emmanuel Macron delivering his New Year wishes during an address to the nation from the Elysee Palace, in Paris, on December 31, 2020.",

   "dc:publisher" : "https://u.afp.com/5t5x",

   "dc:contributor" : ["Jeanne Parexemple", "self#jumbf=c2pa.assertions/cawg.identity_1"],

   "dc:date" : "2020-12-31T20:14:00Z",

   "dc:type" : "Image",

   "dc:source" : "France 2 broadcast",

   "dc:language" : "fr-FR",

   "dc:relation" :  ["AFP_8XZ4ZF","AFP_8XZ4YT"],

   "dc:coverage" :  ["Paris", "Elysée Palace"],

   "dc:rights" :  "self#jumbf=c2pa.assertions/jpt.rights"

}

Figure D.4 — Example of a CAWG metadata assertion

NOTE 1 Many of the Dublin Core terms can be expressed either as single values or as arrays of values. For example, the dc:subject and dc:relation fields in Figure D.4 show multiple values.

NOTE 2 The dc:creator and dc:contributor fields in Figure D.4 refer to authorship, and use JUMBF URIs to reference the identity assertions of the respective creators and contributors.

NOTE 3 The dc:rights field in Figure D.4 references a rights expression assertion using a JUMBF URI, though it could also point to other forms of rights declarations such as a URL to a license agreement.

1. 
   (informative)
   
   Relationship between this document (JPEG Trust) and Content Credentials
   1. Data structures and architecture

The JPEG Trust data structures are built from the same building blocks as Content Credentials; that of a series of well defined JUMBF boxes and superboxes, representing the core concepts of manifests, assertions, claims and claim signatures. Unless otherwise specified, all C2PA Technical Specification boxes and superboxes are also JPEG Trust boxes and superboxes and can be used interchangeably.

In addition, the methodology for embedding a manifest into various asset formats is also compatible with that of C2PA Technical Specification; though this document (JPEG Trust) focuses on the JPEG standards developed by ISO/IEC JTC1 SC 29/WG 1, while C2PA Technical Specification specifies additional formats, including those for audio and documents.

• 1. Cryptographic primitives

This document (JPEG Trust) utilizes the same underlying cryptographic primitives as C2PA Technical Specification, namely the use of common signature schemes and cryptographic hashes, to establish the tamper-evident nature of the information. This enables the use of common tools and libraries for the verification of the information.

• 1. Mapping of terminology

Table E.1 maps the terminology used in this document (JPEG Trust) to that of C2PA Technical Specification. If a term is not listed in the table, it is used exactly as defined in either Clause 3 or the C2PA Technical Specification‘s Glossary.

Table E.1 — Mapping of terminology between this document (JPEG Trust) and C2PA Technical Specification

• 1. Differences

JPEG Trust introduced the Trust Declaration (4.4.4), a new JUMBF box that represents a new type of Trust Manifest. This box is not part of C2PA Technical Specification, but is compatible with it.

JPEG Trust documents how to embed a trust record into additional JPEG types (6.2), including JPEG 2000. This is not part of C2PA Technical Specification, but is compatible with it.

1. 
   (informative)
   
   Threat vectors
   1. General

Establishing the authenticity of a media asset is fundamentally an issue of trust. Threat vectors refer to the different possible approaches to compromising that trust. Initial threat vectors that have been identified include:

— disassociated metadata;

— broken provenance;

— replaced provenance;

— incomplete provenance;

— inaccessible resources;

— impostor signing;

— non-reputability.

The nature of cybersecurity is ever-changing. While this annex considers and identifies mitigations to some common threats, this list of threat vectors and mitigations is indicative only and non-exhaustive.

• 1. Disassociated metadata

An application or online service may remove embedded metadata, including provenance information. This removal leads to the provenance being disassociated from the media asset.

• 1. Broken provenance

It is very common for online services and image gallery applications to re-encode images. Lossy image formats, such as JPEG 1, can change the bit-wise data stream value each time it is re-encoded. Provenance systems that only identify the content based on a cryptographic checksum will fail to identify the content if it is re-encoded.

• 1. Replaced provenance

A common metadata attack replaces authoritative metadata with metadata from another source. Systems that only evaluate the metadata may not notice that the values associated with a media asset were replaced. Provenance signatures that only cover other types of metadata can be copied without detection.

• 1. Incomplete provenance

When adding provenance to a file, the signer receives a media asset and signs it. However, the signer does not authenticate the media asset before signing. For example, a photographer captures a picture and may perform a few touch-ups before sending the picture to a signer for signing. The signer signs what was received, but this does not authenticate the original.

• 1. Inaccessible resources

The entities that digitally sign and/or register the media asset and associated provenance are not expected to be around indefinitely. At some point the media asset, media asset metadata, media asset content or its associated registration information may no longer be able to be linked to the provenance and/or validated.

• 1. Impostor signing

It is important that an actor can determine if the signer of a media asset is trustworthy. For example, if the signer is incorporated into firmware or hardware, then an actor should be able to determine if the hardware or firmware was modified prior to signing.

• 1. Non-reputability

It is important that an actor cannot deny signing something that was legitimately signed. In effect, the action cannot be allowed to deny the provenance of a picture after the fact.

• 1. Threat mitigation

Table F.1 gives an overview how the identified threat vectors are mitigated by this document.

Table F.1 — Threat Vector mitigations

1. 
   (informative)
   
   Change History

The following changes have been made to this document since the first edition:

— This document is now aligned with C2PA Technical Specification (Content Credentials), which is equivalent to the 2.1 version of the C2PA specification.

— This document now includes sections on attribution and intellectual property rights, including identity and rights assertions.

— This document now includes a section on the use of Dublin Core metadata.

— The specifications for Trust Indicators, Trust Profiles, and Trust Reports have been updated and extended to enhance robustness, reliability, and support for a broader range of workflows.

Bibliography

[1] ISO 8601‑1, Date and time — Representations for information interchange — Part 1: Basic rules

[2] ISO/IEC 10918‑4, Information technology — Digital compression and coding of continuous-tone still images — Part 4: APPn markers

[3] ISO/IEC 14496‑12, Information technology — Coding of audio-visual objects — Part 12: ISO base media file format

[4] ISO 15836‑1, Information and documentation — The Dublin Core metadata element set — Part 1: Core elements

[5] ISO 16684‑1, Graphic technology — Extensible metadata platform (XMP) — Part 1: Data model, serialization and core properties

[6] ISO 24138:2024, Information and documentation — International Standard Content Code (ISCC)

[7] Identity Assertion C.A.W.G. CAWG Identity Assertion, https://creator-assertions.github.io/identity/1.0/

[8] Metadata Assertion C.A.W.G. CAWG Metadata Assertion, https://creator-assertions.github.io/metadata/1.0/

[9] CAWG Training and Data Mining Assertion, CAWG Training and Data Mining Assertion, https://creator-assertions.github.io/training-and-data-mining/1.0/

[10] Exif, CIPA DC- 008-Translation- 2019 Exchangeable image file format for digital still cameras: Exif Version 2.32, https://www.cipa.jp/std/documents/download_e.html?DC-008-Translation-2019-E

[11] Principles F.A.I.R. FAIR Principles, https://www.go-fair.org/fair-principles/

[12] Photo Metadata Standard I.P.T.C. IPTC Photo Metadata Standard 2023.1, https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata

[13] Versioning S. Semantic Versioning 2.0.0, https://semver.org/spec/v2.0.0.html

[14] YAML. YAML Ain’t Markup Language (YAML™) Version 1.2.2, https://yaml.org/spec/1.2.2/

[15] IETF BCP 47, Best Current Practice 47. Available from: https://www.rfc-editor.org/info/bcp47.

[16] IETF RFC 4514, K. ZEILENGA. Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names. RFC Series. ^[5]

[17] IETF RFC 5280, D. COOPER, S. SANTESSON, S. FARRELL, S. BOEYEN, R. HOUSLEY and W. POLK. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC Series. ^[6]

[18] IETF RFC 8152, J. SCHAAD. CBOR Object Signing and Encryption (COSE). RFC Series. ^[7]

[19] W3C Recommendation Verifiable Credentials Data Model, Verifiable Credentials Data Model v1.1, https://www.w3.org/TR/vc-data-model/

[20] L. Zhang, L. Zhang, X. Mou and D. Zhang, “FSIM: A Feature Similarity Index for Image Quality Assessment,” in IEEE Transactions on Image Processing, vol. 20, no. 8, pp. 2378-2386, Aug. 2011, doi: 10.1109/TIP.2011.2109730. Available at https://ieeexplore.ieee.org/document/5705575

[21] Zhou Wang and A. C. Bovik, “A universal image quality index,” in IEEE Signal Processing Letters, vol. 9, no. 3, pp. 81-84, March 2002, doi: 10.1109/97.995823. Available at https://ieeexplore.ieee.org/document/995823

[22] Zhou Wang, A. C. Bovik, H. R. Sheikh and E. P. Simoncelli, “Image quality assessment: from error visibility to structural similarity,” in IEEE Transactions on Image Processing, vol. 13, no. 4, pp. 600-612, April 2004, doi: 10.1109/TIP.2003.819861.Available at https://ieeexplore.ieee.org/document/1284395

1. Available from: https://www.rfc-editor.org/info/rfc3161. ↑

2. Available from: https://www.rfc-editor.org/info/rfc4122. ↑

3. Available from: https://www.rfc-editor.org/info/rfc4648. ↑

4. Available from: https://www.rfc-editor.org/info/rfc8141. ↑

5. Available from: https://www.rfc-editor.org/info/rfc4514. ↑

6. Available from: https://www.rfc-editor.org/info/rfc5280. ↑

7. Available from: https://www.rfc-editor.org/info/rfc8152. ↑