From acdbef35eab6778b76dbd1bd89ef3a52624ce13e Mon Sep 17 00:00:00 2001 From: Rand McKinney Date: Fri, 23 Oct 2026 10:14:58 -0700 Subject: [PATCH 1/3] Add initial tech faqs --- docs/technical-faqs/tech-faq-conformance.md | 413 +++++++++++++++++++ docs/technical-faqs/tech-faq-rust.md | 194 +++++++++ docs/technical-faqs/tech-faq-verification.md | 130 ++++++ sidebars.js | 17 + 4 files changed, 754 insertions(+) create mode 100644 docs/technical-faqs/tech-faq-conformance.md create mode 100644 docs/technical-faqs/tech-faq-rust.md create mode 100644 docs/technical-faqs/tech-faq-verification.md diff --git a/docs/technical-faqs/tech-faq-conformance.md b/docs/technical-faqs/tech-faq-conformance.md new file mode 100644 index 00000000..0e2ff938 --- /dev/null +++ b/docs/technical-faqs/tech-faq-conformance.md @@ -0,0 +1,413 @@ +# C2PA Conformance FAQs + +These answers are based on discussions in the CAI C2PA conformance Discord +channel from April through October 2026. They have not been independently +verified against the latest requirements. Date-specific guidance reflects +those discussions, not a guarantee of current program policy. Discord source +links may require channel access. + +## How do I start the conformance process? + +Start with the [C2PA Conformance Program](https://c2pa.org/conformance/) +and its expression of interest form. The September 30, 2026 support reply +also linked the [program document](https://github.com/c2pa-org/conformance-public/blob/main/docs/v0.2/C2PA%20Conformance%20Program.pdf). + +That reply explains that a generator product must pass conformance before +obtaining a signing certificate from a CA with its root on the C2PA Trust +List. Test certificates can be used while preparing for evaluation; they +are not equivalent to trusted production credentials. + +[Source: certificate prerequisite, September 30, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1554850060112498779) + +[Source: program document, September 30, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1554850126449737808) + +[Source: expression of interest form, September 30, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1554850450874834964) + +[Source: evaluation certificates, September 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1547716234173222962) + +## How do I follow up on an application or correct its media types? + +Contact the conformance administrator at **conformance@c2pa.org** for +application-specific issues. For a missing response to an expression of +interest, provide the representative email address used in the submission. +The July discussion identified a contact problem that was subsequently +resolved; it does not establish a guaranteed response time. + +If a generator application incorrectly omits validation capabilities, request +a revision listing both the input media types it validates and the output +media types it generates. For example, a product could validate JPEG and PNG +ingredients while generating signed JPEG, PNG, WebP, and AVIF assets. Declare +your actual capabilities, not this example's list. + +[Source: application follow-up, July 2, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1522236996553146399) + +[Source: resolution, July 2, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1522288127408865310) + +[Source: correcting media types, June 21, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1518382298482081872) + +## Does conformance apply to the product or to each end user? + +Conformance is associated with a generator or validator product, whether +software or hardware, rather than an individual user. + +Creator identity is a separate concern. The support reply recommends a +separately signed CAWG identity assertion when a product needs to identify +its users. Product conformance alone does not establish each user's identity. + +[Source: product conformance and identity, August 12, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1537131310424784896) + +## Why does a generator application ask about validation? + +A generator that ingests assets and creates or appends manifests must invoke +validation logic against the C2PA CA and TSA Trust Lists as part of that +process. Its declared **validate** media types describe those inputs; its +**generate** media types describe the outputs for which it creates manifests. + +This ingredient validation is distinct from applying as a standalone +validator product. The July reply describes a validator product as one that +validates assets without generating manifests. An August reply advises +applying separately as a validator product when also building a verification +tool. + +[Source: generator validation scope, July 16, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1527310749628891176) + +[Source: separate verification tool, August 12, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1537127081672974486) + +## How do I choose between backend, distributed, and separate product submissions? + +A distributed generator can divide asset generation, assertions, claim +generation, and signing between edge and backend subsystems while functioning +as one product. The August guidance describes mutual authentication between +the subsystems and a backend check that the caller is a valid instance of +the edge subsystem. + +The May guidance says cooperating subsystems might be submitted as one +distributed product, while components that independently generate assets, +claims, and signatures would probably require separate submissions. + +Do not classify a customer-hosted component solely by whether it runs on a +server. For that case, support did not give a definitive classification. +Submit an architecture summary and diagram to conformance@c2pa.org, identifying +the **Target of Evaluation**, the components included in the generator +product, and how objects submitted for signing are authenticated. The +discussion also flags dependency vulnerability scanning as a potential +challenge for customer-hosted deployments. + +[Source: cooperating subsystems, May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504810186504671304) + +[Source: independent generators, May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504810688638484660) + +[Source: distributed authentication, August 27, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1542545382997893230) + +[Source: customer-hosted architecture caveats, August 27, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1542586446815170750) + +[Source: definitive assessment requires an architecture, August 28, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1542842626947154031) + +## Does using the latest SDK make my product conformant? + +No. The May support reply generally recommends using the latest SDK, but +explicitly says that SDKs are tools for building products and must be used +in a conformant way. It does not specify a minimum SDK version. + +Preparation checks highlighted in the discussion include: + +- Configure created versus gathered assertions deliberately. +- Use `c2pa.created` and `c2pa.opened` appropriately. Do not describe an + existing asset uploaded by a user as newly created by your product. +- Validate ingredients with the C2PA Trust List configured. + +Interoperability test assets are provided as part of the conformance process. + +[Source: test assets, May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504806955154280601) + +[Source: SDK recommendation and limitation, May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504807032341925918) + +[Source: preparation checks, May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504807213145784443) + +## How do I configure trust for ingredient validation? + +The support guidance recommends loading both the +[C2PA Trust List](https://raw.githubusercontent.com/c2pa-org/conformance-public/refs/heads/main/trust-list/C2PA-TRUST-LIST.pem) +and the +[C2PA TSA Trust List](https://raw.githubusercontent.com/c2pa-org/conformance-public/refs/heads/main/trust-list/C2PA-TSA-TRUST-LIST.pem). +Fetch their PEM contents, concatenate them, and supply the resulting PEM +string through `trust.trust_anchors`. + +For SDK integrations, pass the settings to the builder through a context. +The May 23 follow-up replaces an earlier thread-local settings example, +noting that thread-local settings had been deprecated. + +The August clarification says that the C2PA Trust List alone may appear to +work for timestamp trust because the lists share roots. It still recommends +including the TSA list to pick up intermediate CA certificates. This is +trust-anchor configuration guidance, not a complete answer to every +certificate-expiration or point-in-time validation scenario. + +[Source: PEM configuration, May 22, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1507426136596942962) + +[Source: context-based follow-up, May 23, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1507741760820871250) + +[Source: TSA intermediate certificates, August 19, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1539661485234724864) + +## How do I load trust lists in C2PA Tool? + +Use a raw PEM URL rather than a GitHub file-view page when supplying a +trust-anchor link. + +The August 6 replies explain that `c2patool init trust` loads, updates, and +stores the C2PA Trust List for reuse in subsequent commands unless overridden. +For more control, pass a settings file with `--settings`; TOML settings are +passed through to the SDK. Support also suggests supplying the concatenated +CA and TSA lists when needed to include TSA intermediate certificates. + +See the source-linked +[trust settings walkthrough](https://learn.contentauthenticity.org/signing-an-edited-image). + +[Source: raw PEM URL, August 6, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1534942946212708522) + +[Source: initialization command, August 6, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1534943626499719369) + +[Source: settings option, August 6, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1534945015598678176) + +[Source: persistence and concatenated lists, August 6, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1534995351101116646) + +## Which timestamp endpoints were recommended for C2PA trust? + +On August 10, 2026, support identified these SSL.com endpoints as free for +general use with roots on the C2PA TSA Trust List: + +- `http://ts-c2pa.ssl.com/rsa` +- `http://ts-c2pa.ssl.com/ecc` + +Another participant linked +[Trufo timestamping documentation](https://trufo.ai/documentation#timestamping), +noting that its service required payment and authentication. + +These are dated service recommendations, not a guarantee of current +availability, pricing, or trust-list membership. + +[Source: SSL.com endpoints, August 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1536414294198059132) + +[Source: Trufo documentation, August 11, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1536747888305242223) + +[Source: Trufo access conditions, August 11, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1536748051287248998) + +## Can evaluation samples use test certificates and still report untrusted? + +Yes. The September guidance permits SDK test certificates, CA-provided test +certificates, or certificates you generate yourself, but explicitly says +the evaluation signing certificates cannot be self-signed. Do not interpret +"generate your own" as permission to use a self-signed signing certificate. + +The reply links +[SDK test certificates](https://github.com/contentauth/c2pa-rs/tree/main/sdk/tests/fixtures/certs) +and a [certificate creation walkthrough](https://learn.contentauthenticity.org/private-keys-and-certificates). + +The October 9 clarification says `signingCredential.untrusted` is normal +before obtaining a conforming product certificate and does not itself prevent +passing conformance. This does not excuse other failures or prove that the +rest of an implementation is correct. + +[Source: evaluation certificate constraints, September 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1547716234173222962) + +[Source: certificate creation walkthrough, September 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1547720168149352558) + +[Source: SDK fixtures, September 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1547720257018269826) + +[Source: expected untrusted status, October 9, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1558172948022698065) + +## Does adding a trusted manifest remove warnings about earlier untrusted manifests? + +Do not assume that it does. The September reply explains that validators +generally show a notice when an asset contains manifests signed with +untrusted certificates. The notice may apply to individual manifests, the +manifest store, or both, depending on the validator. + +When a subsequent conforming generator validates such an asset as an +ingredient, it includes the ingredient validation results. If it uses only +the C2PA Trust List, an ingredient signed with a certificate from an +untrusted private CA will produce `signingCredential.untrusted`. + +This explains a trust-display consequence of a mixed pipeline. It is not a +blanket ruling that every trusted/untrusted pipeline is prohibited. + +[Source: mixed-pipeline trust behavior, September 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1547716234173222962) + +## How do I put the actions assertion in created assertions? + +Configure `builder.created_assertion_labels` using **base assertion labels**. +For the Node bindings, support provided: + +```js +const settings = { + builder: { + created_assertion_labels: ['c2pa.actions'], + }, +}; + +const builder = Builder.withJson(manifestDefinition, settings); +``` + +Use `c2pa.actions`, not `c2pa.actions.v2`. Likewise, do not include assertion +instance suffixes such as those in `c2pa.ingredient.v3__2`. + +With only `c2pa.actions` in that setting, the support reply says that the +actions assertion and the automatically created hard binding are created +assertions; other assertions are gathered. Add other base labels as +appropriate for your implementation. This is not a universal conformance +configuration. + +The August user follow-up confirmed the setting worked, but noted that the +Reader output flattened created and gathered assertions into one list. +They inspected the raw claim bytes to verify placement. + +[Source: base labels and automatic hard binding, August 19, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1539665498835517531) + +[Source: successful verification and Reader limitation, August 19, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1539705852968177734) + +[Source: Node settings, September 2, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1544696112101728396) + +[Source: passing settings to the builder, September 2, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1544696724411645972) + +## Should ingredient assertions be created or gathered? + +The July support reply recommends marking an ingredient assertion as created +in most cases because the claim generator validates it. This is +implementation-dependent guidance, not a statement that every assertion +associated with an input asset must be created. + +Configure assertion placement deliberately rather than relying on the +SDK default described in the May discussion, which placed assertions other +than the hard binding in gathered assertions. + +[Source: ingredient recommendation, July 9, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1524768241518641272) + +[Source: SDK default, May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504807213145784443) + +## What does digitalSourceType describe, and when is it needed? + +The July clarification says that `digitalSourceType` describes the nature +of how an **action** was performed, such as human, AI, or algorithmic activity. +It is not one asset-wide value to copy unchanged through every edit. The +reply also notes that C2PA 2.4 allows it to describe an ingredient. + +The same discussion says actions affecting the asset's editorial nature need +a digital source type, whereas an unbound watermarking action does not. +An original asset should still be referenced as the ingredient associated +with `c2pa.opened`; that action does not require a digital source type. + +The August clarification explicitly states that `c2pa.created` requires an +appropriate `digitalSourceType` in both C2PA 2.2 and 2.4. It links the +[specification requirement](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_mandatory_presence_of_at_least_one_actions_assertion) +and section 2.4 of the +[Additional Conformance Requirements](https://github.com/c2pa-org/conformance-public/blob/main/docs/v0.2/Additional%20Conformance%20Requirements%20Against%20the%20Content%20Credentials%20Specification.pdf). +Do not infer that the field is optional merely because an older validator +did not report its absence. + +[Source: action and ingredient semantics, July 14, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1526686021004296334) + +[Source: editorial actions, July 14, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1526686436689055785) + +[Source: opened action and ingredient, July 14, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1526686633561428018) + +[Source: created action requirement, August 20, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1540014008319610961) + +## How should I describe visible and invisible watermarking? + +For invisible watermarking, support recommends `c2pa.watermarked.bound` +or `c2pa.watermarked.unbound`, depending on whether a `c2pa.soft-binding` +assertion is used with it. + +For a visible logo, the reply recommends representing it as a `componentOf` +ingredient and recording `c2pa.placed` with a parameter referencing that +ingredient. For a text-only visible watermark, it suggests considering +`c2pa.addedText`. + +These recommendations replace the question's proposed blanket mapping of +visible watermarking to `c2pa.edited` with a `composite` source type. + +[Source: watermarking guidance, July 9, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1524768241518641272) + +## Which action describes publishing an already signed asset? + +For the marketplace publishing scenario discussed in May, support recommends +`c2pa.published`, together with any other actions that actually occurred. +It means the asset is released to a wider audience. The reply explicitly +says there is no `c2pa.signed` action. + +Use the [official action definitions](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_actions) +to describe the operation, rather than inventing an action solely because +another signature was produced. + +[Source: publication action, May 17, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1505616834148303099) + +## How should I represent a user's training and mining preferences? + +For the discussed seller opt-out workflow, support confirms that +`cawg.training-mining` belongs in gathered assertions. It remains +cryptographically protected there, but is not attributable to the C2PA claim +generator or signer. + +The reply accepts that placement under the manifest signature. If you want +to connect the preference to a CAWG identity, reference the assertion through +the `referenced_assertions` array of `cawg.identity`. + +This answers attribution and cryptographic protection; it does not claim +that the assertion enforces a user's preference on downstream systems. + +[Source: gathered preference assertion and optional identity link, June 8, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1513597018038206725) + +## Can my organization's identity certificate identify all my users? + +Not through the CAWG X.509 method described in the August reply. Each user +would need a CAWG certificate issued with that user's own name or organization. +Your organization's certificate asserts your organization's identity, not +the identities of all its users. Support suggests **Identity Claims +Aggregation** as an option for platforms. + +The October explanation distinguishes this from becoming a C2PA CA, which +is for issuing signing certificates to conforming products. To attach +artist, creator, or publisher identity, it instead recommends the +[CAWG identity assertion](https://cawg.io/identity/1.3/), using an X.509 +certificate or Identity Claims Aggregation. + +[Source: per-user X.509 identity, August 13, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1537519938552733766) + +[Source: CA versus creator identity, October 9, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1558191343988117524) + +## Why can crJSON show different specVersion values? + +The August 11 explanation distinguishes two fields: + +- `claim_generator_info.specVersion` in the claim describes the specification + version declared by the generator. +- `validationResults.specVersion` describes the specification version against + which validation was performed. It is not copied from the generator's field. + +Support reproduced a claim declaring `2.4.0` while the validation results +reported `2.3.0`, and explained that the validation value was hard-coded in +the SDK implementation at that time. Check the generator value in +`claim.v2` rather than trying to change the report's validation version +through generator metadata. + +That explanation resolves the field mismatch, not every conformance check. +Matching the generator field or passing a rubric alone is not presented +here as proof that a product has passed the program. + +[Source: field definitions, August 11, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1536901977655742567) + +[Source: reproduced version mismatch, August 11, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1536918406375276704) + +## Was the Interim Trust List completely unchanged after it was frozen? + +The April 27, 2026 response says necessary exceptions were made in very rare +cases and that no further changes were anticipated. This explains the +reported post-freeze updates; it is not an invitation to submit new entries +or a promise about future changes. + +For ingredient validation configuration, the later support guidance points +to the C2PA Trust List and C2PA TSA Trust List. + +[Source: rare exceptions, April 27, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1498294658600665170) + +[Source: current-list configuration guidance at the time, August 19, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1539661485234724864) diff --git a/docs/technical-faqs/tech-faq-rust.md b/docs/technical-faqs/tech-faq-rust.md new file mode 100644 index 00000000..fc7a69b9 --- /dev/null +++ b/docs/technical-faqs/tech-faq-rust.md @@ -0,0 +1,194 @@ +# Technical FAQ + +These answers are based on discussions in the CAI Rust SDK Discord channel +from April through October 2026. Version-specific information reflects those +discussions and has not been independently checked against the latest release. +Discord source links may require channel access. + +## Can I configure trust anchors using a URL? + +The Rust SDK expects trust anchors as a **PEM string**, not a URL or file +path. Your application must fetch or read the PEM data and pass its contents +to the SDK. + +C2PA Tool accepts URLs and paths as command-line arguments because it +retrieves the data before passing it to the SDK. + +The support reply provided this example: + +```rust +let pem = reqwest::blocking::get("https://example.com/trust_anchors.pem")? + .text()?; + +c2pa::settings::Settings::from_toml( + &toml::toml! { + [trust] + trust_anchors = pem + } + .to_string(), +)?; +``` + +[Source: April 7, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1491236748653494503) + +## How do I mark assertions as created rather than gathered? + +Use the `builder.created_assertion_labels` setting to identify assertions +attributed to your claim generator. For example: + +```toml +[builder] +created_assertion_labels = [ + "c2pa.actions", + "c2pa.thumbnail.claim", + "c2pa.thumbnail.ingredient", + "c2pa.ingredient" +] +``` + +Choose labels appropriate to your implementation. This example is not a +universal conformance configuration. The support discussion notes that the +hard-binding assertion is always a created assertion. + +See [Created versus gathered assertions](https://opensource.contentauthenticity.org/docs/manifest/writing/assertions-actions/#created-versus-gathered-assertions) +for more information. + +[Source: June 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1516521499517779978) + +## How do I preserve an existing asset's assertions when editing it? + +Include the original asset as a **`parentOf` ingredient**. If the asset is +signed, its manifest and assertions are carried forward through that +ingredient. You generally do not need to copy those assertions into your +new manifest as gathered assertions. + +For a typical editing workflow, use: + +```rust +builder.set_intent(BuilderIntent::Edit); +``` + +Edit intent automatically adds the `c2pa.opened` action and uses the source +as the parent if you do not specify one. Do not manually add a duplicate +`c2pa.opened` action. + +It is normal for a simple open-and-edit workflow to have no gathered +assertions. If you intentionally reuse metadata as a new gathered assertion, +verify that it still applies to the edited asset. + +[Source: parent handling, October 14, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1559968978376593439) + +[Source: gathered-assertion clarification, October 14, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1560080821287657594) + +## How do I add timestamps for existing ingredient manifests? + +Enable automatic timestamp assertions. The support discussion provided +these settings: + +```toml +[builder.auto_timestamp_assertion] +enabled = true +fetch_scope = "all" +``` + +Choose the builder intent according to the operation: + +- Use **update intent** when the asset content has not changed and you only + need to add a timestamp assertion. +- Use **edit intent** when you are also editing or reformatting the asset. + +The support responder tested both approaches. The discussion also states +that the timestamp assertion must be added while the relevant signing +certificate is still within its validity period. + +[Source: settings, April 20, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1495826791313571900) + +[Source: intent selection, April 20, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1495827650026147952) + +[Source: certificate validity, April 7, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1491238678410821784) + +## Why is no thumbnail generated when thumbnails are enabled? + +The SDK skips automatic thumbnail generation for **update manifests**, +even when thumbnail generation is enabled. The support reply explains that +the specification does not permit update manifests to contain thumbnail +assertions. + +[Source: April 19, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1495464171934974002) + +## Why do I get duplicate timestamp assertions with `skip_existing = true`? + +The intended behavior of `skip_existing` is to exclude claims already +covered by timestamps, including timestamps in COSE signatures and timestamp +assertions. + +The discussion identified a bug when an ingredient contained **both** +forms of timestamp. The fix was submitted in +[PR #2085](https://github.com/contentauth/c2pa-rs/pull/2085), and the support +responder confirmed that it merged on April 24, 2026. + +If you encounter this behavior, check whether your SDK version includes +that fix. The discussion does not identify the first release containing it. + +[Source: diagnosis, April 24, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1497281494471806976) + +[Source: merge confirmation, April 24, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1497360349878419509) + +## Why does C2PA Tool behave differently when launched by my application? + +Check the **actual executable and version** your application launches, +rather than only the version available in your terminal. + +In the reported case, the application launched C2PA Tool **0.26.1**, +although the user expected **0.26.41**. Launching 0.26.41 resolved the +missing timestamp assertion. + +This is one troubleshooting step, not evidence that every missing timestamp +has this cause. + +[Source: confirmed resolution, April 22, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1496644840786624614) + +## Can I create sidecar manifests for unsupported file types? + +Yes. In the September 2026 discussion, support confirmed that sidecar +support for otherwise unsupported file types had been implemented, +referenced [PR #2014](https://github.com/contentauth/c2pa-rs/pull/2014), +and tested `.obj` and `.mtl` files. + +A user running C2PA Tool 0.27.22 saw an "unsupported file type" error +**after signing**, during the subsequent read operation. The sidecar had +still been created. + +To read the asset with its sidecar, the support reply recommended: + +```sh +c2patool file.obj --external-manifest file.c2pa +``` + +The user subsequently confirmed that the sidecars were being written +successfully. + +[Source: implementation, September 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1549892485080293416) + +[Source: read command, September 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1549898982988455988) + +[Source: user confirmation, September 17, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1550145681090412695) + +## How do I avoid sidecar filename collisions? + +Assets with the same base name can produce the same default sidecar +filename. For example, `file.obj` and `file.mtl` can both produce +`file.c2pa`. + +Rename each sidecar immediately after creating it to preserve the original +extension, for example: + +```text +file.obj.c2pa +file.mtl.c2pa +``` + +When reading an asset, explicitly provide the corresponding sidecar using +`--external-manifest`. + +[Source: September 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1549894561537466399) diff --git a/docs/technical-faqs/tech-faq-verification.md b/docs/technical-faqs/tech-faq-verification.md new file mode 100644 index 00000000..7eda673d --- /dev/null +++ b/docs/technical-faqs/tech-faq-verification.md @@ -0,0 +1,130 @@ +# Technical FAQ topics for review + +These editorial notes capture unresolved or time-sensitive topics from the +CAI Rust SDK Discord history covering April through October 2026. They are +not confirmed FAQ answers. Verify each topic before publishing guidance. +Discord source links may require channel access. + +See the [Technical FAQ](./tech-faq-rust.md) for the nine drafted answers. + +## Verification website reports invalid content that the SDK reports as trusted + +**Candidate question:** Why does a verification website reject an asset +that the SDK reports as trusted? + +The user reported that the SDK returned successful validation results and +a `Trusted` validation state. Support suspected incomplete website support +for update manifests or timestamp assertions and recommended checking with +the SDK or C2PA Tool. No website fix or support timeline was confirmed. + +Before publication: + +- Identify the affected verification website and version, if available. +- Confirm its current support for update manifests and timestamp assertions. +- Reproduce any remaining discrepancy with the same asset and trust settings. +- Do not present incomplete website support as the cause of every validation + discrepancy. + +[Source: initial guidance, April 7, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1491238678410821784) + +[Source: SDK validation result, April 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1494485332010209350) + +[Source: pending website support information, April 20, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1495872312413655162) + +## Server-side assertion validation with a remote signer + +**Candidate question:** How can a remote signer validate assertion values +before signing without receiving the asset bytes? + +Support suggested sending serialized assertions with the claim, checking +their hashes against the claim, and inspecting their contents. The user +reported difficulties accessing assertion salts through `AsyncSigner`. +No complete, confirmed implementation was provided. + +The discussion also distinguished assertion integrity from the broader +security architecture of a distributed implementation. Questions about +whether the proposed architecture satisfied conformance requirements were +referred to the C2PA conformance program. + +Before publication: + +- Confirm the current APIs for accessing serialized assertions and salts. +- Develop and test a complete example of server-side assertion validation. +- Distinguish hash integrity checks from validation of assertion values. +- Obtain authoritative guidance on the applicable conformance requirements; + do not infer that client authentication alone is sufficient. + +[Source: proposed approach, August 10, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1536422380207996989) + +[Source: API limitations, August 11, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1536634968212774962) + +[Source: security architecture, August 11, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1536713305916440648) + +[Source: conformance referral, August 17, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1538923231476457533) + +## Rust SDK 1.0 release timeline + +**Candidate question:** When will the Rust SDK reach 1.0? + +On June 8, 2026, support said the team was not ready to share a timeline. +This is a dated roadmap response, not a permanent FAQ answer. + +Before publication, check current release information and obtain an +approved roadmap statement from the team. + +[Source: June 8, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1513639744167219280) + +## Build failure caused by a yanked dependency + +**Candidate question:** What should I do about the yanked dependency +build failure? + +An October 16, 2026, announcement directed affected source builds to +upgrade to `c2pa-rs` 0.91.3 because of a yanked `zip` dependency. The +announcement named `zip` 8.6.0 and described 0.91.2 and earlier SDK +versions as affected. These details have not been independently verified. + +Before publication: + +- Verify the dependency version and the exact affected SDK releases. +- Confirm the first release containing the dependency update. +- Check how existing lockfiles affect reproducibility. +- Prefer a dated troubleshooting notice over an evergreen FAQ entry. + +[Source: October 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1560738950807687341) + +## Ingredient digital source type and remote-signer certificate chains + +**Candidate questions:** + +- Does the SDK support the ingredient `digitalSourceType` field? +- Has the remote signer's PEM certificate-chain parsing issue been fixed? + +A contributor reported missing ingredient `digitalSourceType` support and +linked [PR #2078](https://github.com/contentauth/c2pa-rs/pull/2078) and +[issue #2077](https://github.com/contentauth/c2pa-rs/issues/2077). +The contributor also linked +[PR #2075](https://github.com/contentauth/c2pa-rs/pull/2075) for parsing a +remote signer's PEM certificate chain into individual DER certificates. +The export does not confirm merge or release status for either fix. + +Before publication, verify each PR's status, identify the first release +containing the change, and test a minimal example of the reported behavior. +Treat these as separate FAQ entries if both remain useful. + +[Source: ingredient field, May 4, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1500953348722131055) + +[Source: certificate-chain parsing, May 4, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1500953982431133827) + +## Building the C SDK for 32-bit Windows + +**Candidate question:** How do I build the C SDK for 32-bit Windows? + +A user reported receiving an x64 DLL when attempting to build the C SDK +for Win32 x86. No resolution appears in the export. The later resolution +of a C2PA Tool version mismatch does not resolve this separate build issue. + +Before publication, confirm supported targets and toolchain requirements, +reproduce the build, and verify the architecture of the resulting DLL. + +[Source: April 21, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1496248252767670272) diff --git a/sidebars.js b/sidebars.js index fe2ccfe4..a17718db 100644 --- a/sidebars.js +++ b/sidebars.js @@ -138,6 +138,23 @@ const sidebars = { ...getRemoteSidebarItems('tasks'), ], }, + { + type: 'category', + label: 'Technical FAQs', + collapsed: true, + items: [ + { + type: 'doc', + id: 'technical-faqs/tech-faq-rust', + label: 'Rust SDK FAQ', + }, + { + type: 'doc', + id: 'technical-faqs/tech-faq-conformance', + label: 'C2PA Conformance FAQs', + }, + ], + }, { type: 'category', label: 'Signing and certificates', From 262148c117b42d70342b092719ac2535c4404eb4 Mon Sep 17 00:00:00 2001 From: Rand McKinney Date: Fri, 23 Oct 2026 11:31:19 -0700 Subject: [PATCH 2/3] Add more FAQs --- ...-faq-verification.md => faqs-to-review.md} | 2 - docs/technical-faqs/tech-faq-c2pa-tool.md | 210 ++++++++++++++++++ docs/technical-faqs/tech-faq-cawg.md | 149 +++++++++++++ docs/technical-faqs/tech-faq-certificates.md | 181 +++++++++++++++ docs/technical-faqs/tech-faq-conformance.md | 24 ++ docs/technical-faqs/tech-faq-general.md | 99 +++++++++ docs/technical-faqs/tech-faq-node.md | 149 +++++++++++++ docs/technical-faqs/tech-faq-rust.md | 60 ++++- sidebars.js | 25 +++ 9 files changed, 892 insertions(+), 7 deletions(-) rename docs/technical-faqs/{tech-faq-verification.md => faqs-to-review.md} (98%) create mode 100644 docs/technical-faqs/tech-faq-c2pa-tool.md create mode 100644 docs/technical-faqs/tech-faq-cawg.md create mode 100644 docs/technical-faqs/tech-faq-certificates.md create mode 100644 docs/technical-faqs/tech-faq-general.md create mode 100644 docs/technical-faqs/tech-faq-node.md diff --git a/docs/technical-faqs/tech-faq-verification.md b/docs/technical-faqs/faqs-to-review.md similarity index 98% rename from docs/technical-faqs/tech-faq-verification.md rename to docs/technical-faqs/faqs-to-review.md index 7eda673d..349c0579 100644 --- a/docs/technical-faqs/tech-faq-verification.md +++ b/docs/technical-faqs/faqs-to-review.md @@ -5,8 +5,6 @@ CAI Rust SDK Discord history covering April through October 2026. They are not confirmed FAQ answers. Verify each topic before publishing guidance. Discord source links may require channel access. -See the [Technical FAQ](./tech-faq-rust.md) for the nine drafted answers. - ## Verification website reports invalid content that the SDK reports as trusted **Candidate question:** Why does a verification website reject an asset diff --git a/docs/technical-faqs/tech-faq-c2pa-tool.md b/docs/technical-faqs/tech-faq-c2pa-tool.md new file mode 100644 index 00000000..1a5eb2c3 --- /dev/null +++ b/docs/technical-faqs/tech-faq-c2pa-tool.md @@ -0,0 +1,210 @@ +# C2PA Tool FAQs + +These answers are based on the 69 messages in the exported CAI C2PA Tool +Discord history, covering April 1 through October 8, 2026. The export supports +eight useful answered topics, selected for actionable guidance rather than +a measured frequency ranking. + +Behavior and version information reflect those discussions and have not been +independently checked against the latest releases or external sources. +Discord source links may require server membership and channel access. + +Selected answers also draw on the General channel history from April through +October 2026, with the same source-only, unverified status. + +## How can I inspect a file locally from the command line? + +The September 11 General-channel answer recommends the open-source C2PA +Tool CLI for inspecting a file on your own machine: + +```sh +c2patool file.jpg --detailed +``` + +This avoids uploading the asset to a web inspection service. It is not a +promise that every configuration or operation is network-free; for example, +the trust initialization command below fetches trust lists. Local +inspection also does not by itself establish that the signer is trusted +or that the depicted content is true. + +[Source: local CLI inspection command, September 11, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1548138360139419719) + +## Does C2PA Tool load trust lists automatically? + +The answer changed during the exported period. In April 2026, support said +the C2PA Trust List was not loaded automatically and showed how to supply +trust anchors through settings or the command line. + +On June 19, support announced a command to fetch or update trust lists and +store them for future calls: + +```sh +c2patool init trust +``` + +The announcement says trust sidecars are loaded automatically on subsequent +runs from the same directory as the settings file. This describes behavior +after initialization, not an assurance that an unconfigured installation +already has current trust lists. + +For ingredient validation during signing, the May guidance specifically +called for configuring both the C2PA Trust List and C2PA TSA Trust List. + +[Source: explicit trust configuration, April 1, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1488985307343884348) + +[Source: trust initialization, June 19, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1517556047324250223) + +[Source: ingredient and timestamp trust, May 27, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1509239917262405742) + +## Does a new manifest automatically inherit its parent's title? + +In the April discussion, support said there was no automatic assignment of +the `parentOf` ingredient's title to the new claim's `dc:title`. Without an +explicit title in the manifest definition, the output filename was used. + +Set the desired title in the new manifest definition rather than relying on +inheritance. The follow-up confirmed that supplying the title this way +worked. This sets the active manifest's title; changing an ingredient's +title is a separate operation. + +[Source: default title behavior, April 7, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1491244347075727431) + +[Source: explicit title confirmation, April 30, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1499462978687209482) + +## How can I override an ingredient's title? + +The April support answer describes exporting a signed asset as an ingredient +using the `--ingredient` option. The resulting folder contains ingredient +JSON, a thumbnail, and the manifest binary. Edit the title in the ingredient +JSON, then reference the folder through `ingredient_paths` in the new +manifest definition: + +```json +"ingredient_paths": ["./ingredient-folder"] +``` + +This is a field excerpt, not a complete JSON document. The follow-up +confirmed that this workflow worked. + +[Source: ingredient export and title workflow, April 30, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1499513543291305995) + +[Source: successful result, May 1, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1499846501948456980) + +## Does the overall validation state describe only the active manifest? + +No. In the May discussion, support clarified that `validation_state` also +considers ingredient deltas. An earlier suggestion that an ingredient +failure should not affect the overall state was superseded by this +explanation after inspecting the code. + +For the active manifest alone, inspect the success, informational, and +failure arrays in `validation_results.activeManifest`. Do not interpret +an aggregate `Invalid` result as proof that the active manifest itself +has a signature failure. + +Support recommended displaying each manifest's state independently and +distinguishing valid-but-untrusted manifests from trusted ones. That is +presentation guidance, not a rule that cryptographic validity establishes +signer trust. + +[Source: aggregate state clarification, May 27, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1509250331320778864) + +[Source: active-manifest results, May 28, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1509555410921590835) + +[Source: ingredient deltas, May 28, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1509555776585465907) + +[Source: per-manifest presentation guidance, May 27, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1509374914510196737) + +## How do I supply my own thumbnail? + +The August support answer shows a `thumbnail` object in the manifest +definition. Its `identifier` is a file path relative to the manifest +definition file: + +```json +"thumbnail": { + "format": "image/jpeg", + "identifier": "thumbnail.jpg" +} +``` + +This is a field excerpt to include in a complete manifest definition. +The source command was: + +```sh +c2patool sample.mp4 -m manifest.json -o sample-signed.mp4 +``` + +Support said the same approach can define ingredient thumbnails. This +provides an explicit thumbnail; it does not explain or promise automatic +thumbnail generation for every input format. + +[Source: custom thumbnails and relative paths, August 31, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1543975786468352150) + +## Why might an HEIC thumbnail not appear in Verify? + +The September answer separates signing from display. For the reported +thumbnail format being changed to `application/octet-stream`, support +advised using a v2 claim, either by setting `claim_version` to `2` or by +omitting it when v2 was the default. The follow-up confirmed that this +resolved the reported signing issue. + +Display also depends on browser support. At the time, support reported +that `image/heic` thumbnails displayed in macOS Safari but not Chrome. +A correctly embedded thumbnail therefore did not guarantee display in +every browser. These observations are historical, not a current browser +compatibility matrix. + +[Source: v2 claims and browser-dependent display, September 1, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1544362081107578961) + +[Source: successful result, September 2, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1544907804417064970) + +## How can I sign a TIFF sample and configure created assertions? + +The September support reply confirmed TIFF reading and writing and supplied +this example: + +```sh +c2patool sample.tiff \ + --settings settings.toml \ + --manifest manifest.json \ + --output signed.tiff +``` + +For that command, support said the source asset becomes a `parentOf` +ingredient and the tool automatically adds the `c2pa.opened` action. +The reply also allowed omitting settings when using the default key and +certificate; it did not establish that those defaults are trusted or +qualify a product for conformance. + +When the implementation needs to designate created rather than gathered +assertions, the follow-up supplied this settings excerpt: + +```toml +[builder] + +created_assertion_labels = [ + "c2pa.actions", + "c2pa.ingredient" +] +``` + +Select the assertions appropriate to the implementation. This is a signing +example, not a complete conformance procedure or universal configuration. + +[Source: TIFF signing command and defaults, September 15, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1549488757898616973) + +[Source: created assertion settings, September 15, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1549489530598588417) + +## Where is the C2PA Tool source repository? + +The September 10 announcement says the CLI source moved out of `c2pa-rs` +into the separate +[`contentauth/c2patool` repository](https://github.com/contentauth/c2patool). +The stated purpose was to allow CLI changes without versioning the Rust +SDK and to avoid confusion between their version numbers. + +The announcement explicitly said this move did not change how to install +or use the tool. + +[Source: repository move, September 10, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1547708360432812152) diff --git a/docs/technical-faqs/tech-faq-cawg.md b/docs/technical-faqs/tech-faq-cawg.md new file mode 100644 index 00000000..be56e249 --- /dev/null +++ b/docs/technical-faqs/tech-faq-cawg.md @@ -0,0 +1,149 @@ +# CAWG Standard FAQs + +These answers are based on the 41 messages in the exported CAI CAWG Standard +Discord history, covering May 1 through October 16, 2026. The export supports +five useful answered topics, selected for actionable guidance rather than +a measured frequency ranking. + +Version, implementation, and trust-model information reflect those +discussions and have not been independently checked against the latest +releases or external sources. Discord source links may require server +membership and channel access. + +Selected answers also draw on the General channel history from April through +October 2026, with the same source-only, unverified status. + +## Does c2pa-rs support identity claims aggregation? + +The August 14 support answer confirms CAWG identity claims aggregation +(ICA) support in `c2pa-rs` and reports an implementation using the Node +bindings. The implementer still needs to provide an aggregation service +that returns the COSE-signed verifiable credential; SDK support does not +supply that service. + +The answer links the Rust +[identity module](https://github.com/contentauth/c2pa-rs/tree/main/sdk/src/identity) +and its +[tests](https://github.com/contentauth/c2pa-rs/tree/main/sdk/src/identity/tests). +It does not confirm equivalent ICA support in the Swift or Python SDKs. + +[Source: Rust and Node ICA support and service responsibilities, August 14, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1537963403539390495) + +## How can I inspect CAWG certificate fields when common_name is missing? + +In May, support described using crJSON to inspect certificate issuer and +subject information when the ordinary CAWG signature report omitted +`common_name`: + +```sh +c2patool signed.jpg --crjson +``` + +The example places these fields under +`cawg.identity.signature.certificateInfo`, including `issuer`, `subject`, +and certificate validity dates. The follow-up confirmed that the common +name was visible through `--crjson`. + +This is a reporting workaround for the issue discussed at that time, not +evidence that the missing field has since been fixed. Reading a certificate +subject also does not establish that its identity is trusted. + +[Source: crJSON workaround, May 8, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1502369680118124555) + +[Source: certificate field structure, May 8, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1502369868396367913) + +[Source: workaround confirmation, May 8, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1502377614436995162) + +## Does a CAWG identity certificate need to chain to the C2PA Trust List? + +The August support answer distinguishes the two trust models. The C2PA +Trust List contains roots for claim-signing certificates issued to generator +products that have passed C2PA Conformance. CAWG X.509 identity certificates +use a different model. + +The answer describes CAWG's **interim** model at that time as using the +Mozilla Root Store and IPTC verified news publisher lists, and links +the [CAWG identity 1.3 X.509 trust model](https://cawg.io/identity/1.3/#_trust_model_for_x_509_certificates). +It also provides the +[Mozilla email-trust roots](https://ccadb.my.salesforce-sites.com/mozilla/IncludedRootsPEMTxt?TrustBitsInclude=Email) +and the IPTC +[end-entity](https://trust.iptc.org/end-entity-list.pem) and +[anchor](https://trust.iptc.org/anchor-list.pem) lists. + +Do not equate C2PA product trust with CAWG identity trust, or treat the +historical interim model as an independently verified current policy. + +An April General-channel answer describes S/MIME certificates as a common +CAWG X.509 choice, including individual-validated, sponsor-validated, and +organization-validated certificates. Having a government-issued identity +certificate does not by itself answer whether it meets CAWG's requirements; +check the CAWG X.509 trust model rather than the C2PA product Trust List. +The reply did not determine whether the questioner's particular certificate +qualified. + +[Source: distinct C2PA and CAWG X.509 trust models, August 20, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1540009285424119868) + +[Source: CAWG certificate types and separate identity role, April 1, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1488868534166749375) + +## Why can CAWG identity remain untrusted when the claim signer is trusted? + +CAWG trust anchors need separate SDK configuration. Trust in the C2PA claim +signer does not automatically establish trust in the identity assertion. +The August troubleshooting answer identifies two possible causes: no CAWG +anchors configured by the validator, or a CAWG certificate that does not +chain to the anchors that validator uses. + +Inspect the validation result's assertion URL to determine whether +`signingCredential.untrusted` refers to `cawg.identity` rather than the claim +signature. A successful signature or well-formedness check is not a +substitute for the identity trust check. + +In September, a fix was reported merged to make the supplied CAWG trust +lists usable by `c2pa-rs` and C2PA Tool. A later test in the same discussion +confirmed that one SSL.com CAWG certificate showed as trusted when the +Mozilla Root Store was configured. That result is specific to the tested +certificate and configuration. It does not show that every validator ships +those anchors, that every certificate from that issuer is trusted, or which +released tool version first included the fix. + +An earlier workaround manually trusted individual leaf certificates. +That local workaround is not evidence that other certificates sharing a +root will be trusted, nor does it define an authoritative CAWG trust policy. + +[Source: possible validator configuration causes, August 24, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1541459686690267136) + +[Source: separate configuration and local leaf workaround, September 7, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1546545082130370620) + +[Source: merged trust-list fix report, September 10, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1547575185790603264) + +[Source: configured-root test result, September 10, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1547641280048275550) + +## Are there source-linked guides for CAWG on mobile? + +The October 16 announcement reports CAWG X.509 support for captured photos +and videos in a Proofmode Android release. It links a +[user guide](https://proofmode.org/cawg_user_guide) describing a workflow +using SSL.com identity-validated certificates. + +A companion message links the +[CAWG mobile SDK developer guide](https://opensource.contentauthenticity.org/docs/cawg-mobile). +These are resources shared in the export, not independently reviewed +instructions or a guarantee of support across all mobile SDKs, certificate +authorities, or identity mechanisms. + +[Source: Android implementation and user guide announcement, October 16, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1560673010854264932) + +[Source: mobile developer guide, October 16, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1560673133684457494) + +## What should I use instead of CreativeWork for creator-related data? + +For the manifest reviewed on August 31, support recommended CAWG assertions +instead of `stds.schema-org.CreativeWork`, pointing to the CAWG identity +assertion and CAWG metadata assertion at [cawg.io](https://cawg.io). + +This is a recommendation about representing the data in that workflow, not +a claim that switching assertion labels automatically verifies an identity +or makes a signing certificate trusted. Identity trust must still be +evaluated separately. + +[Source: CAWG identity and metadata recommendation, August 31, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1543982994082238568) diff --git a/docs/technical-faqs/tech-faq-certificates.md b/docs/technical-faqs/tech-faq-certificates.md new file mode 100644 index 00000000..9fe3120e --- /dev/null +++ b/docs/technical-faqs/tech-faq-certificates.md @@ -0,0 +1,181 @@ +# Certificate FAQs + +These answers are based on the 45 messages in the exported CAI Certificate +Questions Discord history, covering April 4 through September 7, 2026. The +export supports six useful answered topics, selected for actionable guidance +rather than a measured frequency ranking. It includes a thread-creation +notice, but no body of that thread is available in this export. + +Certificate issuance, conformance, and trust guidance reflect those +discussions and have not been independently checked against current policy, +releases, or external sources. Discord source links may require server +membership and channel access. + +Selected answers also draw on the General channel history from April through +October 2026, with the same source-only, unverified status. + +## How can an implementation obtain a broadly recognized signing certificate? + +The April and July support answers identify C2PA generator conformance as +the route to a signing certificate intended for broad recognition by +validators. After passing conformance, a generator can obtain a conforming +product certificate from a certificate authority whose root is on the +C2PA Trust List. This is guidance about recognized trust, not a statement +that signing bytes is technically impossible without conformance. + +The July description of the process starts with a completed implementation +and an expression of interest, followed by a legal agreement and intake +form. It then calls for a Generator Product Security Architecture Document +and Diagram, plus signed interoperability samples. + +The reply links the [C2PA Conformance page](https://c2pa.org/conformance/) +and the +[Generator Product Security Requirements](https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Generator%20Product%20Security%20Requirements.pdf). +These describe the route discussed in July 2026; the export does not +establish current issuance timelines, pricing, or universal acceptance by +every validator. + +[Source: conformance route, April 6, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1490787978065219744) + +[Source: generator and CA-root relationship, July 23, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1529960958108373043) + +[Source: initial application steps, July 23, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1529961067256610816) + +[Source: architecture and interoperability submissions, July 23, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1529961419376693379) + +[Source: conformance reference, July 23, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1529962433861390548) + +## Is a C2PA claim-signing certificate a creator identity certificate? + +Not in the model described by the May support reply. Trusted C2PA +claim-signing certificates are issued for conforming hardware or software +products, rather than to establish the creator's identity. + +The reply points creators to [CAWG](https://cawg.io), which complements +C2PA by attaching verified identity through a CAWG identity assertion in +the manifest. Treat the product-signing and identity roles separately; +obtaining a product certificate does not by itself establish who created, +edited, or published the content. + +[Source: product certificates versus creator identity, May 14, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1504655459725082675) + +## Does renewing an Interim Trust List certificate preserve its listing? + +The June support answer says renewal produces a new PEM and PEM hash, so +validators do not recognize the renewed certificate as the one on the +Interim Trust List (ITL). + +The follow-up also rejects treating that renewed certificate as the +certificate to add to the official C2PA Trust List after conformance. +Instead, passing conformance enables issuance of a conforming product +certificate from a CA with its root on the C2PA Trust List. + +This distinguishes the particular certificate recognized by the ITL from +the CA-root-based route described for the C2PA Trust List. The April +discussion reported that the ITL had been frozen at the start of 2026; +the export does not establish a current renewal or migration exception. + +[Source: renewal changes PEM recognition, June 16, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1516516354125987991) + +[Source: renewed certificate is not the C2PA Trust List route, June 16, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1516525716341264394) + +[Source: conforming product certificate issuance, June 16, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1516525798838767719) + +[Source: historical ITL freeze, April 6, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1490788225294536734) + +## Can conformance interoperability samples use a test certificate? + +Yes. In the June discussion, support said interoperability samples could +be signed with a test certificate or the renewed certificate being +discussed. + +Permission to use that certificate for samples is distinct from production +trust. The subsequent answer explicitly says the renewed certificate was +not the route to the official C2PA Trust List. + +[Source: certificates for interoperability samples, June 16, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1516516612000186498) + +[Source: production trust distinction, June 16, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1516525716341264394) + +## Which certificates should the signer include in x5chain? + +The September support guidance says to pass the certificate chain to the +signer in this order: **leaf first, then the intermediate CA certificate +(ICA), without the root**. The signer populates `x5chain` in the COSE +signature; the validator obtains the root from its trust list. + +The trust list is therefore not a replacement for supplying the signing +chain's intermediate. This guidance does not resolve the particular +reported mismatch between a leaf and its supplied intermediate. That +case was moved to private follow-up, with no confirmed diagnosis or fix +in the export. Do not infer that including an unrelated intermediate +will establish trust. + +[Source: chain order and root source, September 4, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1545416331376066621) + +[Source: private follow-up without published resolution, September 7, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1546538935709208576) + +## What trust-anchor configuration was recommended for a custom validator? + +The July support answer recommends concatenating the C2PA Trust List PEM +and C2PA TSA Trust List PEM, then passing the combined contents as +`trust_anchors` in the tool's `trust` settings. The recommendation includes +both claim-signing and timestamp-authority trust anchors. + +This is configuration guidance, not a guarantee that a particular asset +will be trusted or that an expired certificate's status is resolved merely +by adding a list. Cryptographic validity and trust remain separate checks. + +The person troubleshooting the asset reported already trying this +configuration. The next event is a thread-creation notice, not a confirmed +resolution. The exported channel history cannot establish why that +particular validation continued to fail. + +[Source: combined signing and timestamp trust anchors, July 9, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1524771146631872583) + +## Can a conforming product rotate its signing certificate and key? + +An August 12 implementer reply reports that, with Trufo, a product can +request a new certificate or rotate a certificate at any time, with APIs +available to automate the process. It links +[Trufo's certificate documentation](https://trufo.ai/documentation#certificates). + +This is provider-specific experience, not a published statement of every +CA's issuance rules or all conformance requirements for key rotation. The +export does not specify a universal rotation interval or a complete +key-management procedure. + +[Source: Trufo rotation and automation experience, August 12, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1537108990797025280) + +## What requirements apply to a C2PA credential issuer? + +The September 28 support reply distinguishes the certificate's technical +profile from the policy governing issuance by a trusted CA: + +- The specification's + [certificate profiles](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_certificate_profiles) + define the certificate profile acceptable as a signing credential. +- The + [C2PA Certificate Policy](https://github.com/c2pa-org/conformance-public/blob/main/docs/v0.2/C2PA%20Certificate%20Policy.pdf) + governs issuance by CAs with roots on the C2PA Trust List. + +Meeting the technical profile alone is not the same as establishing +recognized trust. The answer provides requirements references, not a +reference implementation of a credential-issuer service or a list of +required service endpoints. + +[Source: certificate profile versus CA issuance policy, September 28, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1554122925026840576) + +## Was a free production certificate option announced? + +On June 23, SSL.com announced a free tier for qualifying C2PA-conformant +generator products: an Assurance Level 1 claim-signing certificate valid +for one year and up to 10,000 trusted timestamps. The announcement links +[SSL.com's C2PA page](https://ssl.com/c2pa) for details and applications. + +This was a dated provider offer, not a guarantee of current pricing, +eligibility, availability, or renewal terms. It did not remove the +conformance prerequisite and was not an offer of an individual creator +identity certificate. + +[Source: provider free-tier announcement, June 23, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1519016971486761040) diff --git a/docs/technical-faqs/tech-faq-conformance.md b/docs/technical-faqs/tech-faq-conformance.md index 0e2ff938..8e702e40 100644 --- a/docs/technical-faqs/tech-faq-conformance.md +++ b/docs/technical-faqs/tech-faq-conformance.md @@ -6,6 +6,9 @@ verified against the latest requirements. Date-specific guidance reflects those discussions, not a guarantee of current program policy. Discord source links may require channel access. +Selected answers also draw on the General channel history from April through +October 2026, with the same source-only, unverified status. + ## How do I start the conformance process? Start with the [C2PA Conformance Program](https://c2pa.org/conformance/) @@ -56,6 +59,20 @@ its users. Product conformance alone does not establish each user's identity. [Source: product conformance and identity, August 12, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1537131310424784896) +## Does a conformance listing mean the public product already uses production certificates? + +Not necessarily. The May 23 General-channel reply explains that a product +can appear on the conforming products list before public launch. There can +also be a delay between listing and deploying a production certificate: +the selected CA must verify conformance and the applicant's legal identity. + +The reply explains a possible listing/deployment gap; it does not establish +the status of every named product in the discussion or make a beta +certificate trusted. Evaluate the certificate actually used to sign an +asset rather than inferring its trust from the product's listing alone. + +[Source: listing, launch, and certificate deployment distinction, May 23, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1507727660401295360) + ## Why does a generator application ask about validation? A generator that ingests assets and creates or appends manifests must invoke @@ -355,8 +372,15 @@ the `referenced_assertions` array of `cawg.identity`. This answers attribution and cryptographic protection; it does not claim that the assertion enforces a user's preference on downstream systems. +An August 11 General-channel reply also cautions that companies were not +reliably respecting training-and-mining assertions in practice. Treat the +assertion as a statement of preference, not a technical block on scraping +or a guarantee against undesired AI use. + [Source: gathered preference assertion and optional identity link, June 8, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1513597018038206725) +[Source: practical enforcement limitation, August 11, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1536753197203587175) + ## Can my organization's identity certificate identify all my users? Not through the CAWG X.509 method described in the August reply. Each user diff --git a/docs/technical-faqs/tech-faq-general.md b/docs/technical-faqs/tech-faq-general.md new file mode 100644 index 00000000..23eebfa8 --- /dev/null +++ b/docs/technical-faqs/tech-faq-general.md @@ -0,0 +1,99 @@ +# General FAQs + +These answers are based only on the 287 messages in the exported CAI General +Discord channel history, covering April 1 through October 21, 2026. They +have not been independently verified against external sources or current +releases. Dated implementation guidance and linked resources reflect those +discussions, not guarantees of current availability or compatibility. +Discord source links may require server membership and channel access. + +## Where can I find signed sample assets, including location and time examples? + +The April replies point to Proofmode's public +[Baseline repository](https://proofmode.org/baseline/), while warning that +much of its content used older C2PA 1.x support. Another reply suggests the +[`contentauth/example-assets` repository](https://github.com/contentauth/example-assets) +as a place to submit signed assets for testing. Neither answer promises a +complete, current conformance test suite. + +For location metadata, the Proofmode developer links the +[Android 3.0.2 release candidate](https://github.com/guardianproject/proofmode-android/releases/tag/3.0.2-RC-2) +and its use of `c2pa.metadata` to include geolocation as a created assertion. +Older conformance samples used `stds.exif`, described as deprecated but +still valid. A follow-up links the +[Kotlin metadata-generation code](https://github.com/guardianproject/proofmode-android/blob/main/android-libproofmode/src/main/java/org/witness/proofmode/c2pa/C2PAManager.kt#L840). + +These are source-provided examples and implementation pointers, not a +guarantee that every sample contains GPS and a timestamp, that their +certificates remain trusted, or that signed metadata proves the truth of +the depicted event. + +[Source: Baseline and older sample versions, April 3, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1489689553886384228) + +[Source: Android geolocation implementation, April 3, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1489689681653141634) + +[Source: older sample assertion format, April 3, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1489690080623726795) + +[Source: metadata-generation code, April 3, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1489690402805125372) + +[Source: shared signed-asset repository, April 3, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1489693250133430272) + +## How can I get started with Content Credentials on Android or iOS? + +For users, the April 4 support reply recommends installing a C2PA-enabled +camera app, giving Proofmode as an iOS example. This is app-based guidance, +not a statement that the built-in camera on every iPhone signs assets. + +For developers, the April and May replies recommend the open-source +[mobile SDKs](https://opensource.contentauthenticity.org/docs/mobile) +for Android and iOS rather than maintaining a new C2PA implementation. +SDK availability is distinct from the conformance or trust status of an +application built with it. + +[Source: iOS camera-app route, April 4, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1490063556698443877) + +[Source: Android library recommendation, April 3, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1489689175270625582) + +[Source: Android and iOS SDK resources, May 14, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1504547100493348884) + +## Can a manifest carry custom sensor or verification information? + +Yes. In response to a proposed sensor-noise extension, the April 20 answer +confirms that custom assertions can be added to a C2PA manifest. A validator +that understands that assertion could use its information to identify where +changes occurred. + +That is an extensibility mechanism, not endorsement of the proposal's +claimed security guarantees or a promise that existing validators understand +it. The follow-up about coordinating camera and editor implementations +was not resolved in the exported discussion. + +[Source: custom assertions and validator support, April 20, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1495831402938110155) + +## Where are embedding rules for TIFF-based and base-media file formats documented? + +The August 17 reply directs implementers to the **Embedded Formats annex** +of the +[Content Credentials specification](https://c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html). +It was answering a question about TIFF-based Sony formats and the +base-media-based Canon CR3 format. + +This is a specification pointer, not confirmation that every raw camera +format is supported by a particular SDK. The reply did not supply the +requested camera samples. + +[Source: Embedded Formats annex, August 17, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1538922552007589898) + +## Where can I report a CAI security concern? + +The October 19 support reply recommends the +[CAI contact form](https://contentauthenticity.org/contact) for something +that needs reporting. In the follow-up, support said the specific report +had been routed onward, but that the responder might not know its status. + +The discussion does not establish a dedicated security inbox, a response +deadline, or a promise of public status updates. + +[Source: reporting contact, October 19, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1561895003670716528) + +[Source: routing and status limitations, October 19, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1561895701028536405) diff --git a/docs/technical-faqs/tech-faq-node.md b/docs/technical-faqs/tech-faq-node.md new file mode 100644 index 00000000..a79b93f2 --- /dev/null +++ b/docs/technical-faqs/tech-faq-node.md @@ -0,0 +1,149 @@ +# Node.js SDK FAQs + +These answers are based on the 29 messages in the exported CAI Node SDK +Discord history, covering April through July 2026. The export supports five +useful questions, not ten independent answered topics. Questions are selected +for actionable guidance rather than a measured frequency ranking. + +Version-specific information reflects those discussions and has not been +independently checked against the latest release. Discord source links may +require channel access. + +## How do I configure created versus gathered assertions? + +Use `builder.created_assertion_labels` to identify the assertions attributed +to your claim generator. The April support reply provided this example: + +```js +const settings = { + builder: { + created_assertion_labels: [ + "c2pa.actions", + "c2pa.thumbnail.claim", + "c2pa.thumbnail.ingredient", + "c2pa.ingredient" + ] + } +}; +``` + +Choose labels that reflect your implementation; this is not a universal +conformance configuration. The reply explains that assertions were gathered +by default, except for the hard binding, which is always created. + +Use only **base assertion labels**, without version or instance suffixes. +For example, use `c2pa.ingredient`, not `c2pa.ingredient.v3`. The SDK +handles the version. + +Support also recommended updating to the latest release of the then-current +Node SDK because an earlier release had a bug. The discussion does not +identify the first release containing that fix. An upgrade does not replace +the need to configure assertion placement. + +[Source: assertion settings, April 2, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1489395644274839582) + +[Source: release guidance, April 2, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1489396659451592754) + +[Source: base labels, April 2, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1489400012369694912) + +## Which Node SDK package should I use instead of c2pa-node 0.5.26? + +The July 29 support reply identifies `c2pa-node` 0.5.26 as the final +release of the deprecated v1 Node SDK. It recommends migrating to +[`@contentauth/c2pa-node`](https://www.npmjs.com/package/@contentauth/c2pa-node), +which was at version 0.8.0 at the time. + +The replacement package is maintained in the +[`contentauth/c2pa-js` monorepo](https://github.com/contentauth/c2pa-js). +Do not treat 0.8.0 as a recommendation to pin that historical version today. + +The user who asked about trust-list configuration confirmed that migrating +to 0.8.0 enabled the trust settings shown in the next answer. + +[Source: package migration, July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532213791943692398) + +[Source: repository location, July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532213910495563867) + +[Source: successful migration, July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532235743022288977) + +## How do I configure signing-certificate and timestamp trust? + +The July support example loads the C2PA Trust List and C2PA TSA Trust List, +combines their PEM contents, and enables both trust checks. With those PEM +strings already loaded as `c2paTrustList` and `c2paTsaTrustList`, pass the +settings to both the reader and builder: + +```js +const settings = { + trust: { + trust_anchors: c2paTrustList + c2paTsaTrustList, + }, + verify: { + verify_trust: true, + verify_timestamp_trust: true, + }, +}; + +const reader = await Reader.fromAsset({ path: "photo.jpg" }, settings); +const builder = Builder.withJson({ title: "photo.jpg" }, settings); +``` + +This is a configuration excerpt, not a complete program: it assumes the +reader and builder bindings are imported and the PEM contents have been +fetched or read. It comes from the replacement package discussed above, +not the deprecated `c2pa-node` 0.5.26 API. + +[Source: reader and builder trust settings, July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532214117342122025) + +[Source: user confirmation, July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532235743022288977) + +## Should I pass a PEM file path or its contents as trust anchors? + +Pass the **PEM contents as a string**. In the April troubleshooting +discussion, support advised replacing a file path with the actual PEM +data. After inspecting the code, support identified C2PA Tool's +`load_trust_resource()` as a convenience for loading PEM data from a path +or URL; that behavior should not be assumed for the Node SDK. + +The `loadSettingsFromFile()` function mentioned in that discussion loads +the whole settings file. It is not evidence that an individual trust-anchor +setting accepts a PEM path. + +The later July example also supplies PEM strings through +`trust.trust_anchors`. The April thread does not include a confirmed +resolution for the particular Adobe-signed asset being tested, so do not +assume that changing the input format resolves every trust failure. + +[Source: PEM contents, April 4, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1490086610321145876) + +[Source: settings-file distinction, April 4, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1490087412364218409) + +[Source: C2PA Tool convenience method, April 4, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1490090813227536416) + +[Source: later PEM-string example, July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532214117342122025) + +## Does a Valid validation state mean that the signer is trusted? + +No. The July support reply distinguishes three manifest states: +**well-formed**, **valid**, and **trusted**. Trusted manifests are also +valid, and valid manifests are also well-formed. The reverse does not follow. + +A user testing the replacement SDK with trust verification enabled reported +a `Valid` state for a test certificate while +`validation_results.activeManifest.failure` contained +`signingCredential.untrusted`. Support confirmed that the report's overall +state follows the manifest-state model. + +Do not label a manifest trusted merely because its state is `Valid`. +Inspect the trust-related validation results, and distinguish trust that +was not evaluated from a failed trust check. An issuer name alone does +not establish trust. + +See the source-linked +[manifest states specification](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_manifest_states). + +[Source: valid-but-untrusted result, July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532235743022288977) + +[Source: state hierarchy, July 30, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532378030276612178) + +[Source: specification reference, July 30, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532378218420633610) diff --git a/docs/technical-faqs/tech-faq-rust.md b/docs/technical-faqs/tech-faq-rust.md index fc7a69b9..31bdc98f 100644 --- a/docs/technical-faqs/tech-faq-rust.md +++ b/docs/technical-faqs/tech-faq-rust.md @@ -1,9 +1,14 @@ -# Technical FAQ +# FAQ: Rust library -These answers are based on discussions in the CAI Rust SDK Discord channel -from April through October 2026. Version-specific information reflects those -discussions and has not been independently checked against the latest release. -Discord source links may require channel access. +These FAQs are based on discussions in the CAI Rust SDK Discord channel from 2026. +In some cases, the information may be specific to a particular version of the SDK. Always confirm using the latest release. + +Selected answers also draw on the General channel history from April through +October 2026; those additions have not been externally verified. + +:::note +Discord source links require a Discord account and joining the public CAI Discord server. +::: ## Can I configure trust anchors using a URL? @@ -80,6 +85,19 @@ verify that it still applies to the edited asset. [Source: gathered-assertion clarification, October 14, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1560080821287657594) +An October 15 General-channel troubleshooting reply also recommends edit +intent when an existing asset produces +`assertion.action.malformed: first action must be created or opened` +or `assertion.action.ingredientMismatch`. In that case, the manually defined +`actions` were not nested inside `assertions`, and the workflow also needed +a referenced `parentOf` ingredient. The user confirmed that switching to +edit intent worked. Do not assume an "Invalid Manifest" error is a trust +problem without inspecting its validation details. + +[Source: action structure and edit-intent fix, October 15, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1560317418574839849) + +[Source: successful result, October 15, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1560344798165074072) + ## How do I add timestamps for existing ingredient manifests? Enable automatic timestamp assertions. The support discussion provided @@ -192,3 +210,35 @@ When reading an asset, explicitly provide the corresponding sidecar using `--external-manifest`. [Source: September 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1549894561537466399) + +## Why does manifest compression barely reduce a long existing chain? + +The October 15 support reply explains that compression applies to the +current manifest being written, not retroactively to every manifest in an +existing chain. To compare compressed and uncompressed chains, enable +`prefer_compress_manifests` while writing each generation. + +Support tested ten manifests containing a repetitive text custom assertion. +The final manifest-store size was 154,638 bytes without compression and +52,583 bytes with compression enabled at each generation. The responder +explicitly cautioned that repetitive test data would likely compress better +than real-world content. This is not a promised compression ratio or a way +to shrink all prior manifests by appending one compressed manifest. + +[Source: compression scope and test recommendation, October 15, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1560358414264172585) + +[Source: controlled comparison and data caveat, October 15, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1560370962875285566) + +## Can I use the Rust implementation from a JVM backend? + +The September 14 reply points to the Rust implementation's +[C API](https://github.com/contentauth/c2pa-rs/tree/main/c2pa_c_ffi) as an +integration route through JNI. + +The responder said a Kotlin library had been discussed, but development +had focused on Android-specific needs. Forking the Android bindings for a +JVM service was suggested as possible work, not offered as an existing, +maintained JVM package. The export does not establish a supported Java +binding or provide a complete JNI integration example. + +[Source: Android scope and C API integration route, September 14, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1549054456258240674) diff --git a/sidebars.js b/sidebars.js index a17718db..1141a1eb 100644 --- a/sidebars.js +++ b/sidebars.js @@ -143,16 +143,41 @@ const sidebars = { label: 'Technical FAQs', collapsed: true, items: [ + { + type: 'doc', + id: 'technical-faqs/tech-faq-general', + label: 'General FAQs', + }, { type: 'doc', id: 'technical-faqs/tech-faq-rust', label: 'Rust SDK FAQ', }, + { + type: 'doc', + id: 'technical-faqs/tech-faq-node', + label: 'Node.js SDK FAQs', + }, + { + type: 'doc', + id: 'technical-faqs/tech-faq-c2pa-tool', + label: 'C2PA Tool FAQs', + }, { type: 'doc', id: 'technical-faqs/tech-faq-conformance', label: 'C2PA Conformance FAQs', }, + { + type: 'doc', + id: 'technical-faqs/tech-faq-cawg', + label: 'CAWG Standard FAQs', + }, + { + type: 'doc', + id: 'technical-faqs/tech-faq-certificates', + label: 'Certificate FAQs', + }, ], }, { From c9d31e25fce2d7f075790f6cf4e9aab911c30b57 Mon Sep 17 00:00:00 2001 From: Rand McKinney Date: Fri, 23 Oct 2026 16:50:26 -0700 Subject: [PATCH 3/3] Extensive edits --- docs/technical-faqs/faqs-to-review.md | 56 +-- docs/technical-faqs/index.md | 21 + docs/technical-faqs/tech-faq-c2pa-tool.md | 198 ++++----- docs/technical-faqs/tech-faq-cawg.md | 157 +++---- docs/technical-faqs/tech-faq-certificates.md | 169 +++----- docs/technical-faqs/tech-faq-conformance.md | 406 ++++++++----------- docs/technical-faqs/tech-faq-general.md | 128 +++--- docs/technical-faqs/tech-faq-node.md | 125 ++---- docs/technical-faqs/tech-faq-rust.md | 178 +++----- sidebars.js | 9 +- 10 files changed, 606 insertions(+), 841 deletions(-) create mode 100644 docs/technical-faqs/index.md diff --git a/docs/technical-faqs/faqs-to-review.md b/docs/technical-faqs/faqs-to-review.md index 349c0579..31e91935 100644 --- a/docs/technical-faqs/faqs-to-review.md +++ b/docs/technical-faqs/faqs-to-review.md @@ -1,11 +1,17 @@ +--- +hide_table_of_contents: true +--- + +import TOCInline from '@theme/TOCInline'; + # Technical FAQ topics for review -These editorial notes capture unresolved or time-sensitive topics from the -CAI Rust SDK Discord history covering April through October 2026. They are -not confirmed FAQ answers. Verify each topic before publishing guidance. -Discord source links may require channel access. +These editorial notes are not confirmed FAQ answers. Verify each topic +before publishing guidance. + + -## Verification website reports invalid content that the SDK reports as trusted +### Verification website reports invalid content that the SDK reports as trusted **Candidate question:** Why does a verification website reject an asset that the SDK reports as trusted? @@ -23,13 +29,13 @@ Before publication: - Do not present incomplete website support as the cause of every validation discrepancy. -[Source: initial guidance, April 7, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1491238678410821784) +Sources: -[Source: SDK validation result, April 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1494485332010209350) +- [Initial guidance; April 7, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1491238678410821784) +- [SDK validation result; April 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1494485332010209350) +- [Pending website support information; April 20, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1495872312413655162) -[Source: pending website support information, April 20, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1495872312413655162) - -## Server-side assertion validation with a remote signer +### Server-side assertion validation with a remote signer **Candidate question:** How can a remote signer validate assertion values before signing without receiving the asset bytes? @@ -52,15 +58,14 @@ Before publication: - Obtain authoritative guidance on the applicable conformance requirements; do not infer that client authentication alone is sufficient. -[Source: proposed approach, August 10, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1536422380207996989) - -[Source: API limitations, August 11, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1536634968212774962) - -[Source: security architecture, August 11, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1536713305916440648) +Sources: -[Source: conformance referral, August 17, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1538923231476457533) +- [Proposed approach; August 10, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1536422380207996989) +- [API limitations; August 11, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1536634968212774962) +- [Security architecture; August 11, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1536713305916440648) +- [Conformance referral; August 17, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1538923231476457533) -## Rust SDK 1.0 release timeline +### Rust SDK 1.0 release timeline **Candidate question:** When will the Rust SDK reach 1.0? @@ -70,9 +75,9 @@ This is a dated roadmap response, not a permanent FAQ answer. Before publication, check current release information and obtain an approved roadmap statement from the team. -[Source: June 8, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1513639744167219280) +Source: [June 8, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1513639744167219280) -## Build failure caused by a yanked dependency +### Build failure caused by a yanked dependency **Candidate question:** What should I do about the yanked dependency build failure? @@ -89,9 +94,9 @@ Before publication: - Check how existing lockfiles affect reproducibility. - Prefer a dated troubleshooting notice over an evergreen FAQ entry. -[Source: October 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1560738950807687341) +Source: [October 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1560738950807687341) -## Ingredient digital source type and remote-signer certificate chains +### Ingredient digital source type and remote-signer certificate chains **Candidate questions:** @@ -110,11 +115,12 @@ Before publication, verify each PR's status, identify the first release containing the change, and test a minimal example of the reported behavior. Treat these as separate FAQ entries if both remain useful. -[Source: ingredient field, May 4, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1500953348722131055) +Sources: -[Source: certificate-chain parsing, May 4, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1500953982431133827) +- [Ingredient field; May 4, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1500953348722131055) +- [Certificate-chain parsing; May 4, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1500953982431133827) -## Building the C SDK for 32-bit Windows +### Building the C SDK for 32-bit Windows **Candidate question:** How do I build the C SDK for 32-bit Windows? @@ -125,4 +131,4 @@ of a C2PA Tool version mismatch does not resolve this separate build issue. Before publication, confirm supported targets and toolchain requirements, reproduce the build, and verify the architecture of the resulting DLL. -[Source: April 21, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1496248252767670272) +Source: [April 21, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1496248252767670272) diff --git a/docs/technical-faqs/index.md b/docs/technical-faqs/index.md new file mode 100644 index 00000000..a20ddf9f --- /dev/null +++ b/docs/technical-faqs/index.md @@ -0,0 +1,21 @@ +--- +hide_table_of_contents: true +--- + +# Technical FAQs + +- [General FAQs](./tech-faq-general.md) +- [Rust library FAQs](./tech-faq-rust.md) +- [C2PA Tool FAQs](./tech-faq-c2pa-tool.md) +- [Node.js library FAQs](./tech-faq-node.md) +- [Claim-signing certificate FAQs](./tech-faq-certificates.md) +- [CAWG identity FAQs](./tech-faq-cawg.md) +- [C2PA conformance FAQs](./tech-faq-conformance.md) + +These FAQs are derived from discussions in the [public CAI Discord server](https://discord.gg/CAI) from the latter part of 2026. + +Always check the version of the library that you're using and if possible use the latest version to get the latest features anb bug fixes. + +:::note +Links to source Discord messages require a Discord account and joining the [public CAI Discord server](https://discord.gg/CAI). +::: diff --git a/docs/technical-faqs/tech-faq-c2pa-tool.md b/docs/technical-faqs/tech-faq-c2pa-tool.md index 1a5eb2c3..1b230496 100644 --- a/docs/technical-faqs/tech-faq-c2pa-tool.md +++ b/docs/technical-faqs/tech-faq-c2pa-tool.md @@ -1,21 +1,16 @@ -# C2PA Tool FAQs +--- +hide_table_of_contents: true +--- -These answers are based on the 69 messages in the exported CAI C2PA Tool -Discord history, covering April 1 through October 8, 2026. The export supports -eight useful answered topics, selected for actionable guidance rather than -a measured frequency ranking. +import TOCInline from '@theme/TOCInline'; -Behavior and version information reflect those discussions and have not been -independently checked against the latest releases or external sources. -Discord source links may require server membership and channel access. +# C2PA Tool FAQs -Selected answers also draw on the General channel history from April through -October 2026, with the same source-only, unverified status. + -## How can I inspect a file locally from the command line? +### How can I inspect a file locally using C2PA Tool? -The September 11 General-channel answer recommends the open-source C2PA -Tool CLI for inspecting a file on your own machine: +Use the open-source C2PA Tool CLI to inspect a file on your own machine: ```sh c2patool file.jpg --detailed @@ -23,102 +18,96 @@ c2patool file.jpg --detailed This avoids uploading the asset to a web inspection service. It is not a promise that every configuration or operation is network-free; for example, -the trust initialization command below fetches trust lists. Local +the trust initialization command fetches trust lists. Local inspection also does not by itself establish that the signer is trusted or that the depicted content is true. -[Source: local CLI inspection command, September 11, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1548138360139419719) - -## Does C2PA Tool load trust lists automatically? +Source: [Local CLI inspection command; September 11, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1548138360139419719) -The answer changed during the exported period. In April 2026, support said -the C2PA Trust List was not loaded automatically and showed how to supply -trust anchors through settings or the command line. +### How do I load trust lists with C2PA Tool? -On June 19, support announced a command to fetch or update trust lists and -store them for future calls: +You have to initialize trust lists explicitly. Earlier versions required supplying trust +anchors through settings or the command line. Use `c2patool init trust` to fetch or update trust lists and store them for future calls: ```sh c2patool init trust ``` -The announcement says trust sidecars are loaded automatically on subsequent -runs from the same directory as the settings file. This describes behavior -after initialization, not an assurance that an unconfigured installation -already has current trust lists. +Use a raw PEM URL when supplying a trust-anchor link. -For ingredient validation during signing, the May guidance specifically -called for configuring both the C2PA Trust List and C2PA TSA Trust List. +For more control, pass a settings file with `--settings`; TOML settings are +passed through to the SDK. Supply the concatenated CA and TSA lists when needed to include TSA intermediate certificates. +Trust sidecars are loaded automatically on subsequent runs from the same +directory as the settings file. -[Source: explicit trust configuration, April 1, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1488985307343884348) +For ingredient validation during signing, configure both the C2PA Trust List +and C2PA TSA Trust List. -[Source: trust initialization, June 19, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1517556047324250223) +Sources: -[Source: ingredient and timestamp trust, May 27, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1509239917262405742) +- [Explicit trust configuration; April 1, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1488985307343884348) +- [Trust initialization; June 19, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1517556047324250223) +- [Ingredient and timestamp trust; May 27, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1509239917262405742) +- [Raw PEM URL; August 6, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1534942946212708522) +- [Initialization command; August 6, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1534943626499719369) +- [Settings option; August 6, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1534945015598678176) +- [Persistence and concatenated lists; August 6, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1534995351101116646) -## Does a new manifest automatically inherit its parent's title? +### Does a new manifest automatically inherit its parent's title? -In the April discussion, support said there was no automatic assignment of -the `parentOf` ingredient's title to the new claim's `dc:title`. Without an -explicit title in the manifest definition, the output filename was used. +No. The `parentOf` ingredient's title is not automatically assigned to the +new claim's `dc:title`. Without an explicit title in the manifest definition, +the output filename is used. Set the desired title in the new manifest definition rather than relying on -inheritance. The follow-up confirmed that supplying the title this way -worked. This sets the active manifest's title; changing an ingredient's +inheritance. This sets the active manifest's title; changing an ingredient's title is a separate operation. -[Source: default title behavior, April 7, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1491244347075727431) +Sources: -[Source: explicit title confirmation, April 30, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1499462978687209482) +- [Default title behavior; April 7, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1491244347075727431) +- [Explicit title confirmation; April 30, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1499462978687209482) -## How can I override an ingredient's title? +### How can I override an ingredient's title? -The April support answer describes exporting a signed asset as an ingredient -using the `--ingredient` option. The resulting folder contains ingredient -JSON, a thumbnail, and the manifest binary. Edit the title in the ingredient -JSON, then reference the folder through `ingredient_paths` in the new -manifest definition: +Export a signed asset as an ingredient using the `--ingredient` option. +The resulting folder contains ingredient JSON, a thumbnail, and the manifest binary. Edit the title in the ingredient JSON, then reference the folder through `ingredient_paths` in the new manifest definition like this: ```json "ingredient_paths": ["./ingredient-folder"] ``` -This is a field excerpt, not a complete JSON document. The follow-up -confirmed that this workflow worked. +Sources: -[Source: ingredient export and title workflow, April 30, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1499513543291305995) +- [Ingredient export and title workflow; April 30, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1499513543291305995) +- [Successful result; May 1, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1499846501948456980) -[Source: successful result, May 1, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1499846501948456980) +### Does the overall validation state describe only the active manifest? -## Does the overall validation state describe only the active manifest? - -No. In the May discussion, support clarified that `validation_state` also -considers ingredient deltas. An earlier suggestion that an ingredient -failure should not affect the overall state was superseded by this -explanation after inspecting the code. +No. `validation_state` also considers ingredient deltas, so an ingredient +failure can affect the overall state. For the active manifest alone, inspect the success, informational, and failure arrays in `validation_results.activeManifest`. Do not interpret an aggregate `Invalid` result as proof that the active manifest itself has a signature failure. -Support recommended displaying each manifest's state independently and -distinguishing valid-but-untrusted manifests from trusted ones. That is +Display each manifest's state independently and distinguish +valid-but-untrusted manifests from trusted ones. That is presentation guidance, not a rule that cryptographic validity establishes signer trust. -[Source: aggregate state clarification, May 27, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1509250331320778864) - -[Source: active-manifest results, May 28, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1509555410921590835) +Sources: -[Source: ingredient deltas, May 28, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1509555776585465907) +- [Aggregate state clarification; May 27, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1509250331320778864) +- [Active-manifest results; May 28, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1509555410921590835) +- [Ingredient deltas; May 28, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1509555776585465907) +- [Per-manifest presentation guidance; May 27, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1509374914510196737) -[Source: per-manifest presentation guidance, May 27, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1509374914510196737) +### How do I supply my own thumbnail? -## How do I supply my own thumbnail? - -The August support answer shows a `thumbnail` object in the manifest -definition. Its `identifier` is a file path relative to the manifest +Add a `thumbnail` object to the manifest definition. Its `identifier` is +a file path relative to the manifest definition file: ```json @@ -129,40 +118,21 @@ definition file: ``` This is a field excerpt to include in a complete manifest definition. -The source command was: +For example: ```sh c2patool sample.mp4 -m manifest.json -o sample-signed.mp4 ``` -Support said the same approach can define ingredient thumbnails. This +Use the same approach to define ingredient thumbnails. This provides an explicit thumbnail; it does not explain or promise automatic thumbnail generation for every input format. -[Source: custom thumbnails and relative paths, August 31, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1543975786468352150) - -## Why might an HEIC thumbnail not appear in Verify? - -The September answer separates signing from display. For the reported -thumbnail format being changed to `application/octet-stream`, support -advised using a v2 claim, either by setting `claim_version` to `2` or by -omitting it when v2 was the default. The follow-up confirmed that this -resolved the reported signing issue. - -Display also depends on browser support. At the time, support reported -that `image/heic` thumbnails displayed in macOS Safari but not Chrome. -A correctly embedded thumbnail therefore did not guarantee display in -every browser. These observations are historical, not a current browser -compatibility matrix. - -[Source: v2 claims and browser-dependent display, September 1, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1544362081107578961) +Source: [custom thumbnails and relative paths, August 31, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1543975786468352150) -[Source: successful result, September 2, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1544907804417064970) +### How can I sign a TIFF sample and configure created assertions? -## How can I sign a TIFF sample and configure created assertions? - -The September support reply confirmed TIFF reading and writing and supplied -this example: +C2PA Tool supports reading and writing TIFF files. For example: ```sh c2patool sample.tiff \ @@ -171,14 +141,13 @@ c2patool sample.tiff \ --output signed.tiff ``` -For that command, support said the source asset becomes a `parentOf` +For that command, the source asset becomes a `parentOf` ingredient and the tool automatically adds the `c2pa.opened` action. -The reply also allowed omitting settings when using the default key and -certificate; it did not establish that those defaults are trusted or -qualify a product for conformance. +You can omit settings when using the default key and certificate, but do +not assume those defaults are trusted or qualify a product for conformance. When the implementation needs to designate created rather than gathered -assertions, the follow-up supplied this settings excerpt: +assertions, use settings such as: ```toml [builder] @@ -189,22 +158,35 @@ created_assertion_labels = [ ] ``` -Select the assertions appropriate to the implementation. This is a signing -example, not a complete conformance procedure or universal configuration. +This is just an example. Select the assertions appropriate to the implementation. + +Sources: + +- [TIFF signing command and defaults; September 15, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1549488757898616973) +- [Created assertion settings; September 15, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1549489530598588417) + +### Why does C2PA Tool behave differently when launched by my application versus on the command-line? + +Check the **actual executable and version** your application launches, +rather than only the version available in your terminal. -[Source: TIFF signing command and defaults, September 15, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1549488757898616973) +For example in the reported case, the application launched C2PA Tool **0.26.1**, +although the user expected **0.26.41**. Launching 0.26.41 resolved the +missing timestamp assertion. -[Source: created assertion settings, September 15, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1549489530598588417) +Source: [confirmed resolution, April 22, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1496644840786624614) -## Where is the C2PA Tool source repository? +### Can I create sidecar manifests for unsupported file types? + +Yes. To read the asset with its sidecar, use: + +```sh +c2patool file.obj --external-manifest file.c2pa +``` -The September 10 announcement says the CLI source moved out of `c2pa-rs` -into the separate -[`contentauth/c2patool` repository](https://github.com/contentauth/c2patool). -The stated purpose was to allow CLI changes without versioning the Rust -SDK and to avoid confusion between their version numbers. +Sources: -The announcement explicitly said this move did not change how to install -or use the tool. +- [Implementation; September 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1549892485080293416) +- [Read command; September 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1549898982988455988) +- [User confirmation; September 17, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1550145681090412695) -[Source: repository move, September 10, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1547708360432812152) diff --git a/docs/technical-faqs/tech-faq-cawg.md b/docs/technical-faqs/tech-faq-cawg.md index be56e249..73336d1d 100644 --- a/docs/technical-faqs/tech-faq-cawg.md +++ b/docs/technical-faqs/tech-faq-cawg.md @@ -1,149 +1,126 @@ -# CAWG Standard FAQs +--- +hide_table_of_contents: true +--- -These answers are based on the 41 messages in the exported CAI CAWG Standard -Discord history, covering May 1 through October 16, 2026. The export supports -five useful answered topics, selected for actionable guidance rather than -a measured frequency ranking. +import TOCInline from '@theme/TOCInline'; -Version, implementation, and trust-model information reflect those -discussions and have not been independently checked against the latest -releases or external sources. Discord source links may require server -membership and channel access. +# CAWG identity FAQs -Selected answers also draw on the General channel history from April through -October 2026, with the same source-only, unverified status. + -## Does c2pa-rs support identity claims aggregation? +### Does c2pa-rs support identity claims aggregation? -The August 14 support answer confirms CAWG identity claims aggregation -(ICA) support in `c2pa-rs` and reports an implementation using the Node -bindings. The implementer still needs to provide an aggregation service -that returns the COSE-signed verifiable credential; SDK support does not +Yes. `c2pa-rs` supports CAWG identity claims aggregation (ICA), with an +implementation also using the Node bindings. You still need to provide an aggregation service that returns the COSE-signed verifiable credential; SDK support does not supply that service. -The answer links the Rust -[identity module](https://github.com/contentauth/c2pa-rs/tree/main/sdk/src/identity) -and its -[tests](https://github.com/contentauth/c2pa-rs/tree/main/sdk/src/identity/tests). -It does not confirm equivalent ICA support in the Swift or Python SDKs. +See the Rust [identity module](https://github.com/contentauth/c2pa-rs/tree/main/sdk/src/identity) +and its [tests](https://github.com/contentauth/c2pa-rs/tree/main/sdk/src/identity/tests). +Equivalent ICA support in the Swift or Python SDKs is not confirmed here. -[Source: Rust and Node ICA support and service responsibilities, August 14, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1537963403539390495) +Source: [Rust and Node ICA support and service responsibilities; August 14, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1537963403539390495) -## How can I inspect CAWG certificate fields when common_name is missing? +### How can I inspect CAWG certificate fields when common_name is missing? -In May, support described using crJSON to inspect certificate issuer and -subject information when the ordinary CAWG signature report omitted -`common_name`: +Use crJSON to inspect certificate issuer and subject information when +the ordinary CAWG signature report omits `common_name`: ```sh c2patool signed.jpg --crjson ``` -The example places these fields under -`cawg.identity.signature.certificateInfo`, including `issuer`, `subject`, -and certificate validity dates. The follow-up confirmed that the common -name was visible through `--crjson`. +The example places these fields under `cawg.identity.signature.certificateInfo`, including `issuer`, `subject`, and certificate validity dates. The common name is visible through `--crjson`. -This is a reporting workaround for the issue discussed at that time, not +This is a reporting workaround for the issue observed in May 2026, not evidence that the missing field has since been fixed. Reading a certificate subject also does not establish that its identity is trusted. -[Source: crJSON workaround, May 8, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1502369680118124555) +Sources: -[Source: certificate field structure, May 8, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1502369868396367913) +- [CrJSON workaround; May 8, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1502369680118124555) +- [Certificate field structure; May 8, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1502369868396367913) +- [Workaround confirmation; May 8, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1502377614436995162) -[Source: workaround confirmation, May 8, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1502377614436995162) +### Does a CAWG identity certificate need to chain to the C2PA Trust List? -## Does a CAWG identity certificate need to chain to the C2PA Trust List? - -The August support answer distinguishes the two trust models. The C2PA -Trust List contains roots for claim-signing certificates issued to generator +No. The C2PA Trust List contains roots for claim-signing certificates issued to generator products that have passed C2PA Conformance. CAWG X.509 identity certificates use a different model. -The answer describes CAWG's **interim** model at that time as using the -Mozilla Root Store and IPTC verified news publisher lists, and links -the [CAWG identity 1.3 X.509 trust model](https://cawg.io/identity/1.3/#_trust_model_for_x_509_certificates). -It also provides the -[Mozilla email-trust roots](https://ccadb.my.salesforce-sites.com/mozilla/IncludedRootsPEMTxt?TrustBitsInclude=Email) -and the IPTC -[end-entity](https://trust.iptc.org/end-entity-list.pem) and +As of August 2026, CAWG's **interim** model used the Mozilla Root Store and +IPTC verified news publisher lists. See the +[CAWG identity 1.3 X.509 trust model](https://cawg.io/identity/1.3/#_trust_model_for_x_509_certificates), +the [Mozilla email-trust roots](https://ccadb.my.salesforce-sites.com/mozilla/IncludedRootsPEMTxt?TrustBitsInclude=Email) and the IPTC [end-entity](https://trust.iptc.org/end-entity-list.pem) and [anchor](https://trust.iptc.org/anchor-list.pem) lists. Do not equate C2PA product trust with CAWG identity trust, or treat the historical interim model as an independently verified current policy. -An April General-channel answer describes S/MIME certificates as a common -CAWG X.509 choice, including individual-validated, sponsor-validated, and +S/MIME certificates are a common CAWG X.509 choice, including +individual-validated, sponsor-validated, and organization-validated certificates. Having a government-issued identity certificate does not by itself answer whether it meets CAWG's requirements; check the CAWG X.509 trust model rather than the C2PA product Trust List. -The reply did not determine whether the questioner's particular certificate -qualified. -[Source: distinct C2PA and CAWG X.509 trust models, August 20, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1540009285424119868) +Sources: -[Source: CAWG certificate types and separate identity role, April 1, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1488868534166749375) +- [Distinct C2PA and CAWG X.509 trust models; August 20, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1540009285424119868) +- [CAWG certificate types and separate identity role; April 1, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1488868534166749375) -## Why can CAWG identity remain untrusted when the claim signer is trusted? +### Why can CAWG identity remain untrusted when the claim signer is trusted? CAWG trust anchors need separate SDK configuration. Trust in the C2PA claim signer does not automatically establish trust in the identity assertion. -The August troubleshooting answer identifies two possible causes: no CAWG -anchors configured by the validator, or a CAWG certificate that does not -chain to the anchors that validator uses. +Two possible causes are that the validator did not configure CAWG anchors, or using a CAWG certificate that does not chain to the anchors that validator uses. Inspect the validation result's assertion URL to determine whether `signingCredential.untrusted` refers to `cawg.identity` rather than the claim signature. A successful signature or well-formedness check is not a substitute for the identity trust check. -In September, a fix was reported merged to make the supplied CAWG trust -lists usable by `c2pa-rs` and C2PA Tool. A later test in the same discussion -confirmed that one SSL.com CAWG certificate showed as trusted when the -Mozilla Root Store was configured. That result is specific to the tested -certificate and configuration. It does not show that every validator ships -those anchors, that every certificate from that issuer is trusted, or which -released tool version first included the fix. +Sources: -An earlier workaround manually trusted individual leaf certificates. -That local workaround is not evidence that other certificates sharing a -root will be trusted, nor does it define an authoritative CAWG trust policy. +- [Possible validator configuration causes; August 24, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1541459686690267136) +- [Separate configuration and local leaf workaround; September 7, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1546545082130370620) +- [Merged trust-list fix report; September 10, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1547575185790603264) +- [Configured-root test result; September 10, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1547641280048275550) -[Source: possible validator configuration causes, August 24, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1541459686690267136) +### Are there source-linked guides for CAWG on mobile? -[Source: separate configuration and local leaf workaround, September 7, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1546545082130370620) +For a Proofmode Android workflow using CAWG X.509 assertions and SSL.com +identity-validated certificates with captured photos and videos, see the +[user guide](https://proofmode.org/cawg_user_guide). This functionality was +available in a Proofmode Android release in October 2026. -[Source: merged trust-list fix report, September 10, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1547575185790603264) +For SDK integration, see the [CAWG mobile SDK developer guide](../cawg-mobile.mdx). +These resources are not independently reviewed instructions or a guarantee of support across all mobile SDKs, certificate authorities, or identity mechanisms. -[Source: configured-root test result, September 10, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1547641280048275550) +Sources: -## Are there source-linked guides for CAWG on mobile? +- [Android implementation and user guide announcement; October 16, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1560673010854264932) +- [Mobile developer guide; October 16, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1560673133684457494) -The October 16 announcement reports CAWG X.509 support for captured photos -and videos in a Proofmode Android release. It links a -[user guide](https://proofmode.org/cawg_user_guide) describing a workflow -using SSL.com identity-validated certificates. +### What should I use instead of CreativeWork for creator-related data? -A companion message links the -[CAWG mobile SDK developer guide](https://opensource.contentauthenticity.org/docs/cawg-mobile). -These are resources shared in the export, not independently reviewed -instructions or a guarantee of support across all mobile SDKs, certificate -authorities, or identity mechanisms. +Use CAWG identity and metadata assertions instead of `stds.schema-org.CreativeWork` for creator-related data. See +[cawg.io](https://cawg.io). Identity trust must still be evaluated separately. -[Source: Android implementation and user guide announcement, October 16, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1560673010854264932) +Source: [CAWG identity and metadata recommendation; August 31, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1543982994082238568) -[Source: mobile developer guide, October 16, 2026](https://discord.com/channels/983153151341371422/1273777445551603714/1560673133684457494) +### Can my organization's identity certificate identify all my users? -## What should I use instead of CreativeWork for creator-related data? +No. With the CAWG X.509 method, each user +would need a CAWG certificate issued with that user's own name or organization. +Your organization's certificate asserts your organization's identity, not +the identities of all its users. Consider **Identity Claims Aggregation** +for platforms. -For the manifest reviewed on August 31, support recommended CAWG assertions -instead of `stds.schema-org.CreativeWork`, pointing to the CAWG identity -assertion and CAWG metadata assertion at [cawg.io](https://cawg.io). +Becoming a C2PA CA is a separate role: issuing signing certificates to +conforming products. To attach artist, creator, or publisher identity, use the +[CAWG identity assertion](https://cawg.io/identity/1.3/), using an X.509 +certificate or Identity Claims Aggregation. -This is a recommendation about representing the data in that workflow, not -a claim that switching assertion labels automatically verifies an identity -or makes a signing certificate trusted. Identity trust must still be -evaluated separately. +Sources: -[Source: CAWG identity and metadata recommendation, August 31, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1543982994082238568) +- [Per-user X.509 identity; August 13, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1537519938552733766) +- [CA versus creator identity; October 9, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1558191343988117524) \ No newline at end of file diff --git a/docs/technical-faqs/tech-faq-certificates.md b/docs/technical-faqs/tech-faq-certificates.md index 9fe3120e..4354fa41 100644 --- a/docs/technical-faqs/tech-faq-certificates.md +++ b/docs/technical-faqs/tech-faq-certificates.md @@ -1,156 +1,119 @@ -# Certificate FAQs +--- +hide_table_of_contents: true +--- -These answers are based on the 45 messages in the exported CAI Certificate -Questions Discord history, covering April 4 through September 7, 2026. The -export supports six useful answered topics, selected for actionable guidance -rather than a measured frequency ranking. It includes a thread-creation -notice, but no body of that thread is available in this export. +import TOCInline from '@theme/TOCInline'; -Certificate issuance, conformance, and trust guidance reflect those -discussions and have not been independently checked against current policy, -releases, or external sources. Discord source links may require server -membership and channel access. +# Claim-signing certificate FAQs -Selected answers also draw on the General channel history from April through -October 2026, with the same source-only, unverified status. + -## How can an implementation obtain a broadly recognized signing certificate? +### How can an implementation obtain a broadly recognized signing certificate? -The April and July support answers identify C2PA generator conformance as -the route to a signing certificate intended for broad recognition by -validators. After passing conformance, a generator can obtain a conforming +Pass C2PA generator conformance to obtain a signing certificate intended +for broad recognition by validators. After passing conformance, a generator can obtain a conforming product certificate from a certificate authority whose root is on the -C2PA Trust List. This is guidance about recognized trust, not a statement -that signing bytes is technically impossible without conformance. +C2PA Trust List. -The July description of the process starts with a completed implementation -and an expression of interest, followed by a legal agreement and intake -form. It then calls for a Generator Product Security Architecture Document -and Diagram, plus signed interoperability samples. +The process starts with a completed implementation and an +expression of interest, followed by a legal agreement and intake form. +Prepare a Generator Product Security Architecture Document and Diagram, +plus signed interoperability samples. -The reply links the [C2PA Conformance page](https://c2pa.org/conformance/) -and the -[Generator Product Security Requirements](https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Generator%20Product%20Security%20Requirements.pdf). -These describe the route discussed in July 2026; the export does not -establish current issuance timelines, pricing, or universal acceptance by -every validator. +See [C2PA conformance program](../conformance/index.mdx) for more information. -[Source: conformance route, April 6, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1490787978065219744) +### Is a C2PA claim-signing certificate the same as a creator identity certificate? -[Source: generator and CA-root relationship, July 23, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1529960958108373043) - -[Source: initial application steps, July 23, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1529961067256610816) - -[Source: architecture and interoperability submissions, July 23, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1529961419376693379) - -[Source: conformance reference, July 23, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1529962433861390548) - -## Is a C2PA claim-signing certificate a creator identity certificate? - -Not in the model described by the May support reply. Trusted C2PA +No. Trusted C2PA claim-signing certificates are issued for conforming hardware or software products, rather than to establish the creator's identity. -The reply points creators to [CAWG](https://cawg.io), which complements -C2PA by attaching verified identity through a CAWG identity assertion in -the manifest. Treat the product-signing and identity roles separately; -obtaining a product certificate does not by itself establish who created, -edited, or published the content. +Use [CAWG](https://cawg.io), which complements C2PA by attaching verified identity through a CAWG identity assertion in the manifest. Treat the product-signing and identity roles separately; +obtaining a product certificate does not by itself establish who created, edited, or published the content. -[Source: product certificates versus creator identity, May 14, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1504655459725082675) +Source: [Product certificates versus creator identity; May 14, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1504655459725082675) -## Does renewing an Interim Trust List certificate preserve its listing? +### Does renewing an Interim Trust List certificate preserve its listing? -The June support answer says renewal produces a new PEM and PEM hash, so +No. Renewal produces a new PEM and PEM hash, so validators do not recognize the renewed certificate as the one on the Interim Trust List (ITL). -The follow-up also rejects treating that renewed certificate as the -certificate to add to the official C2PA Trust List after conformance. +Do not treat the renewed certificate as the certificate to add to the +official C2PA Trust List after conformance. Instead, passing conformance enables issuance of a conforming product certificate from a CA with its root on the C2PA Trust List. This distinguishes the particular certificate recognized by the ITL from -the CA-root-based route described for the C2PA Trust List. The April -discussion reported that the ITL had been frozen at the start of 2026; -the export does not establish a current renewal or migration exception. - -[Source: renewal changes PEM recognition, June 16, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1516516354125987991) +the CA-root-based route for the C2PA Trust List. The ITL was frozen at the +start of 2026; do not assume a current renewal or migration exception exists. -[Source: renewed certificate is not the C2PA Trust List route, June 16, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1516525716341264394) +Sources: -[Source: conforming product certificate issuance, June 16, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1516525798838767719) +- [Renewal changes PEM recognition; June 16, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1516516354125987991) +- [Renewed certificate is not the C2PA Trust List route; June 16, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1516525716341264394) +- [Conforming product certificate issuance; June 16, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1516525798838767719) +- [Historical ITL freeze; April 6, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1490788225294536734) -[Source: historical ITL freeze, April 6, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1490788225294536734) +### Can conformance interoperability samples use a test certificate? -## Can conformance interoperability samples use a test certificate? - -Yes. In the June discussion, support said interoperability samples could -be signed with a test certificate or the renewed certificate being -discussed. +Yes. Sign interoperability samples with a test certificate. A renewed ITL +certificate can also be used for these samples. Permission to use that certificate for samples is distinct from production -trust. The subsequent answer explicitly says the renewed certificate was -not the route to the official C2PA Trust List. +trust. A renewed ITL certificate is not the route to the official C2PA Trust List. -[Source: certificates for interoperability samples, June 16, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1516516612000186498) +Sources: -[Source: production trust distinction, June 16, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1516525716341264394) +- [Certificates for interoperability samples; June 16, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1516516612000186498) +- [Production trust distinction; June 16, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1516525716341264394) -## Which certificates should the signer include in x5chain? +### Which certificates should the signer include in x5chain? -The September support guidance says to pass the certificate chain to the -signer in this order: **leaf first, then the intermediate CA certificate +Pass the certificate chain to the signer in this order: +**leaf first, then the intermediate CA certificate (ICA), without the root**. The signer populates `x5chain` in the COSE signature; the validator obtains the root from its trust list. The trust list is therefore not a replacement for supplying the signing -chain's intermediate. This guidance does not resolve the particular -reported mismatch between a leaf and its supplied intermediate. That -case was moved to private follow-up, with no confirmed diagnosis or fix -in the export. Do not infer that including an unrelated intermediate -will establish trust. +chain's intermediate. Ensure the intermediate belongs to the leaf's chain; +including an unrelated intermediate will not establish trust. Chain order +alone does not diagnose every leaf/intermediate mismatch. -[Source: chain order and root source, September 4, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1545416331376066621) +Sources: -[Source: private follow-up without published resolution, September 7, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1546538935709208576) +- [Chain order and root source; September 4, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1545416331376066621) +- [Private follow-up without published resolution; September 7, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1546538935709208576) -## What trust-anchor configuration was recommended for a custom validator? +### What trust-anchor configuration was recommended for a custom validator? -The July support answer recommends concatenating the C2PA Trust List PEM -and C2PA TSA Trust List PEM, then passing the combined contents as -`trust_anchors` in the tool's `trust` settings. The recommendation includes +Concatenate the C2PA Trust List PEM and C2PA TSA Trust List PEM, then pass +the combined contents as `trust_anchors` in the tool's `trust` settings. Include both claim-signing and timestamp-authority trust anchors. This is configuration guidance, not a guarantee that a particular asset will be trusted or that an expired certificate's status is resolved merely by adding a list. Cryptographic validity and trust remain separate checks. -The person troubleshooting the asset reported already trying this -configuration. The next event is a thread-creation notice, not a confirmed -resolution. The exported channel history cannot establish why that -particular validation continued to fail. - -[Source: combined signing and timestamp trust anchors, July 9, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1524771146631872583) +Source: [combined signing and timestamp trust anchors, July 9, 2026](https://discord.com/channels/983153151341371422/1276934105858314404/1524771146631872583) -## Can a conforming product rotate its signing certificate and key? +### Can a conforming product rotate its signing certificate and key? -An August 12 implementer reply reports that, with Trufo, a product can -request a new certificate or rotate a certificate at any time, with APIs -available to automate the process. It links +With Trufo, a product can request a new certificate or rotate a certificate +at any time, with APIs available to automate the process. See [Trufo's certificate documentation](https://trufo.ai/documentation#certificates). This is provider-specific experience, not a published statement of every CA's issuance rules or all conformance requirements for key rotation. The -export does not specify a universal rotation interval or a complete -key-management procedure. +applicable rotation interval and key-management procedure depend on your +provider and product requirements. -[Source: Trufo rotation and automation experience, August 12, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1537108990797025280) +Source: [Trufo rotation and automation experience, August 12, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1537108990797025280) -## What requirements apply to a C2PA credential issuer? +### What requirements apply to a C2PA credential issuer? -The September 28 support reply distinguishes the certificate's technical -profile from the policy governing issuance by a trusted CA: +Distinguish the certificate's technical profile from the policy governing +issuance by a trusted CA: - The specification's [certificate profiles](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_certificate_profiles) @@ -160,17 +123,17 @@ profile from the policy governing issuance by a trusted CA: governs issuance by CAs with roots on the C2PA Trust List. Meeting the technical profile alone is not the same as establishing -recognized trust. The answer provides requirements references, not a +recognized trust. These are requirements references, not a reference implementation of a credential-issuer service or a list of required service endpoints. -[Source: certificate profile versus CA issuance policy, September 28, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1554122925026840576) +Source: [certificate profile versus CA issuance policy, September 28, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1554122925026840576) -## Was a free production certificate option announced? +### Was a free production certificate option announced? -On June 23, SSL.com announced a free tier for qualifying C2PA-conformant +As of June 23, 2026, SSL.com offered a free tier for qualifying C2PA-conformant generator products: an Assurance Level 1 claim-signing certificate valid -for one year and up to 10,000 trusted timestamps. The announcement links +for one year and up to 10,000 trusted timestamps. See [SSL.com's C2PA page](https://ssl.com/c2pa) for details and applications. This was a dated provider offer, not a guarantee of current pricing, @@ -178,4 +141,4 @@ eligibility, availability, or renewal terms. It did not remove the conformance prerequisite and was not an offer of an individual creator identity certificate. -[Source: provider free-tier announcement, June 23, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1519016971486761040) +Source: [provider free-tier announcement, June 23, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1519016971486761040) diff --git a/docs/technical-faqs/tech-faq-conformance.md b/docs/technical-faqs/tech-faq-conformance.md index 8e702e40..188f0ff4 100644 --- a/docs/technical-faqs/tech-faq-conformance.md +++ b/docs/technical-faqs/tech-faq-conformance.md @@ -1,40 +1,38 @@ -# C2PA Conformance FAQs +--- +hide_table_of_contents: true +--- -These answers are based on discussions in the CAI C2PA conformance Discord -channel from April through October 2026. They have not been independently -verified against the latest requirements. Date-specific guidance reflects -those discussions, not a guarantee of current program policy. Discord source -links may require channel access. +import TOCInline from '@theme/TOCInline'; -Selected answers also draw on the General channel history from April through -October 2026, with the same source-only, unverified status. +# C2PA conformance FAQs -## How do I start the conformance process? + -Start with the [C2PA Conformance Program](https://c2pa.org/conformance/) -and its expression of interest form. The September 30, 2026 support reply -also linked the [program document](https://github.com/c2pa-org/conformance-public/blob/main/docs/v0.2/C2PA%20Conformance%20Program.pdf). - -That reply explains that a generator product must pass conformance before -obtaining a signing certificate from a CA with its root on the C2PA Trust -List. Test certificates can be used while preparing for evaluation; they -are not equivalent to trusted production credentials. +### How do I start the conformance process? -[Source: certificate prerequisite, September 30, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1554850060112498779) +Start with the [C2PA Conformance Program](https://c2pa.org/conformance/) +and its expression of interest form. See the +[program document](https://github.com/c2pa-org/conformance-public/blob/main/docs/v0.2/C2PA%20Conformance%20Program.pdf) +for details. -[Source: program document, September 30, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1554850126449737808) +A generator product must pass conformance before it can +obtain a signing certificate from an CA that has a root cert on the C2PA Trust List. +You can use test certificates while preparing for evaluation; however, they +are not trusted production credentials. -[Source: expression of interest form, September 30, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1554850450874834964) +Sources: -[Source: evaluation certificates, September 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1547716234173222962) +- [Certificate prerequisite; September 30, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1554850060112498779) +- [Program document; September 30, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1554850126449737808) +- [Expression of interest form; September 30, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1554850450874834964) +- [Evaluation certificates; September 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1547716234173222962) -## How do I follow up on an application or correct its media types? +### How do I follow up on an application or correct its media types? Contact the conformance administrator at **conformance@c2pa.org** for application-specific issues. For a missing response to an expression of interest, provide the representative email address used in the submission. -The July discussion identified a contact problem that was subsequently -resolved; it does not establish a guaranteed response time. +There is no guaranteed response time. If a generator application incorrectly omits validation capabilities, request a revision listing both the input media types it validates and the output @@ -42,38 +40,33 @@ media types it generates. For example, a product could validate JPEG and PNG ingredients while generating signed JPEG, PNG, WebP, and AVIF assets. Declare your actual capabilities, not this example's list. -[Source: application follow-up, July 2, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1522236996553146399) +Sources: -[Source: resolution, July 2, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1522288127408865310) +- [Application follow-up; July 2, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1522236996553146399) +- [Resolution; July 2, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1522288127408865310) +- [Correcting media types; June 21, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1518382298482081872) -[Source: correcting media types, June 21, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1518382298482081872) - -## Does conformance apply to the product or to each end user? +### Does conformance apply to the product or to each end user? Conformance is associated with a generator or validator product, whether software or hardware, rather than an individual user. -Creator identity is a separate concern. The support reply recommends a -separately signed CAWG identity assertion when a product needs to identify -its users. Product conformance alone does not establish each user's identity. +Creator identity is a separate concern. Use a separately-signed CAWG identity assertion when a product needs to identify its users. Product conformance alone does not establish a user's identity. -[Source: product conformance and identity, August 12, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1537131310424784896) +Source: [Product conformance and identity; August 12, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1537131310424784896) -## Does a conformance listing mean the public product already uses production certificates? +### Does a conformance listing mean the public product already uses production certificates? -Not necessarily. The May 23 General-channel reply explains that a product -can appear on the conforming products list before public launch. There can +Not necessarily. A product can appear on the conforming products list +before public launch. There can also be a delay between listing and deploying a production certificate: the selected CA must verify conformance and the applicant's legal identity. -The reply explains a possible listing/deployment gap; it does not establish -the status of every named product in the discussion or make a beta -certificate trusted. Evaluate the certificate actually used to sign an -asset rather than inferring its trust from the product's listing alone. +Listing alone does not make a beta certificate trusted. Evaluate the certificate actually used to sign an asset rather than inferring its trust from the product's listing alone. -[Source: listing, launch, and certificate deployment distinction, May 23, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1507727660401295360) +Source: [Listing, launch, and certificate deployment distinction; May 23, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1507727660401295360) -## Why does a generator application ask about validation? +### Why does a generator application ask about validation? A generator that ingests assets and creates or appends manifests must invoke validation logic against the C2PA CA and TSA Trust Lists as part of that @@ -81,162 +74,126 @@ process. Its declared **validate** media types describe those inputs; its **generate** media types describe the outputs for which it creates manifests. This ingredient validation is distinct from applying as a standalone -validator product. The July reply describes a validator product as one that -validates assets without generating manifests. An August reply advises -applying separately as a validator product when also building a verification -tool. +validator product, which validates assets without generating manifests. +Apply separately as a validator product if you are also building a +verification tool. -[Source: generator validation scope, July 16, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1527310749628891176) +Sources: -[Source: separate verification tool, August 12, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1537127081672974486) +- [Generator validation scope; July 16, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1527310749628891176) +- [Separate verification tool; August 12, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1537127081672974486) -## How do I choose between backend, distributed, and separate product submissions? +### How do I choose between backend, distributed, and separate product submissions? A distributed generator can divide asset generation, assertions, claim generation, and signing between edge and backend subsystems while functioning -as one product. The August guidance describes mutual authentication between -the subsystems and a backend check that the caller is a valid instance of +as one product. Use mutual authentication between the subsystems and a +backend check that the caller is a valid instance of the edge subsystem. -The May guidance says cooperating subsystems might be submitted as one -distributed product, while components that independently generate assets, +Cooperating subsystems might be submitted as one distributed product, +while components that independently generate assets, claims, and signatures would probably require separate submissions. Do not classify a customer-hosted component solely by whether it runs on a -server. For that case, support did not give a definitive classification. +server. Classification requires an assessment of the architecture. Submit an architecture summary and diagram to conformance@c2pa.org, identifying the **Target of Evaluation**, the components included in the generator -product, and how objects submitted for signing are authenticated. The -discussion also flags dependency vulnerability scanning as a potential -challenge for customer-hosted deployments. - -[Source: cooperating subsystems, May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504810186504671304) - -[Source: independent generators, May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504810688638484660) - -[Source: distributed authentication, August 27, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1542545382997893230) - -[Source: customer-hosted architecture caveats, August 27, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1542586446815170750) - -[Source: definitive assessment requires an architecture, August 28, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1542842626947154031) +product, and how objects submitted for signing are authenticated. +Dependency vulnerability scanning requirements can also be a challenge for +customer-hosted deployments. -## Does using the latest SDK make my product conformant? +Sources: -No. The May support reply generally recommends using the latest SDK, but -explicitly says that SDKs are tools for building products and must be used -in a conformant way. It does not specify a minimum SDK version. +- [Cooperating subsystems; May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504810186504671304) +- [Independent generators; May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504810688638484660) +- [Distributed authentication; August 27, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1542545382997893230) +- [Customer-hosted architecture caveats; August 27, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1542586446815170750) +- [Definitive assessment requires an architecture; August 28, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1542842626947154031) -Preparation checks highlighted in the discussion include: +### Does using the latest SDK make my product conformant? -- Configure created versus gathered assertions deliberately. -- Use `c2pa.created` and `c2pa.opened` appropriately. Do not describe an - existing asset uploaded by a user as newly created by your product. -- Validate ingredients with the C2PA Trust List configured. +No. Use the latest SDK, but remember that SDKs are tools for building +products and must be used in a conformant way. Conformance also covers areas beyond software implementation, such as security architecture and key management practices. You also have to submit interoperability test assets as part of the conformance process. -Interoperability test assets are provided as part of the conformance process. +Some common problem areas to check include: -[Source: test assets, May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504806955154280601) +- Configuring created versus gathered assertions deliberately. +- Using `c2pa.created` and `c2pa.opened` appropriately. Do not describe an + existing asset uploaded by a user as newly-created by your product. +- Validating ingredients with the C2PA Trust List configured. -[Source: SDK recommendation and limitation, May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504807032341925918) +Sources: -[Source: preparation checks, May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504807213145784443) +- [Test assets; May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504806955154280601) +- [SDK recommendation and limitation; May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504807032341925918) +- [Preparation checks; May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504807213145784443) -## How do I configure trust for ingredient validation? +### How do I configure trust for ingredient validation? -The support guidance recommends loading both the -[C2PA Trust List](https://raw.githubusercontent.com/c2pa-org/conformance-public/refs/heads/main/trust-list/C2PA-TRUST-LIST.pem) -and the -[C2PA TSA Trust List](https://raw.githubusercontent.com/c2pa-org/conformance-public/refs/heads/main/trust-list/C2PA-TSA-TRUST-LIST.pem). +Load both the [C2PA Trust List](https://raw.githubusercontent.com/c2pa-org/conformance-public/refs/heads/main/trust-list/C2PA-TRUST-LIST.pem) +and the [C2PA TSA Trust List](https://raw.githubusercontent.com/c2pa-org/conformance-public/refs/heads/main/trust-list/C2PA-TSA-TRUST-LIST.pem). Fetch their PEM contents, concatenate them, and supply the resulting PEM string through `trust.trust_anchors`. For SDK integrations, pass the settings to the builder through a context. -The May 23 follow-up replaces an earlier thread-local settings example, -noting that thread-local settings had been deprecated. +Do not use deprecated thread-local settings. -The August clarification says that the C2PA Trust List alone may appear to -work for timestamp trust because the lists share roots. It still recommends -including the TSA list to pick up intermediate CA certificates. This is +The C2PA Trust List alone may appear to work for timestamp trust because +the lists share roots. Include the TSA list to pick up intermediate CA +certificates. This is trust-anchor configuration guidance, not a complete answer to every certificate-expiration or point-in-time validation scenario. -[Source: PEM configuration, May 22, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1507426136596942962) - -[Source: context-based follow-up, May 23, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1507741760820871250) - -[Source: TSA intermediate certificates, August 19, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1539661485234724864) - -## How do I load trust lists in C2PA Tool? - -Use a raw PEM URL rather than a GitHub file-view page when supplying a -trust-anchor link. - -The August 6 replies explain that `c2patool init trust` loads, updates, and -stores the C2PA Trust List for reuse in subsequent commands unless overridden. -For more control, pass a settings file with `--settings`; TOML settings are -passed through to the SDK. Support also suggests supplying the concatenated -CA and TSA lists when needed to include TSA intermediate certificates. - -See the source-linked -[trust settings walkthrough](https://learn.contentauthenticity.org/signing-an-edited-image). - -[Source: raw PEM URL, August 6, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1534942946212708522) - -[Source: initialization command, August 6, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1534943626499719369) - -[Source: settings option, August 6, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1534945015598678176) +Sources: -[Source: persistence and concatenated lists, August 6, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1534995351101116646) +- [PEM configuration; May 22, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1507426136596942962) +- [Context-based follow-up; May 23, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1507741760820871250) +- [TSA intermediate certificates; August 19, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1539661485234724864) -## Which timestamp endpoints were recommended for C2PA trust? +### Which timestamp endpoints are recommended for C2PA trust? -On August 10, 2026, support identified these SSL.com endpoints as free for -general use with roots on the C2PA TSA Trust List: +As of August 10, 2026, these SSL.com endpoints are free for general use +with roots on the C2PA TSA Trust List: - `http://ts-c2pa.ssl.com/rsa` - `http://ts-c2pa.ssl.com/ecc` -Another participant linked -[Trufo timestamping documentation](https://trufo.ai/documentation#timestamping), -noting that its service required payment and authentication. +Trufo's service requires payment and authentication. See the +[Trufo timestamping documentation](https://trufo.ai/documentation#timestamping). -These are dated service recommendations, not a guarantee of current -availability, pricing, or trust-list membership. +Sources: -[Source: SSL.com endpoints, August 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1536414294198059132) +- [SSL.com endpoints; August 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1536414294198059132) +- [Trufo documentation; August 11, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1536747888305242223) +- [Trufo access conditions; August 11, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1536748051287248998) -[Source: Trufo documentation, August 11, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1536747888305242223) +### Can evaluation samples use test certificates and still report untrusted? -[Source: Trufo access conditions, August 11, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1536748051287248998) - -## Can evaluation samples use test certificates and still report untrusted? - -Yes. The September guidance permits SDK test certificates, CA-provided test -certificates, or certificates you generate yourself, but explicitly says -the evaluation signing certificates cannot be self-signed. Do not interpret +Yes. Use SDK test certificates, CA-provided test certificates, or +certificates you generate yourself, but evaluation signing certificates +cannot be self-signed. Do not interpret "generate your own" as permission to use a self-signed signing certificate. -The reply links +See the [SDK test certificates](https://github.com/contentauth/c2pa-rs/tree/main/sdk/tests/fixtures/certs) and a [certificate creation walkthrough](https://learn.contentauthenticity.org/private-keys-and-certificates). -The October 9 clarification says `signingCredential.untrusted` is normal +Getting a `signingCredential.untrusted` error is normal before obtaining a conforming product certificate and does not itself prevent -passing conformance. This does not excuse other failures or prove that the -rest of an implementation is correct. - -[Source: evaluation certificate constraints, September 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1547716234173222962) +passing conformance. -[Source: certificate creation walkthrough, September 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1547720168149352558) +Sources: -[Source: SDK fixtures, September 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1547720257018269826) +- [Evaluation certificate constraints; September 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1547716234173222962) +- [Certificate creation walkthrough; September 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1547720168149352558) +- [SDK fixtures; September 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1547720257018269826) +- [Expected untrusted status; October 9, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1558172948022698065) -[Source: expected untrusted status, October 9, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1558172948022698065) +### Does adding a trusted manifest remove warnings about earlier untrusted manifests? -## Does adding a trusted manifest remove warnings about earlier untrusted manifests? - -Do not assume that it does. The September reply explains that validators -generally show a notice when an asset contains manifests signed with +Do not assume that it does. Validators generally show a notice when an +asset contains manifests signed with untrusted certificates. The notice may apply to individual manifests, the manifest store, or both, depending on the validator. @@ -248,12 +205,12 @@ untrusted private CA will produce `signingCredential.untrusted`. This explains a trust-display consequence of a mixed pipeline. It is not a blanket ruling that every trusted/untrusted pipeline is prohibited. -[Source: mixed-pipeline trust behavior, September 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1547716234173222962) +Source: [Mixed-pipeline trust behavior; September 10, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1547716234173222962) -## How do I put the actions assertion in created assertions? +### How do I put the actions assertion in created assertions? Configure `builder.created_assertion_labels` using **base assertion labels**. -For the Node bindings, support provided: +For the Node bindings, use: ```js const settings = { @@ -268,170 +225,137 @@ const builder = Builder.withJson(manifestDefinition, settings); Use `c2pa.actions`, not `c2pa.actions.v2`. Likewise, do not include assertion instance suffixes such as those in `c2pa.ingredient.v3__2`. -With only `c2pa.actions` in that setting, the support reply says that the -actions assertion and the automatically created hard binding are created +With only `c2pa.actions` in that setting, the actions assertion and the +automatically created hard binding are created assertions; other assertions are gathered. Add other base labels as appropriate for your implementation. This is not a universal conformance configuration. -The August user follow-up confirmed the setting worked, but noted that the -Reader output flattened created and gathered assertions into one list. -They inspected the raw claim bytes to verify placement. - -[Source: base labels and automatic hard binding, August 19, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1539665498835517531) +As of August 2026, the Reader output flattened created and gathered +assertions into one list. Inspect the raw claim bytes to verify placement +if your version has this limitation. -[Source: successful verification and Reader limitation, August 19, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1539705852968177734) +Sources: -[Source: Node settings, September 2, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1544696112101728396) +- [Base labels and automatic hard binding; August 19, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1539665498835517531) +- [Successful verification and Reader limitation; August 19, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1539705852968177734) +- [Node settings; September 2, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1544696112101728396) +- [Passing settings to the builder; September 2, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1544696724411645972) -[Source: passing settings to the builder, September 2, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1544696724411645972) +### Should ingredient assertions be created or gathered? -## Should ingredient assertions be created or gathered? - -The July support reply recommends marking an ingredient assertion as created -in most cases because the claim generator validates it. This is +Mark an ingredient assertion as created in most cases because the claim +generator validates it. This is implementation-dependent guidance, not a statement that every assertion associated with an input asset must be created. Configure assertion placement deliberately rather than relying on the -SDK default described in the May discussion, which placed assertions other -than the hard binding in gathered assertions. +SDK default, which places assertions other than the hard binding in +gathered assertions. -[Source: ingredient recommendation, July 9, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1524768241518641272) +Sources: -[Source: SDK default, May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504807213145784443) +- [Ingredient recommendation; July 9, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1524768241518641272) +- [SDK default; May 15, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1504807213145784443) -## What does digitalSourceType describe, and when is it needed? +### What does digitalSourceType describe, and when is it needed? -The July clarification says that `digitalSourceType` describes the nature +The `digitalSourceType` property describes the nature of how an **action** was performed, such as human, AI, or algorithmic activity. -It is not one asset-wide value to copy unchanged through every edit. The -reply also notes that C2PA 2.4 allows it to describe an ingredient. +It is not one asset-wide value to copy unchanged through every edit. +C2PA 2.4 also allows it to describe an ingredient. -The same discussion says actions affecting the asset's editorial nature need +Actions affecting the asset's editorial nature need a digital source type, whereas an unbound watermarking action does not. An original asset should still be referenced as the ingredient associated with `c2pa.opened`; that action does not require a digital source type. -The August clarification explicitly states that `c2pa.created` requires an -appropriate `digitalSourceType` in both C2PA 2.2 and 2.4. It links the +`c2pa.created` requires an appropriate `digitalSourceType` in both C2PA 2.2 +and 2.4. See the [specification requirement](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_mandatory_presence_of_at_least_one_actions_assertion) and section 2.4 of the [Additional Conformance Requirements](https://github.com/c2pa-org/conformance-public/blob/main/docs/v0.2/Additional%20Conformance%20Requirements%20Against%20the%20Content%20Credentials%20Specification.pdf). Do not infer that the field is optional merely because an older validator did not report its absence. -[Source: action and ingredient semantics, July 14, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1526686021004296334) - -[Source: editorial actions, July 14, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1526686436689055785) +Sources: -[Source: opened action and ingredient, July 14, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1526686633561428018) +- [Action and ingredient semantics; July 14, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1526686021004296334) +- [Editorial actions; July 14, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1526686436689055785) +- [Opened action and ingredient; July 14, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1526686633561428018) +- [Created action requirement; August 20, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1540014008319610961) -[Source: created action requirement, August 20, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1540014008319610961) +### How should I describe visible and invisible watermarking? -## How should I describe visible and invisible watermarking? - -For invisible watermarking, support recommends `c2pa.watermarked.bound` +For invisible watermarking, use `c2pa.watermarked.bound` or `c2pa.watermarked.unbound`, depending on whether a `c2pa.soft-binding` assertion is used with it. -For a visible logo, the reply recommends representing it as a `componentOf` +For a visible logo, represent it as a `componentOf` ingredient and recording `c2pa.placed` with a parameter referencing that -ingredient. For a text-only visible watermark, it suggests considering +ingredient. For a text-only visible watermark, consider `c2pa.addedText`. -These recommendations replace the question's proposed blanket mapping of -visible watermarking to `c2pa.edited` with a `composite` source type. +Do not map all visible watermarking to `c2pa.edited` with a `composite` +source type. -[Source: watermarking guidance, July 9, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1524768241518641272) +Source: [Watermarking guidance; July 9, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1524768241518641272) -## Which action describes publishing an already signed asset? +### Which action describes publishing an already signed asset? -For the marketplace publishing scenario discussed in May, support recommends -`c2pa.published`, together with any other actions that actually occurred. -It means the asset is released to a wider audience. The reply explicitly -says there is no `c2pa.signed` action. +Use `c2pa.published` when releasing an asset to a wider audience, together +with any other actions that actually occurred. There is no `c2pa.signed` +action. Use the [official action definitions](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_actions) to describe the operation, rather than inventing an action solely because another signature was produced. -[Source: publication action, May 17, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1505616834148303099) +Source: [Publication action; May 17, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1505616834148303099) -## How should I represent a user's training and mining preferences? +### How should I represent a user's training and mining preferences? -For the discussed seller opt-out workflow, support confirms that -`cawg.training-mining` belongs in gathered assertions. It remains -cryptographically protected there, but is not attributable to the C2PA claim +For a seller opt-out workflow, put `cawg.training-mining` in gathered +assertions. It remains cryptographically protected there, but is not attributable to the C2PA claim generator or signer. -The reply accepts that placement under the manifest signature. If you want +This placement is covered by the manifest signature. If you want to connect the preference to a CAWG identity, reference the assertion through the `referenced_assertions` array of `cawg.identity`. This answers attribution and cryptographic protection; it does not claim that the assertion enforces a user's preference on downstream systems. -An August 11 General-channel reply also cautions that companies were not -reliably respecting training-and-mining assertions in practice. Treat the +Companies do not necessarily respect training-and-mining assertions. Treat the assertion as a statement of preference, not a technical block on scraping or a guarantee against undesired AI use. -[Source: gathered preference assertion and optional identity link, June 8, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1513597018038206725) - -[Source: practical enforcement limitation, August 11, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1536753197203587175) +Sources: -## Can my organization's identity certificate identify all my users? +- [Gathered preference assertion and optional identity link; June 8, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1513597018038206725) +- [Practical enforcement limitation; August 11, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1536753197203587175) -Not through the CAWG X.509 method described in the August reply. Each user -would need a CAWG certificate issued with that user's own name or organization. -Your organization's certificate asserts your organization's identity, not -the identities of all its users. Support suggests **Identity Claims -Aggregation** as an option for platforms. +### Why can crJSON show different specVersion values? -The October explanation distinguishes this from becoming a C2PA CA, which -is for issuing signing certificates to conforming products. To attach -artist, creator, or publisher identity, it instead recommends the -[CAWG identity assertion](https://cawg.io/identity/1.3/), using an X.509 -certificate or Identity Claims Aggregation. - -[Source: per-user X.509 identity, August 13, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1537519938552733766) - -[Source: CA versus creator identity, October 9, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1558191343988117524) - -## Why can crJSON show different specVersion values? - -The August 11 explanation distinguishes two fields: +The fields describe different specification versions: - `claim_generator_info.specVersion` in the claim describes the specification version declared by the generator. - `validationResults.specVersion` describes the specification version against which validation was performed. It is not copied from the generator's field. -Support reproduced a claim declaring `2.4.0` while the validation results -reported `2.3.0`, and explained that the validation value was hard-coded in -the SDK implementation at that time. Check the generator value in +As of August 2026, a claim could declare `2.4.0` while validation results +reported `2.3.0` because the validation value was hard-coded in the SDK +implementation. Check the generator value in `claim.v2` rather than trying to change the report's validation version through generator metadata. -That explanation resolves the field mismatch, not every conformance check. +This distinction explains the field mismatch, not every conformance check. Matching the generator field or passing a rubric alone is not presented here as proof that a product has passed the program. -[Source: field definitions, August 11, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1536901977655742567) - -[Source: reproduced version mismatch, August 11, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1536918406375276704) - -## Was the Interim Trust List completely unchanged after it was frozen? - -The April 27, 2026 response says necessary exceptions were made in very rare -cases and that no further changes were anticipated. This explains the -reported post-freeze updates; it is not an invitation to submit new entries -or a promise about future changes. - -For ingredient validation configuration, the later support guidance points -to the C2PA Trust List and C2PA TSA Trust List. +Sources: -[Source: rare exceptions, April 27, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1498294658600665170) +- [Field definitions; August 11, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1536901977655742567) +- [Reproduced version mismatch; August 11, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1536918406375276704) -[Source: current-list configuration guidance at the time, August 19, 2026](https://discord.com/channels/983153151341371422/1403049797023174828/1539661485234724864) diff --git a/docs/technical-faqs/tech-faq-general.md b/docs/technical-faqs/tech-faq-general.md index 23eebfa8..82c80c0d 100644 --- a/docs/technical-faqs/tech-faq-general.md +++ b/docs/technical-faqs/tech-faq-general.md @@ -1,99 +1,113 @@ +--- +hide_table_of_contents: true +--- + +import TOCInline from '@theme/TOCInline'; + # General FAQs -These answers are based only on the 287 messages in the exported CAI General -Discord channel history, covering April 1 through October 21, 2026. They -have not been independently verified against external sources or current -releases. Dated implementation guidance and linked resources reflect those -discussions, not guarantees of current availability or compatibility. -Discord source links may require server membership and channel access. + -## Where can I find signed sample assets, including location and time examples? +### Where can I find signed sample assets? -The April replies point to Proofmode's public -[Baseline repository](https://proofmode.org/baseline/), while warning that -much of its content used older C2PA 1.x support. Another reply suggests the -[`contentauth/example-assets` repository](https://github.com/contentauth/example-assets) -as a place to submit signed assets for testing. Neither answer promises a +Use Proofmode's public +[Baseline repository](https://proofmode.org/baseline/) has signed sample +assets, but be aware that much of its content uses older C2PA 1.x support. Use the [`contentauth/example-assets` repository](https://github.com/contentauth/example-assets) to submit signed assets for testing. Neither repository guarantees a complete, current conformance test suite. -For location metadata, the Proofmode developer links the +For location metadata, see the Proofmode [Android 3.0.2 release candidate](https://github.com/guardianproject/proofmode-android/releases/tag/3.0.2-RC-2) and its use of `c2pa.metadata` to include geolocation as a created assertion. Older conformance samples used `stds.exif`, described as deprecated but -still valid. A follow-up links the +still valid. See the [Kotlin metadata-generation code](https://github.com/guardianproject/proofmode-android/blob/main/android-libproofmode/src/main/java/org/witness/proofmode/c2pa/C2PAManager.kt#L840). -These are source-provided examples and implementation pointers, not a -guarantee that every sample contains GPS and a timestamp, that their -certificates remain trusted, or that signed metadata proves the truth of -the depicted event. +Sources: -[Source: Baseline and older sample versions, April 3, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1489689553886384228) +- [Baseline and older sample versions; April 3, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1489689553886384228) +- [Android geolocation implementation; April 3, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1489689681653141634) +- [Older sample assertion format; April 3, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1489690080623726795) +- [Metadata-generation code; April 3, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1489690402805125372) +- [Shared signed-asset repository; April 3, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1489693250133430272) -[Source: Android geolocation implementation, April 3, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1489689681653141634) +### How can I get started with Content Credentials on Android or iOS? -[Source: older sample assertion format, April 3, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1489690080623726795) +Use the [mobile SDKs](../mobile.md) for Android and iOS. -[Source: metadata-generation code, April 3, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1489690402805125372) +### Does a Valid validation state mean that the signer is trusted? -[Source: shared signed-asset repository, April 3, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1489693250133430272) +No. There are three manifest states: +**well-formed**, **valid**, and **trusted**. Trusted manifests are also +valid, and valid manifests are also well-formed. The reverse does not follow. -## How can I get started with Content Credentials on Android or iOS? +A manifest signed with a test certificate can have a `Valid` state while +`validation_results.activeManifest.failure` contains +`signingCredential.untrusted`. This follows the manifest-state model. -For users, the April 4 support reply recommends installing a C2PA-enabled -camera app, giving Proofmode as an iOS example. This is app-based guidance, -not a statement that the built-in camera on every iPhone signs assets. +Do not label a manifest trusted merely because its state is `Valid`. +Inspect the trust-related validation results, and distinguish trust that +was not evaluated from a failed trust check. An issuer name alone does +not establish trust. -For developers, the April and May replies recommend the open-source -[mobile SDKs](https://opensource.contentauthenticity.org/docs/mobile) -for Android and iOS rather than maintaining a new C2PA implementation. -SDK availability is distinct from the conformance or trust status of an -application built with it. +See the +[manifest states specification](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_manifest_states). -[Source: iOS camera-app route, April 4, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1490063556698443877) +Sources: -[Source: Android library recommendation, April 3, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1489689175270625582) +- [Valid-but-untrusted result; July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532235743022288977) +- [State hierarchy; July 30, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532378030276612178) +- [Specification reference; July 30, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532378218420633610) -[Source: Android and iOS SDK resources, May 14, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1504547100493348884) +### Can a manifest carry custom sensor or verification information? -## Can a manifest carry custom sensor or verification information? - -Yes. In response to a proposed sensor-noise extension, the April 20 answer -confirms that custom assertions can be added to a C2PA manifest. A validator +Yes. You can add custom assertions to a C2PA manifest. A validator that understands that assertion could use its information to identify where changes occurred. That is an extensibility mechanism, not endorsement of the proposal's claimed security guarantees or a promise that existing validators understand -it. The follow-up about coordinating camera and editor implementations -was not resolved in the exported discussion. +it. A camera/editor workflow needs compatible implementations; custom +assertions alone do not provide that coordination. -[Source: custom assertions and validator support, April 20, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1495831402938110155) +Source: [custom assertions and validator support, April 20, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1495831402938110155) -## Where are embedding rules for TIFF-based and base-media file formats documented? +### Where are embedding rules for TIFF-based and base-media file formats documented? -The August 17 reply directs implementers to the **Embedded Formats annex** +See the **Embedded Formats annex** of the [Content Credentials specification](https://c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html). -It was answering a question about TIFF-based Sony formats and the +for embedding rules relevant to TIFF-based Sony formats and the base-media-based Canon CR3 format. This is a specification pointer, not confirmation that every raw camera -format is supported by a particular SDK. The reply did not supply the -requested camera samples. +format is supported by a particular SDK or that camera samples are available. + +Source: [Embedded Formats annex, August 17, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1538922552007589898) + +### Where can I report a CAI security concern? + +Use the [CAI contact form](https://contentauthenticity.org/contact) to report +a security concern. Do not assume a dedicated security inbox, a response +deadline, or public status updates are available. + +Sources: -[Source: Embedded Formats annex, August 17, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1538922552007589898) +- [Reporting contact; October 19, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1561895003670716528) +- [Routing and status limitations; October 19, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1561895701028536405) -## Where can I report a CAI security concern? +### Why might an HEIC thumbnail not appear in Verify? -The October 19 support reply recommends the -[CAI contact form](https://contentauthenticity.org/contact) for something -that needs reporting. In the follow-up, support said the specific report -had been routed onward, but that the responder might not know its status. +Signing and display are separate issues. If a thumbnail's format changes to +`application/octet-stream` during signing, use a v2 claim: set +`claim_version` to `2`, or omit it if your version defaults to v2. -The discussion does not establish a dedicated security inbox, a response -deadline, or a promise of public status updates. +Display also depends on browser support. As of September 2026, +`image/heic` thumbnails displayed in macOS Safari but not Chrome. +A correctly embedded thumbnail therefore did not guarantee display in +every browser. These observations are historical, not a current browser +compatibility matrix. -[Source: reporting contact, October 19, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1561895003670716528) +Sources: -[Source: routing and status limitations, October 19, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1561895701028536405) +- [V2 claims and browser-dependent display; September 1, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1544362081107578961) +- [Successful result; September 2, 2026](https://discord.com/channels/983153151341371422/983153390781616159/1544907804417064970) \ No newline at end of file diff --git a/docs/technical-faqs/tech-faq-node.md b/docs/technical-faqs/tech-faq-node.md index a79b93f2..00dce854 100644 --- a/docs/technical-faqs/tech-faq-node.md +++ b/docs/technical-faqs/tech-faq-node.md @@ -1,18 +1,17 @@ -# Node.js SDK FAQs +--- +hide_table_of_contents: true +--- -These answers are based on the 29 messages in the exported CAI Node SDK -Discord history, covering April through July 2026. The export supports five -useful questions, not ten independent answered topics. Questions are selected -for actionable guidance rather than a measured frequency ranking. +import TOCInline from '@theme/TOCInline'; -Version-specific information reflects those discussions and has not been -independently checked against the latest release. Discord source links may -require channel access. +# Node.js library FAQs -## How do I configure created versus gathered assertions? + + +### How do I configure created versus gathered assertions? Use `builder.created_assertion_labels` to identify the assertions attributed -to your claim generator. The April support reply provided this example: +to your claim generator. For example: ```js const settings = { @@ -28,48 +27,27 @@ const settings = { ``` Choose labels that reflect your implementation; this is not a universal -conformance configuration. The reply explains that assertions were gathered -by default, except for the hard binding, which is always created. +conformance configuration. Assertions are gathered by default, except for +the hard binding, which is always created. Use only **base assertion labels**, without version or instance suffixes. For example, use `c2pa.ingredient`, not `c2pa.ingredient.v3`. The SDK handles the version. -Support also recommended updating to the latest release of the then-current -Node SDK because an earlier release had a bug. The discussion does not -identify the first release containing that fix. An upgrade does not replace +Update to the latest Node SDK release to avoid a bug in an earlier release. +The first release containing that fix is not identified here. An upgrade does not replace the need to configure assertion placement. -[Source: assertion settings, April 2, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1489395644274839582) - -[Source: release guidance, April 2, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1489396659451592754) - -[Source: base labels, April 2, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1489400012369694912) - -## Which Node SDK package should I use instead of c2pa-node 0.5.26? - -The July 29 support reply identifies `c2pa-node` 0.5.26 as the final -release of the deprecated v1 Node SDK. It recommends migrating to -[`@contentauth/c2pa-node`](https://www.npmjs.com/package/@contentauth/c2pa-node), -which was at version 0.8.0 at the time. +Sources: -The replacement package is maintained in the -[`contentauth/c2pa-js` monorepo](https://github.com/contentauth/c2pa-js). -Do not treat 0.8.0 as a recommendation to pin that historical version today. +- [Assertion settings; April 2, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1489395644274839582) +- [Release guidance; April 2, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1489396659451592754) +- [Base labels; April 2, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1489400012369694912) -The user who asked about trust-list configuration confirmed that migrating -to 0.8.0 enabled the trust settings shown in the next answer. +### How do I configure signing-certificate and timestamp trust? -[Source: package migration, July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532213791943692398) - -[Source: repository location, July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532213910495563867) - -[Source: successful migration, July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532235743022288977) - -## How do I configure signing-certificate and timestamp trust? - -The July support example loads the C2PA Trust List and C2PA TSA Trust List, -combines their PEM contents, and enables both trust checks. With those PEM +Load the C2PA Trust List and C2PA TSA Trust List, combine their PEM contents, +and enable both trust checks. With those PEM strings already loaded as `c2paTrustList` and `c2paTsaTrustList`, pass the settings to both the reader and builder: @@ -93,57 +71,26 @@ reader and builder bindings are imported and the PEM contents have been fetched or read. It comes from the replacement package discussed above, not the deprecated `c2pa-node` 0.5.26 API. -[Source: reader and builder trust settings, July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532214117342122025) - -[Source: user confirmation, July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532235743022288977) - -## Should I pass a PEM file path or its contents as trust anchors? - -Pass the **PEM contents as a string**. In the April troubleshooting -discussion, support advised replacing a file path with the actual PEM -data. After inspecting the code, support identified C2PA Tool's -`load_trust_resource()` as a convenience for loading PEM data from a path -or URL; that behavior should not be assumed for the Node SDK. - -The `loadSettingsFromFile()` function mentioned in that discussion loads -the whole settings file. It is not evidence that an individual trust-anchor -setting accepts a PEM path. - -The later July example also supplies PEM strings through -`trust.trust_anchors`. The April thread does not include a confirmed -resolution for the particular Adobe-signed asset being tested, so do not -assume that changing the input format resolves every trust failure. - -[Source: PEM contents, April 4, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1490086610321145876) - -[Source: settings-file distinction, April 4, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1490087412364218409) - -[Source: C2PA Tool convenience method, April 4, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1490090813227536416) - -[Source: later PEM-string example, July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532214117342122025) - -## Does a Valid validation state mean that the signer is trusted? +Sources: -No. The July support reply distinguishes three manifest states: -**well-formed**, **valid**, and **trusted**. Trusted manifests are also -valid, and valid manifests are also well-formed. The reverse does not follow. +- [Reader and builder trust settings; July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532214117342122025) +- [User confirmation; July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532235743022288977) -A user testing the replacement SDK with trust verification enabled reported -a `Valid` state for a test certificate while -`validation_results.activeManifest.failure` contained -`signingCredential.untrusted`. Support confirmed that the report's overall -state follows the manifest-state model. +### Should I pass a PEM file path or its contents as trust anchors? -Do not label a manifest trusted merely because its state is `Valid`. -Inspect the trust-related validation results, and distinguish trust that -was not evaluated from a failed trust check. An issuer name alone does -not establish trust. +Pass the **PEM contents as a string**, not a file path. C2PA Tool's +`load_trust_resource()` is a convenience for loading PEM data from a path +or URL; do not assume that behavior applies to the Node SDK. -See the source-linked -[manifest states specification](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_manifest_states). +The `loadSettingsFromFile()` function loads the whole settings file; it +does not imply that an individual trust-anchor setting accepts a PEM path. -[Source: valid-but-untrusted result, July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532235743022288977) +Supply PEM strings through `trust.trust_anchors`, as shown above. Changing +the input format does not necessarily resolve every trust failure. -[Source: state hierarchy, July 30, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532378030276612178) +Sources: -[Source: specification reference, July 30, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532378218420633610) +- [PEM contents; April 4, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1490086610321145876) +- [Settings-file distinction; April 4, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1490087412364218409) +- [C2PA Tool convenience method; April 4, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1490090813227536416) +- [Later PEM-string example; July 29, 2026](https://discord.com/channels/983153151341371422/1168635192680923206/1532214117342122025) diff --git a/docs/technical-faqs/tech-faq-rust.md b/docs/technical-faqs/tech-faq-rust.md index 31bdc98f..7f5f224d 100644 --- a/docs/technical-faqs/tech-faq-rust.md +++ b/docs/technical-faqs/tech-faq-rust.md @@ -1,25 +1,23 @@ -# FAQ: Rust library +--- +hide_table_of_contents: true +--- -These FAQs are based on discussions in the CAI Rust SDK Discord channel from 2026. -In some cases, the information may be specific to a particular version of the SDK. Always confirm using the latest release. +import TOCInline from '@theme/TOCInline'; -Selected answers also draw on the General channel history from April through -October 2026; those additions have not been externally verified. +# Rust library FAQs -:::note -Discord source links require a Discord account and joining the public CAI Discord server. -::: + -## Can I configure trust anchors using a URL? +### Can I configure trust anchors using a URL? The Rust SDK expects trust anchors as a **PEM string**, not a URL or file path. Your application must fetch or read the PEM data and pass its contents to the SDK. -C2PA Tool accepts URLs and paths as command-line arguments because it +In contrast, C2PA Tool accepts URLs and paths as command-line arguments because it retrieves the data before passing it to the SDK. -The support reply provided this example: +For example: ```rust let pem = reqwest::blocking::get("https://example.com/trust_anchors.pem")? @@ -34,9 +32,9 @@ c2pa::settings::Settings::from_toml( )?; ``` -[Source: April 7, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1491236748653494503) +Source: [Trust anchors: April 7, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1491236748653494503) -## How do I mark assertions as created rather than gathered? +### How do I mark assertions as created rather than gathered? Use the `builder.created_assertion_labels` setting to identify assertions attributed to your claim generator. For example: @@ -52,15 +50,15 @@ created_assertion_labels = [ ``` Choose labels appropriate to your implementation. This example is not a -universal conformance configuration. The support discussion notes that the -hard-binding assertion is always a created assertion. +universal conformance configuration. The hard-binding assertion is always +a created assertion. -See [Created versus gathered assertions](https://opensource.contentauthenticity.org/docs/manifest/writing/assertions-actions/#created-versus-gathered-assertions) +See [Created versus gathered assertions](../manifest/writing/assertions-actions.md#created-versus-gathered-assertions) for more information. -[Source: June 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1516521499517779978) +Source: [Created assertions config; June 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1516521499517779978) -## How do I preserve an existing asset's assertions when editing it? +### How do I preserve an existing asset's assertions when editing it? Include the original asset as a **`parentOf` ingredient**. If the asset is signed, its manifest and assertions are carried forward through that @@ -73,7 +71,7 @@ For a typical editing workflow, use: builder.set_intent(BuilderIntent::Edit); ``` -Edit intent automatically adds the `c2pa.opened` action and uses the source +The `Edit` intent automatically adds the `c2pa.opened` action and uses the source as the parent if you do not specify one. Do not manually add a duplicate `c2pa.opened` action. @@ -81,27 +79,26 @@ It is normal for a simple open-and-edit workflow to have no gathered assertions. If you intentionally reuse metadata as a new gathered assertion, verify that it still applies to the edited asset. -[Source: parent handling, October 14, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1559968978376593439) +Sources: -[Source: gathered-assertion clarification, October 14, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1560080821287657594) +- [Parent handling; October 14, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1559968978376593439) +- [Gathered-assertion clarification; October 14, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1560080821287657594) -An October 15 General-channel troubleshooting reply also recommends edit -intent when an existing asset produces +Use the `Edit` intent when an existing asset produces `assertion.action.malformed: first action must be created or opened` -or `assertion.action.ingredientMismatch`. In that case, the manually defined -`actions` were not nested inside `assertions`, and the workflow also needed -a referenced `parentOf` ingredient. The user confirmed that switching to -edit intent worked. Do not assume an "Invalid Manifest" error is a trust +or `assertion.action.ingredientMismatch`. Ensure manually defined +`actions` are nested inside `assertions` and the workflow includes +a referenced `parentOf` ingredient. Do not assume an "Invalid Manifest" error is a trust problem without inspecting its validation details. -[Source: action structure and edit-intent fix, October 15, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1560317418574839849) +Sources: -[Source: successful result, October 15, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1560344798165074072) +- [action structure and edit-intent fix, October 15, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1560317418574839849) +- [successful result, October 15, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1560344798165074072) -## How do I add timestamps for existing ingredient manifests? +### How do I add timestamps for existing ingredient manifests? -Enable automatic timestamp assertions. The support discussion provided -these settings: +Enable automatic timestamp assertions with these settings: ```toml [builder.auto_timestamp_assertion] @@ -115,84 +112,25 @@ Choose the builder intent according to the operation: need to add a timestamp assertion. - Use **edit intent** when you are also editing or reformatting the asset. -The support responder tested both approaches. The discussion also states -that the timestamp assertion must be added while the relevant signing +Add the timestamp assertion while the relevant signing certificate is still within its validity period. -[Source: settings, April 20, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1495826791313571900) +Sources: -[Source: intent selection, April 20, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1495827650026147952) +- [settings, April 20, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1495826791313571900) +- [intent selection, April 20, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1495827650026147952) +- [certificate validity, April 7, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1491238678410821784) -[Source: certificate validity, April 7, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1491238678410821784) - -## Why is no thumbnail generated when thumbnails are enabled? +### Why is no thumbnail generated even though thumbnails are enabled? The SDK skips automatic thumbnail generation for **update manifests**, -even when thumbnail generation is enabled. The support reply explains that -the specification does not permit update manifests to contain thumbnail -assertions. - -[Source: April 19, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1495464171934974002) - -## Why do I get duplicate timestamp assertions with `skip_existing = true`? - -The intended behavior of `skip_existing` is to exclude claims already -covered by timestamps, including timestamps in COSE signatures and timestamp +even when thumbnail generation is enabled. The specification does not +permit update manifests to contain thumbnail assertions. -The discussion identified a bug when an ingredient contained **both** -forms of timestamp. The fix was submitted in -[PR #2085](https://github.com/contentauth/c2pa-rs/pull/2085), and the support -responder confirmed that it merged on April 24, 2026. - -If you encounter this behavior, check whether your SDK version includes -that fix. The discussion does not identify the first release containing it. - -[Source: diagnosis, April 24, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1497281494471806976) - -[Source: merge confirmation, April 24, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1497360349878419509) - -## Why does C2PA Tool behave differently when launched by my application? - -Check the **actual executable and version** your application launches, -rather than only the version available in your terminal. - -In the reported case, the application launched C2PA Tool **0.26.1**, -although the user expected **0.26.41**. Launching 0.26.41 resolved the -missing timestamp assertion. - -This is one troubleshooting step, not evidence that every missing timestamp -has this cause. - -[Source: confirmed resolution, April 22, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1496644840786624614) - -## Can I create sidecar manifests for unsupported file types? - -Yes. In the September 2026 discussion, support confirmed that sidecar -support for otherwise unsupported file types had been implemented, -referenced [PR #2014](https://github.com/contentauth/c2pa-rs/pull/2014), -and tested `.obj` and `.mtl` files. - -A user running C2PA Tool 0.27.22 saw an "unsupported file type" error -**after signing**, during the subsequent read operation. The sidecar had -still been created. - -To read the asset with its sidecar, the support reply recommended: - -```sh -c2patool file.obj --external-manifest file.c2pa -``` - -The user subsequently confirmed that the sidecars were being written -successfully. - -[Source: implementation, September 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1549892485080293416) - -[Source: read command, September 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1549898982988455988) - -[Source: user confirmation, September 17, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1550145681090412695) +Source: [Thumbnail auto-generation, April 19, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1495464171934974002) -## How do I avoid sidecar filename collisions? +### How do I avoid sidecar filename collisions? Assets with the same base name can produce the same default sidecar filename. For example, `file.obj` and `file.mtl` can both produce @@ -209,36 +147,34 @@ file.mtl.c2pa When reading an asset, explicitly provide the corresponding sidecar using `--external-manifest`. -[Source: September 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1549894561537466399) +Source: [Renaming sidecars, September 16, 2026](https://discord.com/channels/983153151341371422/983153550018371595/1549894561537466399) -## Why does manifest compression barely reduce a long existing chain? +### Why does manifest compression barely reduce a long existing chain? -The October 15 support reply explains that compression applies to the -current manifest being written, not retroactively to every manifest in an +Compression applies to the current manifest being written, not retroactively to every manifest in an existing chain. To compare compressed and uncompressed chains, enable `prefer_compress_manifests` while writing each generation. -Support tested ten manifests containing a repetitive text custom assertion. -The final manifest-store size was 154,638 bytes without compression and -52,583 bytes with compression enabled at each generation. The responder -explicitly cautioned that repetitive test data would likely compress better +In a test of 10 manifests containing a repetitive text custom assertion, +the final manifest-store size was 154,638 bytes without compression and +52,583 bytes with compression enabled at each generation. Repetitive test +data would likely compress better than real-world content. This is not a promised compression ratio or a way to shrink all prior manifests by appending one compressed manifest. -[Source: compression scope and test recommendation, October 15, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1560358414264172585) +Sources: -[Source: controlled comparison and data caveat, October 15, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1560370962875285566) +- [Compression scope and test recommendation, October 15, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1560358414264172585) +- [Controlled comparison and data caveat, October 15, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1560370962875285566) -## Can I use the Rust implementation from a JVM backend? +### Can I use the Rust implementation from a JVM backend? -The September 14 reply points to the Rust implementation's -[C API](https://github.com/contentauth/c2pa-rs/tree/main/c2pa_c_ffi) as an -integration route through JNI. +The SDK does not provide a supported Java binding. +And the Android bindings focus on Android-specific needs: Adapting them for a +JVM service would require additional work; they are not an existing, +maintained general-purpose Java package. -The responder said a Kotlin library had been discussed, but development -had focused on Android-specific needs. Forking the Android bindings for a -JVM service was suggested as possible work, not offered as an existing, -maintained JVM package. The export does not establish a supported Java -binding or provide a complete JNI integration example. +You could use the Rust implementation's +[C API](https://github.com/contentauth/c2pa-rs/tree/main/c2pa_c_ffi) to integrate through JNI. -[Source: Android scope and C API integration route, September 14, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1549054456258240674) +Source: [Android scope and C API integration route, September 14, 2026](https://discord.com/channels/983153151341371422/986451330992320512/1549054456258240674) diff --git a/sidebars.js b/sidebars.js index 1141a1eb..4de39ee6 100644 --- a/sidebars.js +++ b/sidebars.js @@ -141,42 +141,37 @@ const sidebars = { { type: 'category', label: 'Technical FAQs', + link: { type: 'doc', id: 'technical-faqs/index' }, collapsed: true, items: [ { type: 'doc', id: 'technical-faqs/tech-faq-general', - label: 'General FAQs', }, { type: 'doc', id: 'technical-faqs/tech-faq-rust', - label: 'Rust SDK FAQ', }, { type: 'doc', id: 'technical-faqs/tech-faq-node', - label: 'Node.js SDK FAQs', }, { type: 'doc', id: 'technical-faqs/tech-faq-c2pa-tool', - label: 'C2PA Tool FAQs', }, { type: 'doc', id: 'technical-faqs/tech-faq-conformance', - label: 'C2PA Conformance FAQs', }, { type: 'doc', id: 'technical-faqs/tech-faq-cawg', - label: 'CAWG Standard FAQs', }, { type: 'doc', id: 'technical-faqs/tech-faq-certificates', - label: 'Certificate FAQs', + label: 'Signing certificate FAQs', }, ], },