From 4ba784d3a1b153c055bbc966a979b3b2abe90047 Mon Sep 17 00:00:00 2001 From: Rand McKinney Date: Thu, 22 Aug 2024 09:11:39 -0700 Subject: [PATCH 01/11] Change links to be to files not urls --- docs/prod-cert.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/prod-cert.mdx b/docs/prod-cert.mdx index 29aabdbc..c10a981a 100644 --- a/docs/prod-cert.mdx +++ b/docs/prod-cert.mdx @@ -5,13 +5,13 @@ title: Getting and using a signing certificate ## Overview -For convenience, C2PA Tool, the Rust library, and the CAI prerelease libraries include one or more [test certificates](manifest/signing-manifests#test-certificates) and private keys for use during development, typically in the `tests/fixtures` directory. While these test certificates and keys are useful during development and testing, for production deployment you must use your own private key and certificate. +For convenience, C2PA Tool, the Rust library, and the CAI prerelease libraries include one or more [test certificates](manifest/signing-manifests.md#test-certificates) and private keys for use during development, typically in the `tests/fixtures` directory. While these test certificates and keys are useful during development and testing, for production deployment you must use your own private key and certificate. Certificates and private keys are often stored on a hardware security module (HSM), a physical device that attaches directly to a computer or server and is used to securely manage and perform operations on cryptographic keys. A Key Management Service (KMS) is software used to manage keys in a networked environment. A KMS can be connected to a HSM for extra security. For example, the [Python example application](/c2pa-python-example) uses [AWS KMS](https://aws.amazon.com/kms/). ## Purchasing a certificate -To create or modify Content Credentials, you must have a valid X.509 v3 security certificate and key that conform to the requirements laid out in the [C2PA specification](https://c2pa.org/specifications/specifications/2.0/specs/C2PA_Specification.html#x509_certificates). You must purchase a certificate from a certificate authority (CA). There are many CAs; some popular ones are listed in [Getting started](getting-started#getting-a-security-certificate). +To create or modify Content Credentials, you must have a valid X.509 v3 security certificate and key that conform to the requirements laid out in the [C2PA specification](https://c2pa.org/specifications/specifications/2.0/specs/C2PA_Specification.html#x509_certificates). You must purchase a certificate from a certificate authority (CA). There are many CAs; some popular ones are listed in [Getting started](getting-started.mdx#getting-a-security-certificate). When you purchase a certificate, you must select at least one of the extended key usage (EKU) fields that specify what the certificate can be used for: **email protection** and **document signing**. Applications that use the CAI SDK won't accept the certificate unless it has one of these EKUs. From 397963f35358903b024e9525c877a71f21348d7d Mon Sep 17 00:00:00 2001 From: Rand McKinney Date: Thu, 22 Aug 2024 09:24:24 -0700 Subject: [PATCH 02/11] fix more links, etc --- docs/getting-started.mdx | 8 ++++---- docs/introduction.mdx | 4 ++-- docs/trust-list.mdx | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/getting-started.mdx b/docs/getting-started.mdx index fa1c9239..bd663c68 100644 --- a/docs/getting-started.mdx +++ b/docs/getting-started.mdx @@ -87,7 +87,7 @@ In practice, to use a certificate with the CAI SDK, follow this process: 3. Use one of the supporting CAI libraries or C2PA Tool to sign manifests using the certificate. :::tip -For more details and a short tutorial example, see [Signing manifests](manifest/signing-manifests). +For more details and a short tutorial example, see [Signing manifests](manifest/signing-manifests.md). ::: ### Getting a security certificate @@ -113,7 +113,7 @@ Certificate authorities offer many levels of validation. For Content Credentials - **Organization Validated (OV).** The CA validates the organization's identity by checking its credentials against extensive databases, including those held by local governments. - **Extended Validation (EV).** A fully authenticated certificate, needed to offer secure web locations, email, and financial transactions. -If you don't get an OV certificate, then the Content Credentials that use the certificate won't display your organization name, as shown in the examples on [verify.contentauthenticity.org](https://verify.contentauthenticity.org/). +If you don't get an OV certificate, then the [C2PA Verify tool](https://verify.contentauthenticity.org/) won't display your organization name in the Content Credentials. ### Extracting the certificate @@ -143,7 +143,7 @@ The C2PA [Verify tool](https://contentcredentials.org/verify) uses a list of _kn ## Identity -To identify who created or modified an asset, identity needs to be verifiable and bound to an asset and its manifest store. The CAI SDK supports the [W3C verifiable credentials](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_w3c_verifiable_credentials) standard recommendation (part of the C2PA specification), but doesn't currently have a way to validate these credentials or ensure that they properly reflect authorship of the content. An actor can add one or more identities to a manifest using the W3C verifiable credentials data model. Currently, a verifier must trust the manifest signer to properly authenticate the identity. +To identify who created or modified an asset, identity needs to be verifiable and bound to an asset and its manifest store. The CAI SDK supports the [W3C verifiable credentials](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_w3c_verifiable_credentials) standard recommendation (part of the C2PA specification), but doesn't currently have a way to validate these credentials or ensure that they properly reflect authorship of the content. An actor can add one or more identities to a manifest using the W3C verifiable credentials data model. Currently, a verifier must trust the manifest signer to properly authenticate the identity. Identity can be bolstered with other kinds of evidence such as _Adobe connected accounts_. In the future, the identity credentials will be separately verifiable. In the future, these verifiable credentials will be strongly bound to the manifest and media and be independently verifiable. @@ -227,7 +227,7 @@ Embedding a manifest in an asset usually increases the size of the file. Two thi ### Storing a manifest in the cloud -In addition to storing the manifest with the asset, Adobe tools use the _Adobe Content Credentials Cloud_, a public, persistent storage option for attribution and history data. Publishing to this cloud keeps files smaller and makes Content Credentials more resilient, because if stripped from an asset they can be recovered by searching at [verify.contentauthenticity.org](https://verify.contentauthenticity.org/). On the other hand, embedding the manifest keeps the file self-contained and means no web access is required to validate. +In addition to storing the manifest with the asset, Adobe tools use the _Adobe Content Credentials Cloud_, a public, persistent storage option for attribution and history data. Publishing to this cloud keeps files smaller and makes Content Credentials more resilient, because if stripped from an asset they can be recovered by searching with the [C2PA Verify tool](https://verify.contentauthenticity.org/). On the other hand, embedding the manifest keeps the file self-contained and means no web access is required to validate. Currently, Adobe Content Credentials Cloud (ACCC) is only available to Adobe tools, though in the future other credentials clouds may become available if other organizations want to host a credential service. Currently, most manifests will be embedded in assets since ACCC is specific to Adobe. diff --git a/docs/introduction.mdx b/docs/introduction.mdx index 84b98b41..52b3bcea 100644 --- a/docs/introduction.mdx +++ b/docs/introduction.mdx @@ -7,7 +7,7 @@ import cr_pin from '../static/img/cr-pin.png'; import cai_open_source_red from '../static/img/cai-open-source-red.jpg'; :::tip -You're strongly encouraged to read this introduction and [Getting started](getting-started) to give you some basic background and context, before you dive right into development. [Working with manifests](manifest/understanding-manifest) also has some crucial information, regardless of which language and library you use. +You're strongly encouraged to read this introduction and [Getting started](getting-started.mdx) to give you some basic background and context, before you dive right into development. [Working with manifests](manifest/understanding.md) also has some crucial information, regardless of which language and library you use. ::: The Coalition for Content Provenance and Authenticity (C2PA) and Content Authenticity Initiative (CAI) are groups working together to develop and promote adoption of an open industry standard for content authenticity and provenance. @@ -37,7 +37,7 @@ To see a summary of what each tool and library can do, see [Which tool is right ### JavaScript library -The client [JavaScript library](js-sdk/getting-started/overview) enables **working with manifest data in the browser**. Use this library to: +The client [JavaScript library](js-sdk/getting-started/overview.mdx) enables **working with manifest data in the browser**. Use this library to: - Verify and display manifest data on a website or web application. - Link manifest data displayed on your site to [Verify](https://verify.contentauthenticity.org/). diff --git a/docs/trust-list.mdx b/docs/trust-list.mdx index 49c94c84..8b0ffa9e 100644 --- a/docs/trust-list.mdx +++ b/docs/trust-list.mdx @@ -12,7 +12,7 @@ The C2PA **[Verify tool](https://contentcredentials.org/verify)** uses a list of style={{ width: '300px', display: 'block', margin: '10px auto' }} /> -Conversely, if the Content Credential was signed by a known certificate, the Verify tool will display the [name of the certificate owner and time of the claim signature](../verify#title-and-signing-information). +Conversely, if the Content Credential was signed by a known certificate, the Verify tool will display the [name of the certificate owner and time of the claim signature](verify.mdx#title-and-signing-information). :::note The C2PA intends to publish an official public list of known certificates. Until then, **[Verify](https://contentcredentials.org/verify)** uses a temporary list. The list is subject to change and will be deprecated when C2PA publishes the official list. From d4fc0b529da465ba8d1ed2922d36ae5f69663349 Mon Sep 17 00:00:00 2001 From: Rand McKinney Date: Thu, 22 Aug 2024 09:43:32 -0700 Subject: [PATCH 03/11] still more link fixes --- docs/getting-started.mdx | 14 +++++++------- docs/trust-list.mdx | 4 ++-- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/getting-started.mdx b/docs/getting-started.mdx index bd663c68..4cd95234 100644 --- a/docs/getting-started.mdx +++ b/docs/getting-started.mdx @@ -33,7 +33,7 @@ Now, let's drill down a bit to clarify some of these terms. **Action**: An operation that an _actor_ performs on an _asset._ For example, "create," "embed," or "change contrast." -**Assertion**: Part of the manifest "asserted" by an actor that contains data about an asset's creation, authorship, how it's been edited, and other relevant information. For example, an assertion might be "change image contrast." For a list of standard C2PA assertions, see the [C2PA Specification](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_c2pa_standard_assertions). +**Assertion**: Part of the manifest "asserted" by an actor that contains data about an asset's creation, authorship, how it's been edited, and other relevant information. For example, an assertion might be "change image contrast." For a list of standard C2PA assertions, see the [C2PA Specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_c2pa_standard_assertions). **Certificate Authority (CA)**: A trusted third party that verifies the identity of an organization applying for a digital certificate. After verifying the organization's identity, the CA issues a certificate and binds the organization's identity to a public key. A digital certificate can be trusted because it is chained to the CA's root certificate. @@ -53,15 +53,15 @@ Now, let's drill down a bit to clarify some of these terms. **Manifest store**: A collection of manifests associated with asset. The most recent manifest in the manifest store is the _active manifest_, which has the set of _content bindings_ that are hashed with the asset and thus can be validated. -For more definitions and detail, see the [C2PA specification](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_glossary). +For more definitions and detail, see the [C2PA specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_glossary). ## How it works A _manifest_ is a binary data structure that describes the history and identity data attached to digital asset. The CAI SDK enables applications and websites to attach a manifest to an asset and display it when requested. This helps viewers to understand the origin and evolution of the asset. -Although the manifest structure described in the C2PA specification is a complex binary structure, the CAI SDK works with a JSON manifest format that's easier to understand and use. It's essentially a declarative language for representing and creating a manifest in binary format. For more information on the CAI JSON manifest, see [Working with manifests](manifest/understanding-manifest). +Although the manifest structure described in the C2PA specification is a complex binary structure, the CAI SDK works with a JSON manifest format that's easier to understand and use. It's essentially a declarative language for representing and creating a manifest in binary format. For more information on the CAI JSON manifest, see [Working with manifests](manifest/understanding.md). -The CAI uses _cryptographic asset hashing_ to provide verifiable, tamper-evident signatures to indicate that the asset and metadata haven't been altered since the asset was published with the attached manifest. This means that a hash function converts the digital asset data to a unique "fingerprint," which is signed using a certificate. Once the credentials are signed, if the asset is changed then its fingerprint also changes. That's why it's called "tamper evident." You're not prevented from changing an image that has Content Credentials, but if you do, the credentials are no longer valid unless you change it using a tool that updates and re-hashes the credentials, along with a timestamp and optionally a description of what changed. The C2PA specification refers to this as [hard binding](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_binding_to_content). +The CAI uses _cryptographic asset hashing_ to provide verifiable, tamper-evident signatures to indicate that the asset and metadata haven't been altered since the asset was published with the attached manifest. This means that a hash function converts the digital asset data to a unique "fingerprint," which is signed using a certificate. Once the credentials are signed, if the asset is changed then its fingerprint also changes. That's why it's called "tamper evident." You're not prevented from changing an image that has Content Credentials, but if you do, the credentials are no longer valid unless you change it using a tool that updates and re-hashes the credentials, along with a timestamp and optionally a description of what changed. The C2PA specification refers to this as [hard binding](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_binding_to_content). ## Introduction to public key infrastructure @@ -92,7 +92,7 @@ For more details and a short tutorial example, see [Signing manifests](manifest/ ### Getting a security certificate -To create or modify Content Credentials, you must have a valid security certificate and key that conform to the requirements laid out in the [C2PA specification Trust Model section](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_trust_model). +To create or modify Content Credentials, you must have a valid security certificate and key that conform to the requirements laid out in the [C2PA specification Trust Model section](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_trust_model). You must purchase a X.509 v3 security certificate from a certificate authority (CA). There are many CAs that issue certificates. Some of the most popular ones are: @@ -125,14 +125,14 @@ The _private key_ associated with the certificate is extremely sensitive. Always ### Using the certificate to sign a manifest -The simplest way to add a C2PA manifest to an asset file is by using C2PA Tool (`c2patool`). You can run C2PA Tool tool manually from the command line (for example, during development) and more generally from any executable program that can call out to the shell, such as a Node.js application as shown in the [c2patool Node.js service example](c2pa-service-example). +The simplest way to add a C2PA manifest to an asset file is by using C2PA Tool (`c2patool`). You can run C2PA Tool tool manually from the command line (for example, during development) and more generally from any executable program that can call out to the shell, such as a Node.js application as shown in the [c2patool Node.js service example](c2pa-node-example/). The prerelease libraries for [Node.js](c2pa-node/), [Python](c2pa-python/), and [C++/C](c2pa-c/) 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. For a simple example of creating and signing a manifest from a C program, see the [c2c2pa repository](https://github.com/contentauth/c2c2pa). :::warning Warning -Do not access a private key and certificate directly from the file system in production. Doing so is not secure because it exposes these sensitive files to potential attackers. Instead use a hardware security module (HSM) and optionally a Key Management Service (KMS); for example as show in the [C2PA Python Example](../docs/c2pa-python-example). +Do not access a private key and certificate directly from the file system in production. Doing so is not secure because it exposes these sensitive files to potential attackers. Instead use a hardware security module (HSM) and optionally a Key Management Service (KMS); for example as show in the [C2PA Python Example](c2pa-python-example/). ::: ### Verify known certificate list diff --git a/docs/trust-list.mdx b/docs/trust-list.mdx index 8b0ffa9e..0074092b 100644 --- a/docs/trust-list.mdx +++ b/docs/trust-list.mdx @@ -20,10 +20,10 @@ The C2PA intends to publish an official public list of known certificates. Until ## Temporary known certificate list -The [contentcredentials.org](https://contentcredentials.org/) site hosts the following files that it uses to [validate signing certificates](https://c2pa.org/specifications/specifications/2.0/specs/C2PA_Specification.html#_c2pa_signers). Together, these files form the temporary known certificate list: +The [contentcredentials.org](https://contentcredentials.org/) site hosts the following files that it uses to [validate signing certificates](https://c2pa.org/specifications/specifications/2.0/specs/C2PA_Specification.html#_c2pa_signers). Together, these files form the _temporary known certificate list_: - **The temporary end-entity certificate list** in https://contentcredentials.org/trust/allowed.pem consists of end-entity certificates. If the certificate is on this list, it is considered "known." To reduce bandwidth consumption, a [version with SHA-256 hashes](https://contentcredentials.org/trust/allowed.sha256.txt) of the certificates is also available. -- **The temporary known anchor list** in https://contentcredentials.org/trust/anchors.pem contains the list of known anchor certificates. If an end-entity [certificate's chain](../getting-started#signing-and-certificates) can be traced back to an anchor certificate on this list, the certificate is considered "known." +- **The temporary known anchor list** in https://contentcredentials.org/trust/anchors.pem contains the list of known anchor certificates. If an end-entity [certificate's chain](../getting-started.mdx#signing-and-certificates) can be traced back to an anchor certificate on this list, the certificate is considered "known." - **The configuration file**, https://contentcredentials.org/trust/store.cfg, specifies the [Extended Key Usage (EKU)](https://datatracker.ietf.org/doc/html/rfc9336) values accepted for end-entity certificates. An end-entity certificate must have at least one of the EKUs in this list to be valid. ## Using the known certificate list From c1ac7fae7bad1a281cb14eed4ec5f8079996157e Mon Sep 17 00:00:00 2001 From: Rand McKinney Date: Thu, 22 Aug 2024 09:49:50 -0700 Subject: [PATCH 04/11] fix link to python example --- docs/prod-cert.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/prod-cert.mdx b/docs/prod-cert.mdx index c10a981a..24f68980 100644 --- a/docs/prod-cert.mdx +++ b/docs/prod-cert.mdx @@ -7,7 +7,7 @@ title: Getting and using a signing certificate For convenience, C2PA Tool, the Rust library, and the CAI prerelease libraries include one or more [test certificates](manifest/signing-manifests.md#test-certificates) and private keys for use during development, typically in the `tests/fixtures` directory. While these test certificates and keys are useful during development and testing, for production deployment you must use your own private key and certificate. -Certificates and private keys are often stored on a hardware security module (HSM), a physical device that attaches directly to a computer or server and is used to securely manage and perform operations on cryptographic keys. A Key Management Service (KMS) is software used to manage keys in a networked environment. A KMS can be connected to a HSM for extra security. For example, the [Python example application](/c2pa-python-example) uses [AWS KMS](https://aws.amazon.com/kms/). +Certificates and private keys are often stored on a hardware security module (HSM), a physical device that attaches directly to a computer or server and is used to securely manage and perform operations on cryptographic keys. A Key Management Service (KMS) is software used to manage keys in a networked environment. A KMS can be connected to a HSM for extra security. For example, the [Python example application](c2pa-python-example/) uses [AWS KMS](https://aws.amazon.com/kms/). ## Purchasing a certificate @@ -45,4 +45,4 @@ If you don't get an OV certificate, then the C2PA [Verify tool](https://verify.c ## The C2PA Python example -The [c2pa-python-example](/c2pa-python-example) app provides an example of constructing a certificate signing request (CSR) and of using a certificate in a way suitable for a production environment. +The [c2pa-python-example](c2pa-python-example/) app provides an example of constructing a certificate signing request (CSR) and of using a certificate in a way suitable for a production environment. From 4cbdcd412710d04dc4263c4571d8543dd0728327 Mon Sep 17 00:00:00 2001 From: Rand McKinney Date: Thu, 22 Aug 2024 11:49:47 -0700 Subject: [PATCH 05/11] fix links and typos --- docs/faqs.mdx | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/faqs.mdx b/docs/faqs.mdx index 315726dd..8880d179 100644 --- a/docs/faqs.mdx +++ b/docs/faqs.mdx @@ -14,9 +14,9 @@ The most effective approach to content provenance is a combination of technologi This "three-pronged" approach includes using: -- **Secure metadata** (Content Credentials): Verifiable information about how content was made that cannot be altered without leaving evidence of alteration. This metadata can indicate the provenance of a digital media asset and indicate how it was created. The CAI open-source SDK enables applications to create and securely attach this metdata to assets and display it to end-users. +- **Secure metadata** (Content Credentials): Verifiable information about how content was made that cannot be altered without leaving evidence of alteration. This metadata can indicate the provenance of a digital media asset and indicate how it was created. The CAI open-source SDK enables applications to create and securely attach this metadata to assets and display it to end-users. -- **Watermarking**: Hidden information undetectable by humans but that can be decoded using a specialized watermark detector. State-of-the-art watermarks can be impervious to alterations such as cropping or rotating or the addition of noise to video and audio. Importantly, a watermark can survive rebroadcasting efforts like screenshotting, pictures of pictures, or re-recording of media, which can remove secure metadata. +- **Watermarking**: Hidden information undetectable by humans but that can be decoded using a specialized watermark detector. State-of-the-art watermarks can be impervious to alterations such as cropping or rotating or the addition of noise to video and audio. Importantly, a watermark can survive rebroadcasting efforts like screen-shotting, pictures of pictures, or re-recording of media, which can remove secure metadata. - **Fingerprinting**: A way to create a unique code based on pixels, frames, or audio waveforms that can be computed and matched against other instances of the same content, even if there has been some alteration. The fingerprint can be stored separately from the content, re-computed on the fly, and matched against a database of Content Credentials and associated stored fingerprints. This technique does not require embedding of information in the media itself and is immune to information removal because there is no information to remove. @@ -37,17 +37,17 @@ Examples: No; Content Credentials do not enforce permissions for access to content. In many cases, the name displayed on the [Verify website](https://contentcredentials.org/verify) is the name of the exporter of the content, not the rights owner. -The [“Produced by” section](verify#produced-by) in Verify refers to the name of the exporter. If the image was created with an Adobe Product such as Photoshop with Content Credentials (Beta) enabled, the “Produced by” section shows the name of the Adobe ID associated with the user who exported the image. +The [“Produced by” section](verify.mdx#produced-by) in Verify refers to the name of the exporter. If the image was created with an Adobe Product such as Photoshop with Content Credentials (Beta) enabled, the “Produced by” section shows the name of the Adobe ID associated with the user who exported the image. ### Do Content Credentials indicate if an image is fake or altered? -Content Credentials don't indicate if an image is fake. They can provide information on the origin of an image and how it was edited: For example, if an AI tool supports Content Credentials, then they indicate if [an image was generated with AI](manifest/assertions-actions#generative-ai-action). If an image was taken with a C2PA-enabled camera, the Content Credentials would show that, along with any subsequent edits, if they were made with C2PA-enabled software tools. +Content Credentials don't indicate if an image is fake. They can provide information on the origin of an image and how it was edited: For example, if an AI tool supports Content Credentials, then they indicate if [an image was generated with AI](manifest/assertions-actions.md#generative-ai-action). If an image was taken with a C2PA-enabled camera, the Content Credentials would show that, along with any subsequent edits, if they were made with C2PA-enabled software tools. :::info Content Credentials provide a **positive signal** about the origin and history of an image, but they don't provide a **negative signal** about the authenticity of an image. ::: -An image with Content Credentials is like box of cereal with a nutrition label that tells you what's in it; on the other hand, an image with no Content Credentials is like a box of cerreal without any nutrition information, so you don't know what's in it or where it came from. Because the Content Credentials are cryptographically signed, you can trust the information they provide and detect if they've been tampered with. +An image with Content Credentials is like box of cereal with a nutrition label that tells you what's in it; on the other hand, an image with no Content Credentials is like a box of cereal without any nutrition information, so you don't know what's in it or where it came from. Because the Content Credentials are cryptographically signed, you can trust the information they provide and detect if they've been tampered with. ### What happens if someone takes a photo or screenshot of an existing image? @@ -60,13 +60,13 @@ The C2PA specification allows for recovery of metadata stripped from an asset th ### What information is embedded in Content Credentials? The information embedded in Content Credentials is totally up to each implementor. -The [manifest](manifest/understanding-manifest) that defines the Content Credentials +The [manifest](manifest/understanding.md) that defines the Content Credentials can include various assertions about the image, including the ingredients, the date and time, the location, and the device that created the image. ### How can I prove time and place an image was created without revealing my identity? -Content Credentials can specify identity by using the [Schema.org CreativeWork assertion](manifest/assertions-actions#creative-work-assertion), but it is _entirely optional_. +Content Credentials can specify identity by using the [Schema.org CreativeWork assertion](manifest/assertions-actions.md#creative-work-assertion), but it is _entirely optional_. For example, using Photoshop you can add Content Credentials that indicate what edits were made without saying who From 3ff0370c880879c7c462e5c58ef32bc9d6164c54 Mon Sep 17 00:00:00 2001 From: Rand McKinney Date: Thu, 22 Aug 2024 13:18:01 -0700 Subject: [PATCH 06/11] fix link to python ex app --- docs/prod-cert.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/prod-cert.mdx b/docs/prod-cert.mdx index 24f68980..07a8e366 100644 --- a/docs/prod-cert.mdx +++ b/docs/prod-cert.mdx @@ -7,7 +7,7 @@ title: Getting and using a signing certificate For convenience, C2PA Tool, the Rust library, and the CAI prerelease libraries include one or more [test certificates](manifest/signing-manifests.md#test-certificates) and private keys for use during development, typically in the `tests/fixtures` directory. While these test certificates and keys are useful during development and testing, for production deployment you must use your own private key and certificate. -Certificates and private keys are often stored on a hardware security module (HSM), a physical device that attaches directly to a computer or server and is used to securely manage and perform operations on cryptographic keys. A Key Management Service (KMS) is software used to manage keys in a networked environment. A KMS can be connected to a HSM for extra security. For example, the [Python example application](c2pa-python-example/) uses [AWS KMS](https://aws.amazon.com/kms/). +Certificates and private keys are often stored on a hardware security module (HSM), a physical device that attaches directly to a computer or server and is used to securely manage and perform operations on cryptographic keys. A Key Management Service (KMS) is software used to manage keys in a networked environment. A KMS can be connected to a HSM for extra security. For example, the [Python example application](c2pa-python-example/readme.md) uses [AWS KMS](https://aws.amazon.com/kms/). ## Purchasing a certificate From 7dfe1ea87fffd883c6cc20a80da786451f69967d Mon Sep 17 00:00:00 2001 From: Rand McKinney Date: Thu, 22 Aug 2024 14:08:21 -0700 Subject: [PATCH 07/11] more link fixes --- docs/faqs.mdx | 2 +- docs/introduction.mdx | 6 +++--- docs/other-langs.mdx | 6 +++--- docs/prod-cert.mdx | 2 +- docs/trust-list.mdx | 2 +- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/faqs.mdx b/docs/faqs.mdx index 8880d179..f29fcf0c 100644 --- a/docs/faqs.mdx +++ b/docs/faqs.mdx @@ -76,4 +76,4 @@ time. A camera could also include Exif metadata with location information. ### How do you prevent faking GPS location metadata? -The location data included in [Exif metadata](manifest/assertions-actions#exif-assertion) is based on the implementor. People would trust the data based on the various "trust signals" they are given in the manifest, such as who signed it and when. +The location data included in [Exif metadata](manifest/assertions-actions.md#exif-assertion) is based on the implementor. People would trust the data based on the various "trust signals" they are given in the manifest, such as who signed it and when. diff --git a/docs/introduction.mdx b/docs/introduction.mdx index 52b3bcea..43e355c6 100644 --- a/docs/introduction.mdx +++ b/docs/introduction.mdx @@ -29,7 +29,7 @@ To see a summary of what each tool and library can do, see [Which tool is right ### C2PA Tool -[C2PA Tool](c2patool), is a **command-line utility for working with C2PA manifest data**. Use this tool to work with assets in a supported file format to: +[C2PA Tool](c2patool/readme.md), is a **command-line utility for working with C2PA manifest data**. Use this tool to work with assets in a supported file format to: - Read a JSON report of manifest data. - Attach a manifest store to an asset, if it doesn't already have an associated manifest store. @@ -45,7 +45,7 @@ The client [JavaScript library](js-sdk/getting-started/overview.mdx) enables **w ### Prerelease libraries -The [C++/C](c2pa-c), [Python](c2pa-python), and [Node.js](c2pa-node) libraries enable applications written in those languages to **create, verify, and display Content Credentials**. +The [C++/C](c2pa-c//readme.md), [Python](c2pa-python/readme.md), and [Node.js](c2pa-node/readme.md) libraries enable applications written in those languages to **create, verify, and display Content Credentials**. :::warning Warning These libraries are all early prerelease versions. They may have bugs and unimplemented features, and their APIs are subject to change. @@ -53,7 +53,7 @@ These libraries are all early prerelease versions. They may have bugs and unimpl ### Rust library -The [Rust library](rust-sdk) enables **adding C2PA capabilities to a desktop, mobile, or embedded application**. The Rust library is the fundamental system underlying everything else. C2PA Tool uses it "under the hood" and language-specific APIs are generated from it. +The [Rust library](rust-sdk/readme.md) enables **adding C2PA capabilities to a desktop, mobile, or embedded application**. The Rust library is the fundamental system underlying everything else. C2PA Tool uses it "under the hood" and language-specific APIs are generated from it. You can use the Rust library via the Foreign Function Interface (FFI) to: diff --git a/docs/other-langs.mdx b/docs/other-langs.mdx index a1fb65b2..b6bd5cc3 100644 --- a/docs/other-langs.mdx +++ b/docs/other-langs.mdx @@ -10,6 +10,6 @@ These libraries are all early prerelease versions. They may have bugs and unimpl The prerelease libraries enable applications written in each language to create, verify, and display content credentials: -- [Node.js](c2pa-node) -- [Python](c2pa-python) -- [C++/C](c2pa-c) +- [Node.js](c2pa-node/readme.md) +- [Python](c2pa-python/readme.md) +- [C++/C](c2pa-c/readme.md) diff --git a/docs/prod-cert.mdx b/docs/prod-cert.mdx index 07a8e366..00d68a2f 100644 --- a/docs/prod-cert.mdx +++ b/docs/prod-cert.mdx @@ -45,4 +45,4 @@ If you don't get an OV certificate, then the C2PA [Verify tool](https://verify.c ## The C2PA Python example -The [c2pa-python-example](c2pa-python-example/) app provides an example of constructing a certificate signing request (CSR) and of using a certificate in a way suitable for a production environment. +The [c2pa-python-example](c2pa-python-example/readme.md) app provides an example of constructing a certificate signing request (CSR) and of using a certificate in a way suitable for a production environment. diff --git a/docs/trust-list.mdx b/docs/trust-list.mdx index 0074092b..2a9525a1 100644 --- a/docs/trust-list.mdx +++ b/docs/trust-list.mdx @@ -32,7 +32,7 @@ You can use the C2PA Tool or the CAI JavaScript library to determine whether a c ### Using with C2PA Tool -The [C2PA Tool documentation](../c2patool/#using-the-temporary-contentcredentialsorg--verify-trust-settings) explains how to use the temporary known certificate list with the tool. +The [C2PA Tool documentation](c2patool/readme.md#using-the-temporary-contentcredentialsorg--verify-trust-settings) explains how to use the temporary known certificate list with the tool. ### Using with the JavaScript library From 09b0c968f4757d288f0f9c67684c69613d18492f Mon Sep 17 00:00:00 2001 From: Rand McKinney Date: Fri, 23 Aug 2024 13:40:24 -0700 Subject: [PATCH 08/11] fix more links --- docs/manifest/assertions-actions.md | 6 +++--- docs/manifest/examples.mdx | 4 ++-- docs/manifest/ingredients.md | 2 +- docs/manifest/signing-manifests.md | 8 ++++---- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/manifest/assertions-actions.md b/docs/manifest/assertions-actions.md index 73c0d759..ccf43a3a 100644 --- a/docs/manifest/assertions-actions.md +++ b/docs/manifest/assertions-actions.md @@ -7,7 +7,7 @@ title: Assertions and actions Assertions provide information about when, where, and how an asset was created or transformed. -In the JSON manifest, each assertion is specified by a [ManifestAssertion](../manifest/manifest-ref#manifestassertion) object. All the assertions in the manifest are in the `assertions` array. A ManifestAssertion object has two required properties, `label`, a string, and `data`, which can contain arbitrary information; and two optional properties, `kind` and `instance`. +In the JSON manifest, each assertion is specified by a [ManifestAssertion](../manifest/manifest-ref.mdx#manifestassertion) object. All the assertions in the manifest are in the `assertions` array. A ManifestAssertion object has two required properties, `label`, a string, and `data`, which can contain arbitrary information; and two optional properties, `kind` and `instance`. The standard form of an assertion in a JSON manifest is: @@ -37,7 +37,7 @@ Metadata assertions must include one or more `@context` properties in the `data` ### C2PA standard assertions -The C2PA Technical Specification defines a [set of standard assertions](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_standard_c2pa_assertion_summary) and their corresponding labels. In addition, you can define [custom assertions](#custom-assertions) for your specific application. +The C2PA Technical Specification defines a [set of standard assertions](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_standard_c2pa_assertion_summary) and their corresponding labels. In addition, you can define [custom assertions](#custom-assertions) for your specific application. The following table summarizes some of the most important standard assertions. @@ -71,7 +71,7 @@ The value of each of these properties is an object with a `use` property that ca - `notAllowed`: Permission is NOT granted for this type of use. - `constrained`: Permission is not unconditionally granted for this use. You can provide more details (such as contact information) in the `constraints_info` text property. -For more information, see the [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_training_and_data_mining). +For more information, see the [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_training_and_data_mining). For example: diff --git a/docs/manifest/examples.mdx b/docs/manifest/examples.mdx index 7c5349b7..6f675dc0 100644 --- a/docs/manifest/examples.mdx +++ b/docs/manifest/examples.mdx @@ -9,9 +9,9 @@ import CodeBlock from '@theme/CodeBlock'; The C2PA [public-testfiles](https://github.com/c2pa-org/public-testfiles) repository contains numerous examples of asset files with Content Credentials. See https://c2pa.org/public-testfiles/ for links to easily inspect each asset file using Verify using [an asset URL](../verify#entering-an-asset-url) and to the corresponding [manifest report](../c2patool/#displaying-manifest-data) and [detailed manifest report](../c2patool/#detailed-manifest-report) from C2PA Tool. -## Examples from c2patool +## Examples from C2PA Tool -The command-line tool [`c2patool`](/docs/c2patool) is helpful when developing applications to work with manifest data. When saving a manifest, it has two modes: +The command-line [C2PA Tool](/docs/c2patool), `c2patool`, is helpful when developing applications to work with manifest data. When saving a manifest, it has two modes: - **Standard mode** (the default), where it saves a manifest file in JSON format, which is simplified and slightly different from the underlying binary manifest structure. - **Detailed mode** (specified with the `-d` option), where it saves a file that more closely reflects the actual structure of the binary data, including assertions with JUMBF URLs and their associated hashes. diff --git a/docs/manifest/ingredients.md b/docs/manifest/ingredients.md index 7dbd80ff..5bd1718c 100644 --- a/docs/manifest/ingredients.md +++ b/docs/manifest/ingredients.md @@ -15,7 +15,7 @@ The C2PA Technical Specification describes _ingredient assertions_ but the CAI S ## Ingredient objects -Each ingredient used to create an asset is listed in the [JSON manifest](manifest-ref) `ingredients` array. When an ingredient itself has Content Credentials, those manifests are included in the composed asset's manifest store to keep the provenance data intact. +Each ingredient used to create an asset is listed in the [JSON manifest](manifest-ref.mdx) `ingredients` array. When an ingredient itself has Content Credentials, those manifests are included in the composed asset's manifest store to keep the provenance data intact. The `ingredients` array contains an [ingredient object](manifest-ref#ingredient) for each ingredient. The only required property of the `ingredient` object is the `title` property, which usually is the source file name. diff --git a/docs/manifest/signing-manifests.md b/docs/manifest/signing-manifests.md index 71c6a343..eea7a09e 100644 --- a/docs/manifest/signing-manifests.md +++ b/docs/manifest/signing-manifests.md @@ -4,7 +4,7 @@ title: Signing manifests --- :::tip -Before reading this page, be sure to read [Getting started](/docs/getting-started) so you'll have some basic background on public-key infrastructure (PKI) technology, certificates, and signing manifests. +Before reading this page, be sure to read [Getting started](../getting-started.mdx) so you'll have some basic background on public-key infrastructure (PKI) technology, certificates, and signing manifests. ::: ## Overview @@ -72,7 +72,7 @@ The information in this table is based on the [C2PA specification Trust Model se Here is an example of generating a C2PA-compliant set of credentials using [GlobalSign](http://globalsign.com/) certificate authority (CA). :::note -GlobalSign is just one of many CAs. For a list of some others, see [Getting started](/docs/getting-started#getting-a-security-certificate). +GlobalSign is just one of many CAs. For a list of some others, see [Getting started](../getting-started.mdx#getting-a-security-certificate). :::note Credential management is a complex topic and different for every organization. See [above](#overview) for links to best practices. @@ -167,7 +167,7 @@ You now have all the needed information to configure C2PA Tool for manifest sign The `private_key` and `sign_cert` properties must be full paths to the key and certificate chain files generated above. -You can now use C2PA Tool as described in its [documentation](/docs/c2patool/#adding-a-manifest-to-an-asset-file) to add a manifest to an image or other asset file. The command will be something like this: +You can now use C2PA Tool as described in its [documentation](../c2patool/readme.md#adding-a-manifest-to-an-asset-file) to add a manifest to an image or other asset file. The command will be something like this: ``` c2patool -m my_manifest.json -o signed_image.jpg my_image.jpg @@ -176,7 +176,7 @@ c2patool -m my_manifest.json -o signed_image.jpg my_image.jpg The example above uses the information in `my_manifest.json` to add a new manifest to output `signed_image.jpg` using source `my_image.jpg`. The manifest will be signed using the PS256 signature algorithm with private key `mykey.pem`. The manifest will contain the trust chain specified in `mycerts.pem`. :::warning -In a production application, do not access a private key and certificate directly from the file system as shown in this example. Doing so is fine during development, but not in production because it exposes these sensitive files to potential attackers. Instead use a hardware security module (HSM) and optionally a Key Management Service (KMS) to access them; for example as show in the [C2PA Python Example](../../docs/c2pa-python-example). +In a production application, do not access a private key and certificate directly from the file system as shown in this example. Doing so is fine during development, but not in production because it exposes these sensitive files to potential attackers. Instead use a hardware security module (HSM) and optionally a Key Management Service (KMS) to access them; for example as show in the [C2PA Python Example](../c2pa-python-example/readme.md). ::: ### Confirm it worked From 9afe02f6846207055fd26c9adf41431c560c0108 Mon Sep 17 00:00:00 2001 From: Rand McKinney Date: Fri, 23 Aug 2024 13:55:09 -0700 Subject: [PATCH 09/11] still more link fixes --- docs/community.md | 2 +- docs/manifest/assertions-actions.md | 16 ++++++++-------- docs/manifest/signing-manifests.md | 4 ++-- 3 files changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/community.md b/docs/community.md index fc5e14bb..ec82d39f 100644 --- a/docs/community.md +++ b/docs/community.md @@ -3,7 +3,7 @@ id: community-resources title: Community resources --- -The Content Authenticity Initiative has an active and growing community of developers collaborating on the ecosystem of open-source tools and SDKs for working with digital content provenance creation and validation. +The Content Authenticity Initiative has an active and growing community of developers collaborating on the ecosystem of open-source tools and libraries for working with digital content provenance creation and validation. ## GitHub diff --git a/docs/manifest/assertions-actions.md b/docs/manifest/assertions-actions.md index ccf43a3a..a7977d2b 100644 --- a/docs/manifest/assertions-actions.md +++ b/docs/manifest/assertions-actions.md @@ -156,7 +156,7 @@ An International Press Telecommunications Council (IPTC) metadata assertion repr An IPTC assertion has the label `stds.iptc` and is stored in JSON-LD format using the XMP field names and structures specified in the IPTC standards. -Earlier versions of the C2PA specification defined the `stds.iptc.photo-metadata` label for IPTC photo metadata; the 1.3 version of the C2PA specification defines the `stds.iptc` assertion that includes video metadata as well. +Earlier versions of the C2PA specification defined the `stds.iptc.photo-metadata` label for IPTC photo metadata; starting with version 1.3, the C2PA specification defines the `stds.iptc` assertion that includes video metadata as well. :::note Do not use the IPTC `plus:DataMining` property to specify whether permission is granted to use an asset in data mining or AI/ML training. Instead use the C2PA ["do not train" assertion](#do-not-train-assertion). @@ -217,13 +217,13 @@ For example: ### Content bindings -Content bindings are standard assertions such as `c2pa.hash.boxes` and `c2pa.hash.data` that uniquely identify portions of an asset. For more information on content bindings, see the [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_binding_to_content). +Content bindings are standard assertions such as `c2pa.hash.boxes` and `c2pa.hash.data` that uniquely identify portions of an asset. For more information on content bindings, see the [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_binding_to_content). :::note 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](manifest-examples/#detailed-manifest) specifies an exclusion hash: +For example, the `c2pa.hash.data` assertion shown in the [detailed manifest example](examples.mdx/#detailed-manifest) specifies an exclusion hash: ```json "assertions": [ @@ -269,7 +269,7 @@ For example: ## Actions -Actions provide information about creation, edits, and other things that have occurred to an asset. In the manifest, an `actions` assertion is an array of [ManifestAssertion](../manifest/manifest-ref#manifestassertion) objects. For example: +Actions provide information about creation, edits, and other things that have occurred to an asset. In the manifest, an `actions` assertion is an array of [ManifestAssertion](manifest-ref.mdx#manifestassertion) objects. For example: ```json ... @@ -301,9 +301,9 @@ Each object in the `actions` array has the following standard properties. ### Action names -The value of the `action` property must be either one of the pre-defined [standard C2PA action strings](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_actions) of the form `c2pa.*` or a custom action name. The set of standard C2PA actions includes fundamental ones as `c2pa.created` for when an asset is first created, and others (`c2pa.cropped`, `c2pa.resized`, and so on) for when an asset's content is modified in some way. +The value of the `action` property must be either one of the pre-defined [standard C2PA action strings](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_actions) of the form `c2pa.*` or a custom action name. The set of standard C2PA actions includes fundamental ones as `c2pa.created` for when an asset is first created, and others (`c2pa.cropped`, `c2pa.resized`, and so on) for when an asset's content is modified in some way. -For the complete list of standard actions, see the [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_actions). +For the complete list of standard actions, see the [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_actions). ### Digital source type @@ -380,7 +380,7 @@ The `parameters` property can contain any data that provide more details on the ] ``` -For more information on action parameters, see the [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_parameters). +For more information on action parameters, see the [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_parameters). ### The instanceId property @@ -452,6 +452,6 @@ For example, the following action identifies that the `c2pa.opened` action was p ### V2 actions -This documentation covers C2PA v1 actions. The [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_actions) also describes expanded v2 actions. V1 actions are fully specified in the actions array. However, a v2 action may either be specified by an element of the actions array or from an element in the templates array with the same action name. +This documentation covers C2PA v1 actions. The [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_actions) also describes expanded v2 actions. V1 actions are fully specified in the actions array. However, a v2 action may either be specified by an element of the actions array or from an element in the templates array with the same action name. There are some additional differences between v1 and v2 actions, for example in v2, `softwareAgent` is a [ClaimGeneratorInfo](../manifest/manifest-ref#claimgeneratorinfo) structure instead of a string. The CAI APIs can read all v2 actions and write most v2 actions. diff --git a/docs/manifest/signing-manifests.md b/docs/manifest/signing-manifests.md index eea7a09e..f4b36612 100644 --- a/docs/manifest/signing-manifests.md +++ b/docs/manifest/signing-manifests.md @@ -167,7 +167,7 @@ You now have all the needed information to configure C2PA Tool for manifest sign The `private_key` and `sign_cert` properties must be full paths to the key and certificate chain files generated above. -You can now use C2PA Tool as described in its [documentation](../c2patool/readme.md#adding-a-manifest-to-an-asset-file) to add a manifest to an image or other asset file. The command will be something like this: +You can now use C2PA Tool [to add a manifest to an image or other asset file](../c2patool/readme.md#adding-a-manifest-to-an-asset-file). The command will be something like this: ``` c2patool -m my_manifest.json -o signed_image.jpg my_image.jpg @@ -176,7 +176,7 @@ c2patool -m my_manifest.json -o signed_image.jpg my_image.jpg The example above uses the information in `my_manifest.json` to add a new manifest to output `signed_image.jpg` using source `my_image.jpg`. The manifest will be signed using the PS256 signature algorithm with private key `mykey.pem`. The manifest will contain the trust chain specified in `mycerts.pem`. :::warning -In a production application, do not access a private key and certificate directly from the file system as shown in this example. Doing so is fine during development, but not in production because it exposes these sensitive files to potential attackers. Instead use a hardware security module (HSM) and optionally a Key Management Service (KMS) to access them; for example as show in the [C2PA Python Example](../c2pa-python-example/readme.md). +This example accesses the private key and certificate directly from the file system, which is fine during development, but in production may not be secure. Instead, in a production application, use a hardware security module (HSM) or a Key Management Service (KMS); for example as show in the [C2PA Python Example](../c2pa-python-example/readme.md). ::: ### Confirm it worked From 0f27805713a8229761030dd3e20fce7556fb3709 Mon Sep 17 00:00:00 2001 From: Rand McKinney Date: Fri, 23 Aug 2024 14:19:16 -0700 Subject: [PATCH 10/11] Add note about org name required by Verify --- docs/manifest/understanding.md | 4 ++-- docs/manifest/validation.md | 2 +- docs/verify.mdx | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/manifest/understanding.md b/docs/manifest/understanding.md index 94beb3a8..fa0d8982 100644 --- a/docs/manifest/understanding.md +++ b/docs/manifest/understanding.md @@ -13,7 +13,7 @@ A manifest store can be linked to an asset in three ways: 1. Directly embedded in the asset's metadata. 1. In a sidecar file, a file with the same file name as the asset but with a `.c2pa` extension. -1. In a remote URL, linked from the asset's metadata, as detailed in the [C2PA specification](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_embedding_a_reference_to_the_active_manifest). NOTE: A given asset can have a remote manifest store plus a local manifest store linked in one of the first two ways. +1. In a remote URL, linked from the asset's metadata, as detailed in the [C2PA specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_embedding_a_reference_to_the_active_manifest). NOTE: A given asset can have a remote manifest store plus a local manifest store linked in one of the first two ways. To determine if an asset has Content Credentials, the SDK checks for the presence of a manifest store (in the order shown above). So, for example to see if `foo.jpg` has Content Credentials, the SDK first checks if there's a manifest store in the file itself, then looks for a sidecar file (`foo.c2pa` in the same directory), and finally looks in the asset's metadata for a reference to a remote manifest store. @@ -48,4 +48,4 @@ The time-stamp is typically defined as part of the signing information. You can ## References - [JUMBF](https://www.iso.org/standard/84635.html): A framework for JPEG standards to add universal metadata, supplementary images, or other elements in addition to the base image. -- [C2PA Technical Specification v1.3](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html) \ No newline at end of file +- [C2PA Technical Specification v1.4](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html) \ No newline at end of file diff --git a/docs/manifest/validation.md b/docs/manifest/validation.md index dccb18e4..3f6857b1 100644 --- a/docs/manifest/validation.md +++ b/docs/manifest/validation.md @@ -3,7 +3,7 @@ id: manifest-validation title: Validating manifests --- -Processing an asset includes [validating the manifests](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_validation) in the associated manifest store. During validation, errors can occur in the active manifest and in ingredients. +Processing an asset includes [validating the manifests](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_validation) in the associated manifest store. During validation, errors can occur in the active manifest and in ingredients. ## Validation errors in manifests diff --git a/docs/verify.mdx b/docs/verify.mdx index bc140e02..75911632 100644 --- a/docs/verify.mdx +++ b/docs/verify.mdx @@ -168,7 +168,7 @@ For example, suppose you downloaded a file from Adobe Stock and renamed it `my_s **Signing information** -This section displays the the issuer of the claim signature from the `signature_info.issuer` property in the active manifest, as shown in the example snippet below. +This section displays the the issuer of the claim signature from the `signature_info.issuer` property in the active manifest, as shown in the example snippet below. It shows the organization name only if the signing certificate includes the "O" or [Organization Name attribute](https://www.alvestrand.no/objectid/2.5.4.10.html) (OID value 2.5.4.10) in the certificate's distinguished name information. If the Content Credential was signed by a certificate on the [known certificate list](verify-known-cert-list), then this section also displays the time of the claim signature from the `signature_info.time` property in the active manifest, as shown in the example snippet below. The date is converted from UTC to the local time zone. From f0399183816c28b848f2f37c972b7ec4ebcd064d Mon Sep 17 00:00:00 2001 From: Rand McKinney Date: Fri, 23 Aug 2024 14:48:41 -0700 Subject: [PATCH 11/11] Reword key/cert warning --- docs/getting-started.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/getting-started.mdx b/docs/getting-started.mdx index 03ee090c..54aaadc4 100644 --- a/docs/getting-started.mdx +++ b/docs/getting-started.mdx @@ -125,7 +125,7 @@ The prerelease libraries for [Node.js](c2pa-node/), [Python](c2pa-python/), and 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. For a simple example of creating and signing a manifest from a C program, see the [c2c2pa repository](https://github.com/contentauth/c2c2pa). :::warning Warning -Do not access a private key and certificate directly from the file system in production. Doing so is not secure because it exposes these sensitive files to potential attackers. Instead use a hardware security module (HSM) and optionally a Key Management Service (KMS); for example as show in the [C2PA Python Example](c2pa-python-example/). +Accessing a private key and certificate directly from the file system is fine during development, but doing so in production may be insecure. Instead use a Key Management Service (KMS) or a hardware security module (HSM) to access the certificate and key; for example as show in the [C2PA Python Example](https://github.com/contentauth/c2pa-python-example). ::: ### Verify known certificate list