Skip to content

Conversation

crandmck
Copy link
Collaborator

@crandmck crandmck commented May 29, 2025

See also Changes in the v1.0 SDK release.

Review questions:


WIP Notes:

  • To document: Hard binding types - Box hashes, etc.
  • Reading: Don't display - Thumbnails, ingredients

New assertion types:

  • Timestamp assertion
  • Update assertion support

Copy link

github-actions bot commented May 29, 2025

@github-actions github-actions bot temporarily deployed to pull request May 29, 2025 20:35 Inactive
@crandmck crandmck marked this pull request as draft May 30, 2025 15:19
@github-actions github-actions bot temporarily deployed to pull request June 2, 2025 15:17 Inactive
@github-actions github-actions bot temporarily deployed to pull request June 2, 2025 17:33 Inactive
@github-actions github-actions bot temporarily deployed to pull request June 12, 2025 22:09 Inactive
@github-actions github-actions bot temporarily deployed to pull request June 18, 2025 23:52 Inactive
@github-actions github-actions bot temporarily deployed to pull request June 19, 2025 18:42 Inactive
@crandmck crandmck requested a review from gpeacock July 10, 2025 20:39
@github-actions github-actions bot temporarily deployed to pull request July 14, 2025 15:54 Inactive
@github-actions github-actions bot temporarily deployed to pull request July 17, 2025 21:25 Inactive
@github-actions github-actions bot temporarily deployed to pull request July 23, 2025 21:05 Inactive
@github-actions github-actions bot temporarily deployed to pull request July 24, 2025 19:59 Inactive
@crandmck crandmck marked this pull request as ready for review August 28, 2025 21:31
@github-actions github-actions bot temporarily deployed to pull request August 28, 2025 21:41 Inactive
@github-actions github-actions bot temporarily deployed to pull request September 3, 2025 22:26 Inactive
@github-actions github-actions bot temporarily deployed to pull request September 5, 2025 20:25 Inactive
@github-actions github-actions bot temporarily deployed to pull request September 5, 2025 20:33 Inactive
@github-actions github-actions bot temporarily deployed to pull request September 5, 2025 20:56 Inactive
@github-actions github-actions bot temporarily deployed to pull request September 5, 2025 21:19 Inactive
@github-actions github-actions bot temporarily deployed to pull request September 5, 2025 22:36 Inactive
@github-actions github-actions bot temporarily deployed to pull request September 5, 2025 23:07 Inactive

## Legacy ingredients

Old manifests may contain these kinds of deprecated ingredient data:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While these labels will show up so they can detect them, the API will return the same ingredient option for any of them. But the field contents may vary depending on the version.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"...the API will return the same ingredient option ..."

I think this should be "...same ingredient OBJECT..." right?

@@ -0,0 +1,141 @@
---
id: cawg-id
title: Writing CAWG identity assertions
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is ok to explain how CAWG identity will look when reading manifests, but we have some work to do to define how you will create them. Eric has been reconstructing this api.


The `ingredients` array contains an [ingredient object](manifest/json-ref/manifest-def.mdx#ingredient) for each ingredient. The only required property of the `ingredient` object is the `title` property, which usually is the source file name.

The `label` property for the first ingredient in a manifest is `c2pa.ingredient.v3` When there is more than one ingredient, subsequent labels have a monotonically increasing index: `c2pa.ingredient.v3__1`, `c2pa.ingredient.v3__2`, and so on.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this only applies when reading, you can use your own labels when creating new ingredients, but those labels are only temporary and will be replaced

See [Validation results](json-ref/reader#validationresults) in the manifest JSON reference.

When ingredients are added, the SDK validates their Content Credentials (if any). However, the validation status of an ingredient does not imply anything about the validation status of the composed asset containing the ingredient. In other words:
- A composed asset's Content Credentials may be valid, but one or more of its ingredients may have invalid Content Credentials. For example, test file [adobe-20220124-XCA.jpg](https://contentcredentials.org/verify?source=https://c2pa.org/public-testfiles/image/jpeg/adobe-20220124-XCA.jpg)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think these are the right examples. XCA has a hard binding error in the active manifest but is otherwise valid. The A, ingredient is fine and has no manifest.

The CIE-sig-CA file has an invalid signature in an ingredient but active manifest is valid and identifies that that ingredients error were known when signed.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need correct examples here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants