diff --git a/docs/community.md b/docs/community.md index 19a9b68..a8b9a39 100644 --- a/docs/community.md +++ b/docs/community.md @@ -14,7 +14,7 @@ All the open-source CAI code is hosted in GitHub in the [CAI GitHub organization - **JavaScript library**: [c2pa-web](https://github.com/contentauth/c2pa-web) - **Python library**: [c2pa-python](https://github.com/contentauth/c2pa-python) - **Node.js library**: [c2pa-node-v2](https://github.com/contentauth/c2pa-node-v2) -- **C++ library**: [c2pa-c](https://github.com/contentauth/c2pa-c) +- **C++ library**: [c2pa-cpp](https://github.com/contentauth/c2pa-cpp) If you think you've found a bug or want to request a feature, please open an issue in the appropriate repository. diff --git a/docs/getting-started/index.mdx b/docs/getting-started/index.mdx index f52c2ad..d2d0822 100644 --- a/docs/getting-started/index.mdx +++ b/docs/getting-started/index.mdx @@ -99,7 +99,7 @@ The _C2PA trust list_ is a curated list of certification authorities (CAs) that Conforming validator products such as the [Inspect tool on Adobe Content Authenticity (Beta)](https://inspect.cr) use the C2PA trust list to determine whether a Content Credential was issued using a certificate that can be traced back to a CA on the C2PA trust list. -The [Verify tool](https://verify.contentauthenticity.org) uses [the interim trust list](../conformance/trust-lists.mdx#interim-trust-list) to determine which certificates are considered valid. Verify will be updated to use the official [C2PA trust list](conformance/index.mdx#c2pa-trust-lists). +The [Verify tool](https://verify.contentauthenticity.org) uses both the [the interim trust list](../conformance/trust-lists.mdx#interim-trust-list) and the official [C2PA trust list](conformance/trust-lists.mdx#c2pa-trust-list) to determine which certificates are considered valid and indicates which trust list was used. ## Identity diff --git a/docs/introduction.mdx b/docs/introduction.mdx index e76c3ea..d2c53de 100644 --- a/docs/introduction.mdx +++ b/docs/introduction.mdx @@ -23,7 +23,7 @@ The CAI open-source SDK consist of: - Attach a manifest data to an asset. - Add a manifest to to the associated manifest store if the asset already has an associated manifest data. - [**JavaScript library**](c2pa-js/readme.md) that enables web pages to to read, validate, create, and sign manifest data, and embed it in supported asset files using client JavaScript. Use it to add user interface elements to your website that display manifest data while following the [C2PA user experience recommendations](https://c2pa.org/specifications/specifications/1.0/ux/UX_Recommendations.html). -- **[C/C++](c2pa-cpp/readme.md), [Python](c2pa-python/readme.md), [Node.js](c2pa-node/readme.md) libraries** that enable applications to read and validate manifest data, create and sign manifest data, and embed it supported asset files. +- **[C/C++](c2pa-cpp/readme.md), [Python](c2pa-python/readme.md), [Node.js](c2pa-node-v2/readme.md) libraries** that enable applications to read and validate manifest data, create and sign manifest data, and embed it supported asset files. - [**Mobile libraries**](mobile.md) that enable mobile applications for iOS and Android to to read and generate manifest data. - [**The Rust library**](rust-sdk/readme.md) that generates the other language bindings and can also be used directly to read and generate manifest data. The Rust library is the fundamental system underlying everything else. diff --git a/docs/manifest/writing/assertions-actions.md b/docs/manifest/writing/assertions-actions.md index 5a94bf5..219c670 100644 --- a/docs/manifest/writing/assertions-actions.md +++ b/docs/manifest/writing/assertions-actions.md @@ -60,7 +60,7 @@ Content bindings are standard assertions such as `c2pa.hash.boxes` and `c2pa.has The CAI SDK writes content bindings assertions, so normally you don't need to write them, just read them. ::: -For example, the `c2pa.hash.data` assertion shown in the [detailed manifest example](../examples.mdx#detailed-manifest) specifies an exclusion hash: +For example, the `c2pa.hash.data` assertion shown in the example below specifies an exclusion hash: ```json "assertions": [ diff --git a/docs/nodejs.md b/docs/nodejs.md index d15a2ff..9a3f1b7 100644 --- a/docs/nodejs.md +++ b/docs/nodejs.md @@ -7,7 +7,7 @@ custom_edit_path: c2pa-node-v2/edit/main/README.md import Readme from './c2pa-node-v2/readme.md'; :::note -[The old c2pa-node library](c2pa-node/readme.md) is still available, but it's deprecated and will no longer be updated or supported. Move to the new `c2pa-node-v2` library as soon as possible! +The old [c2pa-node library](c2pa-node/readme.md) is still available, but it's deprecated and will no longer be updated or supported. Move to the new `c2pa-node-v2` library as soon as possible! ::: null }} /> \ No newline at end of file diff --git a/docs/roadmap.mdx b/docs/roadmap.mdx deleted file mode 100644 index a22c2cc..0000000 --- a/docs/roadmap.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -id: roadmap -title: Open-source SDK task planning and roadmap -hide_table_of_contents: true ---- - -:::warning -This page is deprecated and may not be up to date. -::: - -This is an overview of task planning for the CAI open-source SDK to provide a general idea of priorities and progress. The roadmap is subject to change based on feedback and other factors. - -:::note -This information was updated in **November, 2025**. It will be regularly updated but might not always reflect the most current status. -::: - -Tasks in progress or planning are categorized as follows (in reverse order of completion): - -- [**Released**](#released) : The feature, code, or fix has been released. -- [**Merged to Main**](#merged-to-main): Code has been merged to the main branch but not yet released. -- [**Code Complete**](#code-complete): Coding is done, but testing may still be in progress, and the task has not been merged to the main branch. -- [**In Progress**](#in-progress): Work is in progress. -- [**To Do**](#todo): Planned for future work. -- [**In Review / Triage**](#in-review-/-triage): Task is under review to determine if and when it can be addressed. - -A new issue/task starts in the **In Review / Triage** status. Once reviewed and approved, it moves into **To Do** status, and when a developer begins working on it, into **In Progress**. Once development work is done, the task moves to **Code Complete**. After testing and validation, it moves to **Merged to Main**, which is the final step before it is included in a release. - -:::tip -Do you see something important that's not listed? Open an issue in the appropriate repository! -::: - -import Roadmap from '@site/src/components/Roadmap'; - - diff --git a/docs/signing/local-signing.md b/docs/signing/local-signing.md index 44f833f..0ff9535 100644 --- a/docs/signing/local-signing.md +++ b/docs/signing/local-signing.md @@ -13,7 +13,7 @@ Trust lists connect the end-entity certificate that signed a manifest back to th The simplest way to add a C2PA manifest to an asset file and sign it is by using C2PA Tool (`c2patool`). You can run C2PA Tool manually from the command line (for example, during development) and more generally from any executable program that can call out to the shell. -Similarly, using the Rust SDK, you can [add a manifest to an asset file](https://docs.rs/c2pa/latest/c2pa/#example-adding-a-manifest-to-a-file), referencing the certificate and private key file. The [Node.js](../c2pa-node), [Python](../c2pa-python), and [C++/C](../c2pa-c) libraries can also add and sign a manifest. +Similarly, using the Rust SDK, you can [add a manifest to an asset file](https://docs.rs/c2pa/latest/c2pa/#example-adding-a-manifest-to-a-file), referencing the certificate and private key file. The [Node.js](../c2pa-node), [Python](../c2pa-python), and [C++](../c2pa-cpp) libraries can also add and sign a manifest. :::warning Warning Accessing a private key and certificate directly from the file system is fine during development, but doing so in production is not secure. Instead use a Key Management Service (KMS) or a hardware security module (HSM) to access the certificate and key; For more information, see [Using a certificate in production](prod-cert.mdx). diff --git a/docs/signing/test-certs.md b/docs/signing/test-certs.md index 368ff53..f61ba6a 100644 --- a/docs/signing/test-certs.md +++ b/docs/signing/test-certs.md @@ -7,7 +7,7 @@ The CAI SDK does not allow you to use a self-signed certificate to sign a manife For initial development and testing, the SDK provides example *test certificates* and private keys: - The [Rust library `sdk/tests/fixtures/certs/` folder](https://github.com/contentauth/c2pa-rs/tree/main/sdk/tests/fixtures/certs) contains certificates and signing keys for many of the supported [signature types](get-cert.md#signature-types). -- The Node.js, Python, and C++ libraries provide a subset of test certificates in each repository's `tests/fixtures` folder. The Node.js library even provides a [`CreateTestSigner()`](https://github.com/contentauth/c2pa-node/blob/main/docs/README.md#createtestsigner) convenience function to create a local signer instance using the test certificate. +- The Node.js, Python, and C++ libraries provide a subset of test certificates in each repository's `tests/fixtures` folder. :::warning Warning While these test credentials are useful during development, you must [get your own certificate](get-cert.md) and use your own private key for production deployment. @@ -15,6 +15,6 @@ While these test credentials are useful during development, you must [get your o Although not recommended due to complexity and difficulty, you can create your own certificates for development and testing. Follow the requirements in the C2PA Technical Specification [X.509 Certificates](https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#x509_certificates) and [Digital Signatures](https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#_digital_signatures) sections. -For manifest claims signed with one of the test certificates, the [Inspect tool on Adobe Content Authenticity (Beta)](https://inspect.cr) will display the message "The Content Credential issuer couldn't be recognized." See [Using ACA Inspect](../getting-started/aca-inspect.mdx#signing-information) for more information. +For manifest claims signed with one of the test certificates, the [Inspect tool on Adobe Content Authenticity (Beta)](https://inspect.cr) will display the message "The Content Credential issuer couldn't be recognized." See [Using ACA Inspect](../getting-started/aca-inspect.mdx#title-and-signing-information) for more information. diff --git a/docusaurus.config.js b/docusaurus.config.js index d6d08e1..aa94907 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -124,6 +124,9 @@ async function createConfig() { baseUrl: '/', staticDirectories: ['static'], onBrokenLinks: 'warn', + // Schema reference pages (docs/manifest/json-ref/*-ref.mdx) render headings and + // ids inside SchemaReference from JSON Schema at runtime, so build-time anchor + // extraction cannot see those hashes. Links to #fragments on those pages are valid. onBrokenAnchors: 'log', markdown: { mermaid: true, diff --git a/remote-docs.json b/remote-docs.json index 9abd405..0e41855 100644 --- a/remote-docs.json +++ b/remote-docs.json @@ -405,11 +405,6 @@ }, { "_comment": "Node.js library" }, - { - "repo": "contentauth/c2pa-node", - "path": "README.md", - "dest": "docs/c2pa-node/readme.md" - }, { "repo": "contentauth/c2pa-node-v2", "path": "README.md",