Skip to content

[Question] Multi-phase workflow with working store and archive, how to update simple manifest properties? #176

Description

@fwanderse

Background
We are working on implemented C2PA support in Digital Asset Management (DAM) system, We are using c++ and the c2pa-c SDK.

What are we trying to do?
Using the c2pa::Builder, we are trying out a multi-phase workflow for building working stores for assets that live in our DAM system, and finally sign them when assets are downloaded or exported. The workflow is is similar to (or based on) what's described here under Two-phase workflow example in the working-stores doc.

OUR WORKFLOW

In phase 1

  • create a Builder with an initial manifest
  • add a parent-of ingredient
  • add some action(s)
  • call builder.to_archive(..) to save the working store for later

In n-number of phases

  • restore the working store using Builder::from_archive(...)
  • add some action(s) and maybe some component-of ingredients
  • call builder.to_archive(..) to save the working store for later

In the final phase (the signing phase)

  • restore the working store using Builder::from_archive(...)
  • add some final action(s)
  • [HERE IS THE ISSUE] update simple manifest properties before signing, e.g. title and format before signing.
  • call builder.sign(...) to create a signed asset (usually requested by the user in form of an export or download on a specified format)

The workflow is working - except for the issue:

ISSUE
Our issue is in the "final phase". Before signing, we need to update some simple manifest properties. This can be title, format, application and version (in claim_generator_info). These are values that were not necessary known in "phase 1" when the working store was initially created. For example users may have re-titled the asset, and requested to convert and export it to a different format.

I have found no way using the c2pa-c SDK to do the update of the manifest properties as described above.

I see that in the node.js SDK, there seem to be a method that can be used for this, updateManifestProperty(property, value): void, but I found no equivalent in the C/C++ SDK.

My question is:

  1. Is there maybe a (complete) different way to achieve what we are trying to do (that I haven't found)?
  2. Is there currently lack of support for this in c2pa-c SDK that will/can be implemented later?

As a side comment, I would like to mention: each phase described above may happen on different system components (backends, desktop apps etc.). Archives (c2pa files) may be transferred across network boundaries. Also long time may pass between each phase.

Activity

  1. tmathern commented on Mar 18, 2026

    @tmathern
    Collaborator

    Have you seen this doc: https://github.com/contentauth/c2pa-c/blob/main/docs/selective-manifests.md ? This part, especially: https://github.com/contentauth/c2pa-c/blob/main/docs/selective-manifests.md#filtering-into-a-new-builder.

    One idea could be to take your archived Builder in the last step, take what you need from it and create a new Builder.

  2. scouten-adobe commented on Mar 27, 2026

    @scouten-adobe
    Contributor

    Closing based on @tmathern's comment. If, after reading through that suggestion, there is a new feature request, please re-open or file a new ticket.

  3. fwanderse commented on Apr 4, 2026

    @fwanderse
    Author

    Have you seen this doc: https://github.com/contentauth/c2pa-c/blob/main/docs/selective-manifests.md ? This part, especially: https://github.com/contentauth/c2pa-c/blob/main/docs/selective-manifests.md#filtering-into-a-new-builder.

    One idea could be to take your archived Builder in the last step, take what you need from it and create a new Builder.

    Thanks for answer, and sorry for not coming back on this in a timely manner. I wanted to spend some more time testing the suggestion, but ran out of time earlier. Now I have finally tested.

    I explored the idea from from @tmathern about creating a new builder. In our case we basically need all ingredients and actions from the archived builder, so I copied everything; assertions, ingredients plus resources over. I got this working fine.

    So creating a new builder definitely looks like a way to go. This is good. However I also want to comment:
    In the case described in this issue, the asset and the working store exist side by side inside a system until the user exports the asset. As part of this export, the asset will be signed. The file format and filename, may also be decided (by the user) as part of the export - this needs to be reflected in the manifest, Maybe assertions (other than actions) also needs to be added to before signing. I do think it would be logical and convenient to be able update the builder's manifest and add assertions just before signing it in such case. I mean, instead of copying everything over to a new builder with a different manifest definition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions