1. Introduction

The C2PA intends to provide clear guidance for implementers of provenance-enabled user experiences (UX). Developing these recommendations is an ongoing process that involves diverse stakeholders, with the results balancing uniformity and familiarity with utility and flexibility for users across contexts, platforms, and devices. Our intent is to present a comprehensive range of conventions for the user experience and evolve them based on feedback.


TODO: Asset journey example of problems across fragmented data sharing vs. what C2PA is intending to do

2. Principles

The UX recommendations aim to define best practices for presenting C2PA provenance to consumers. The recommendations strive to describe standard, readily recognizable experiences that:

  • provide asset creators a means to capture information and history about the content they are creating, and

  • provide asset consumers information and history about the content they are experiencing, thereby empowering them to understand where it came from and decide how much to trust it.

User interfaces designed for the consumption of C2PA provenance must be informed by the context of the asset. We have studied 4 primary user groups and a collection of contexts in which C2PA assets are encountered. These user groups have been defined in the C2PA Guiding Principles as Consumers, Creators, Publishers and Verifiers (or Investigators). To serve the needs of each of these groups across common contexts, exemplary user interfaces are presented for many common cases. These are recommendations, not mandates, and we expect best practices to evolve.

2.1. Designing for trust

A unique aspect of this approach is that rather than attempt to determine the veracity of an asset, it enables users to make their own judgement by presenting the most salient and/or comprehensive provenance information. As such it is critical that users develop trust in the system itself, over the individual data presented. Exposing the C2PA Trust Model and Trust Signals in a way that balances transparency and intuitiveness is the critical design goal addressed here. There is no design pattern that can guarantee to engender trustworthiness across multiple contexts, and while we anticipate a degree of contextual customization (see applications and examples), we recommend all implementations adhere to the following general principles.

2.2. Quality

Implementations should be created using industry standard, robust user interface technologies.

2.3. Accessibility

Implementations should adhere to accepted, current accessibility standards to ensure no users are excluded. For an example of such criteria, see the Web Content Accessibility Guidelines (WCAG).

2.4. Consistency

Wherever suitable, UX patterns should match those outlined here. In the case that this would break contextual paradigms of the platform, lean on precedent whether in the OS or app design. Users should not have to learn new paradigms or terminology in different contexts in order to access the information.

2.5. Summary vs comprehensive

In many cases, a subset of the available information will be the most useful to a user in a given context. A link through to the full information should always be made available, however.

2.6. Linked

Some data will assert an individual or organization, wherever possible, a links out should be made available, to allow the user to make a judgement on those actors' trustworthiness.

3. User experience overview

3.1. Levels of Information Disclosure

Because the complete set of C2PA data for a given asset can be overwhelming to a user, we describe 4 levels of progressive disclosure which guide the designs:

Figure 1
Figure 1. Disclosure levels
Level 1

An indication that C2PA data is present and its cryptographic validation status.

Level 2

A summary of C2PA data available for a given asset. Should provide enough information for the particular content, user, and context to allow the consumer to understand to a sufficient degree how the asset came to its current state.

Level 3

A detailed display of all relevant provenance data. Note that the relevance of certain items over others is contextual and determined by the UX implementor.

Level 4

For sophisticated, forensic investigatory usage, a standalone tool capable of revealing all the granular detail of signatures and trust signals is recommended. In addition to these standard levels, there will be common tools available for those interested in a full forensic view of the provenance data. This would reveal all available C2PA data across all manifests for an asset, including signature details.

4. L1 – indicator of C2PA data

Figure 2
Figure 2. The L1 indicator

4.1. Appearance

Following the consistency principle, it is important in developing trust that users can learn to easily recognize the presence of the system and that their expectations are met regardless of context. As such, the L1 indicator should be consistent in its appearance across all contexts and devices to the degree that it clearly represents the presence of C2PA data. L1 can be applied using only the icon, the title, or both. If using the icon alone, ensure its appearance meets accessibility criteria so that consumers can easily identify its presence on or near the C2PA-enabled content. We recommend adhering to the “information seal” icon and working title “Content Credentials” for recognition and learned understanding of C2PA-enabled content.

4.2. Placement and interaction

For flexibility across implementations, there are two recommended placements for L1 indicators when C2PA-enabled content is present: on top of the content or somewhere close enough that its relationship to the content is clear. If L1 is positioned on top of the content, a hover state may be applied so as not to permanently obstruct the content below. Applications may differ depending on device, such as revealing L1 via long-press on mobile. A new user experience guidance is recommended for initial implementation rollout to make clear how to identify L1 indicators. Behavior of L1 indicators should reveal L2 progressive disclosure, either via a hover or click interaction. Within L2 user interfaces, L1 can continue to be used to indicate the presence of C2PA-enabled ingredients.

5. L2 – progressive disclosures

5.1. Minimum viable provenance

Figure 3
Figure 3. Minimum viable provenance display

If L1 indicates the presence of C2PA data, L2 is where consumers can begin to view and interact with the data. The minimum L2 user experience is defined as the display of nothing more than the base required C2PA manifest data: the signing entity, the claim generator and date. The signer is a top trust signal that allows the consumers to make their judgement trusting that the information available has been 'backed' by a legitimate entity. We anticipate that additional varying assertion data will be included by implementers, and recommend including the manifest thumbnail, signer logo, and a link to L3 where consumers can find more assertion data if available.

L2 styles, fonts, etc. can be customized to fit the given context. Iconography and terminology used to describe assertions should be consistent wherever possible. We anticipate the need for L2 generally to be real-estate efficient as it appears within the implementer’s context, so we suggest streamlining the data displayed to provide enough information for the particular content, user, and context to allow the consumer to understand to a sufficient degree how the asset came to its current state.

5.2. Discrete displays

Figure 4
Figure 4. Discrete manifest display

A discrete manifest display only represents a single manifest. It could be the active manifest, as this is the most recent version tied to the C2PA-enabled content, or another manifest determined by the implementer. For example, if the active manifest is actually a transcode since the C2PA-enabled content is being delivered by a CDN, the implementer may choose to display the second most recent manifest. The determination for displaying a discrete manifest should be if there is substantive assertion data in a given manifest the implementer believes is most relevant to its audience. A shortcoming of discrete displays it that the highlighted manifest may not represent the complete history of the C2PA-enabled content, and may require consumers to navigate away from the implementer’s context to L3 to learn more.

5.3. Summary displays

Figure 5
Figure 5. Summary display, example 1

A summary display represents the collection of manifests related to the C2PA-enabled content. Manifests should be presented in reverse chronological order, starting with the active manifest at the top and the origin ingredients below. Origin ingredients represent the beginning of their respective history branches.

Figure 6
Figure 6. Summary display, example 2

Summary displays should show at minimum the origin ingredients and active manifests, or if screen real estate allows, with at least one manifest in between.

Figure 7
Figure 7. Summary display, example 3

In order to provide users with a succinct summary and to allow for limited screen real estate, the manifests in between origin and active can be collapsed and represented as a numerical count. We recommend a baseline rule for collapsing manifests if the total number exceeds four or more. However, this threshold can be altered according to context. In keeping with the core recommendations, a link to the full set of data in L3 should always follow the summary list of manifests.

Figure 8
Figure 8. Summary display, two origins

When multiple origins are present, either as multiple ingredients in a single manifest or across multiple manifests, they can be summarized in the origin section of the UI. The L1 indicator can be used as a badge on ingredient thumbnails to distinguish C2PA-enabled assets.

Figure 9
Figure 9. Summary display, multiple origins

L2 UI is flexible enough to allow for various combinations of manifest counts and origin assets.

5.4. Non-Editorial Transform

Figure 10
Figure 10. Non-editorial transform, example 1

Non-editorial transforms or transcode manifests can be included in L2 UI. However, because transcode manifests do not typically contain data of significant user value, we recommend deprioritizing them in the summary display.

Figure 11
Figure 11. Non-editorial transform, example 2

Transcode manifests can be combined with other summary UI elements.

Figure 12
Figure 12. Non-editorial transform, example 3

If a transcode manifest appears between the active and origin manifests, it can also be collapsed into the "Additional steps" row.

5.5. Missing data

Figure 13
Figure 13. Missing data, example 1

There will be instances when C2PA-enabled content is missing data. Most commonly, this will happen if the content is edited without capturing C2PA data. In this event, the L2 and L3 UI should reflect when data is missing, as well as the manifest data that came before or after. It should be noted that because the relationship with prior manifests is tenuous, a dotted line can be drawn to suggest the connection is not the same as between valid, intact manifests. Note that the missing or incomplete data should not automatically signal that one should discount the content as untrustworthy. For this reason, we discourage against the use of an indicator designed to trigger alarm, which should be reserved for more apparent tamper-evident use cases, in favor of a more descriptive and neutral indicator.

Figure 14
Figure 14. Missing data, example 2

Following the established pattern of collapsing additional manifest, missing data steps can be called out via the text string (Figure 13) to bring awareness to the questionable validity of ingredients.

5.6. Broken bindings & untrusted signers

Figure 15
Figure 15. Error display

There may be instances when C2PA-enabled content has been maliciously edited to tamper with C2PA data, or is signed by an untrustworthy entity. In this case, no additional prior data can be displayed.

6. Applications and Use cases

As above, L2 assumes some level of contextual customization will be beneficial to make C2PA data helpful to users. Rather than recommend customizations based on a fixed set of applications, instead we have categorized the ways that assets are used to communicate aspects of reality to users, and provide a recommended customization based on that. The following examples represent a range of potentially common applications:

6.1. Arts and entertainment

Depicted is a discrete manifest showing an identity assertion, indicating the uploader is the same as the content producer.

Figure 16
Figure 16. Entertainment example

6.2. News

An example of photojournalism, wherein steps between the origin and published manifests are displayed.

Figure 17
Figure 17. News example

6.3. Social sites

A transcode manifest is depicted, representing C2PA content shared on a social network.

Figure 18
Figure 18. Social media example

6.4. E-commerce and retail

Depicted is a more complex summary, indicating the shared content on the retail platform is an edited composite of two images. Buyer beware!

Figure 19
Figure 19. E-commerce example

6.5. Travel

A travel company publishing a photo captured by a C2PA-enabled camera app.

Figure 20
Figure 20. Travel example

7. Open issues

7.1. Video

As a time-based media, video provenance represents a significant challenge to distill into simple consumer UI. Topics we are actively exploring relate to the visual representation of ingredients, the volume of potential edits, and assertions tied to temporal segments. We aim to provide more detailed recommendations for video content by the v1.0 spec.

7.2. User research

Correctly identifying and displaying trust signals are a paramount concern for our overall user experience. We strive to understand the value consumers will apply to content attribution through ongoing user research studies and usability testing.

8. Public Review, Feedback and Evolution

The team authoring the UX recommendations is cognizant of its limitations and potential biases, recognizing that feedback, review, user testing and ongoing evolution is a requirement for success. This guidance is therefore an evolving document, informed by real world experiences deploying C2PA UX across a wide variety of applications and scenarios.