Merge pull request #160 from contentauth/fix-rel-links

Change links to be to files not urls

Author: crandmck

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
 

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
@@ -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.

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
 
@@ -87,12 +87,12 @@ 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
 
-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:
 
@@ -118,14 +118,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).
+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
@@ -136,7 +136,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.
 
@@ -220,7 +220,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.