Skip to content

Commit a6db053

Browse files
authored
Merge branch 'main' into old-new-manifests
2 parents c3dd874 + 925348b commit a6db053

File tree

11 files changed

+40
-17
lines changed

11 files changed

+40
-17
lines changed

docs/community.md

Lines changed: 13 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -29,13 +29,25 @@ We also welcome thoughtful pull requests (PRs) from the community, following the
2929

3030
Participants are required to follow the [Adobe Code of Conduct](https://github.com/contentauth/c2pa-rs/blob/main/CODE_OF_CONDUCT.md) to maintain an open and welcoming environment for all.
3131

32+
### Incubator projects
33+
34+
:::warning Warning
35+
Incubator projects are still under active development and are not yet ready for general use. However, input and bug reports are welcome in the GitHub repositories.
36+
:::
37+
38+
These projects are in early alpha release:
39+
- [iOS Library](https://github.com/contentauth/c2pa-ios): Provides iOS/macOS support via Swift Package/XCFramework.
40+
- [Android Library](https://github.com/contentauth/c2pa-android): Provides native Android support via an AAR library.
41+
42+
Both of these projects wrap the C2PA Rust implementation ([c2pa-rs](https://github.com/contentauth/c2pa-rs)) using its C API bindings.
43+
3244
### Related projects
3345

3446
These related projects may be of interest, but the CAI team doesn't maintain or support them:
3547

3648
- [**Drupal module**](https://github.com/contentauth/c2pa-drupal): Enables Drupal sites to process and display Content Credentials for supported image types.
3749
- [**DASH video player**](https://github.com/contentauth/dash.js/tree/c2pa-dash): DASH video player that displays Content Credentials in browsers for supported media types. This repo/branch is a work-in-progress forked from [dash.js](https://github.com/Dash-Industry-Forum/dash.js), the canonical reference JavaScript implementation for the playback of MPEG DASH.
38-
- [**TrustMark**](https://github.com/adobe/trustmark): Open-source Python implementation of watermarking for encoding, decoding and removing image watermarks.
50+
- [**TrustMark**](https://github.com/adobe/trustmark): Open-source Python implementation of watermarking for encoding, decoding and removing image watermarks. You can use TrustMark as part of providing [durable content credentials](durable-cr.md).
3951
- [**C2PA Security Testing Tool**](https://github.com/contentauth/c2pa-attacks): A CLI tool derived from [c2patool](https://github.com/contentauth/c2patool) that performs security testing on a Content Credentials application. This tool is intended for use by software security professionals.
4052

4153
## Discussions on Discord

docs/durable-cr.md renamed to docs/durable-cr/index.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
---
2-
id: durable-cr
2+
id: index
33
title: Durable Content Credentials
44
---
55

File renamed without changes.

docs/trustmark-faq.mdx renamed to docs/durable-cr/trustmark-faq.mdx

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -47,6 +47,6 @@ hide_table_of_contents: true
4747
- [Is TrustMark compatible with blockchain technology?](#is-trustmark-compatible-with-blockchain-technology)
4848
- [Can TrustMark be used for NFT provenance?](#can-trustmark-be-used-for-nft-provenance)
4949

50-
import Faq from './trustmark/FAQ.md';
50+
import Faq from '../trustmark/FAQ.md';
5151

5252
<Faq name="faq" />

docs/trustmark-intro.md renamed to docs/durable-cr/trustmark-intro.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@ TrustMark is an open-source universal watermarking system for images that:
1010
- Has implementations in Python (using PyTorch), [Rust](trustmark/rust/README.md), and [JavaScript](trustmark/js/README.md) (both using ONNX).
1111

1212
:::info
13-
For full technical details and help getting started with TrustMark, see [TrustMark - Overview](trustmark/readme.md).
13+
For full technical details and help getting started with TrustMark, see [TrustMark - Overview](trustmark/README.md).
1414
:::
1515

1616
## Variants

docs/getting-started.mdx

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,7 @@ The CAI open-source SDK is fully compliant with the C2PA specification, but it's
1515

1616
## Important terminology
1717

18-
To understand how CAI works, you need to understand some basic vocabulary. Having this vocabulary makes it easier to discuss CAI's technical aspects. The definitions below are summarized and slightly simplified from the [Glossary in the C2PA specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_glossary). This document is meant to convey the general concepts and may not cover all technical details or edge cases that the specification addresses.
18+
To understand how CAI works, you need to understand some basic vocabulary. Having this vocabulary makes it easier to discuss CAI's technical aspects. The definitions below are summarized and slightly simplified from the [Glossary in the C2PA specification](https://c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_glossary). This document is meant to convey the general concepts and may not cover all technical details or edge cases that the specification addresses.
1919

2020
Let's start with a broad definition of _content provenance_ which means information on the creation, authorship, and editing of a digital asset such as an image. _Content Credentials_ include this provenance information, along with the cryptographic means to authenticate that the information is correctly tied to the content and is unchanged from when it was originally added. Sometimes these two terms are used to loosely mean the same thing: Technology to verify the origin and history of a digital asset.
2121

@@ -33,7 +33,7 @@ Now, let's drill down a bit to clarify some of these terms.
3333

3434
**Action**: An operation that an _actor_ performs on an _asset._ For example, "create," "embed," or "change contrast."
3535

36-
**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).
36+
**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/2.2/specs/C2PA_Specification.html#_c2pa_standard_assertions).
3737

3838
**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.
3939

@@ -53,15 +53,15 @@ Now, let's drill down a bit to clarify some of these terms.
5353

5454
**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.
5555

56-
For more definitions and detail, see the [C2PA specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_glossary).
56+
For more definitions and detail, see the [C2PA specification](https://c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_glossary).
5757

5858
## How it works
5959

6060
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.
6161

6262
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).
6363

64-
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).
64+
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/2.2/specs/C2PA_Specification.html#_binding_to_content).
6565

6666
## Introduction to public key infrastructure
6767

@@ -98,7 +98,7 @@ The C2PA [Verify tool](https://contentcredentials.org/verify) uses a list of _kn
9898

9999
## Identity
100100

101-
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.
101+
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 v1.4 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.
102102

103103
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.
104104

docs/introduction.mdx

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -184,7 +184,7 @@ C2PA provides the formal technical specifications and open standards for content
184184
The "cr" icon is trademarked by the C2PA and is the _de facto_ mark for C2PA user experiences. C2PA members can use this icon to provide a consistent user experience and set expectations that an application, tool, or website implements C2PA standards.
185185

186186
:::info
187-
For detailed guidance on using the "cr" icon, see [C2PA User Experience Guidance for Implementers](https://c2pa.org/specifications/specifications/1.4/ux/UX_Recommendations.html#_l1_indicator_of_c2pa_data).
187+
For detailed guidance on using the "cr" icon, see [C2PA User Experience Guidance for Implementers](https://c2pa.org/specifications/specifications/2.0/ux/UX_Recommendations.html#_l1_indicator_of_c2pa_data).
188188
:::
189189

190190
### CAI

docs/js-sdk/getting-started/overview.mdx

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -43,8 +43,8 @@ Key features of the JavaScript library include:
4343
- **Developer friendly**: Full TypeScript support and robust debugging support using the [debug](https://github.com/debug-js/debug) library make integration easy.
4444
- **Performance**: The processing code of the library uses a high-performance [WebAssembly](https://developer.mozilla.org/en-US/docs/WebAssembly) binary. Additionally, the library offloads processing tasks to a configurable Web Worker pool to enable parallelization and avoid blocking a web application's main thread.
4545
- **Lazy loading and processing**: Since images can be quite large, the library inspects the start of an asset file for C2PA manifest data before requesting the entire file, [if the server supports it](../guides/hosting#range-requests). The library will download the rest of the asset only if it finds the metadata marker. Additionally, it delays loading the WebAssembly binary until it makes the first processing request.
46-
- **Adherence to the C2PA specification**: The library strives to maintain compliance with the [C2PA specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html) as much as possible, and the web components follow the [C2PA user experience guidance](https://c2pa.org/specifications/specifications/1.0/ux/UX_Recommendations.html) recommendations.
47-
- **Security and encryption**: The library handles all [validation](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_validation) via the [Web Crypto API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API) and passes any validation errors back to the client. It supports all ECDSA and RSASSA-PSS algorithms listed in the [C2PA specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_digital_signatures).
46+
- **Adherence to the C2PA specification**: The library strives to maintain compliance with the [C2PA specification](https://c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html) as much as possible, and the web components follow the [C2PA user experience guidance](https://c2pa.org/specifications/specifications/1.0/ux/UX_Recommendations.html) recommendations.
47+
- **Security and encryption**: The library handles all [validation](https://c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_validation) via the [Web Crypto API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API) and passes any validation errors back to the client. It supports all ECDSA and RSASSA-PSS algorithms listed in the [C2PA specification](https://c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_digital_signatures).
4848
:::caution
4949
The JavaScript library does not currently support Ed25519 signatures.
5050
:::caution

docs/manifest/understanding.md

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -54,4 +54,5 @@ The time-stamp is typically defined as part of the signing information. You can
5454
## References
5555

5656
- [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.
57-
- [C2PA Technical Specification v2.2](https://c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html)
57+
- [C2PA Technical Specification v2.2](https://c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html)
58+

scripts/fetch-readme.js

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -142,6 +142,11 @@ const readmes = [
142142
repo: 'contentauth/c2pa-python',
143143
path: 'docs/release-notes.md',
144144
},
145+
{
146+
dest: resolve(__dirname, '../docs/c2pa-python/docs/examples.md'),
147+
repo: 'contentauth/c2pa-python',
148+
path: 'examples/README.md',
149+
},
145150
{
146151
dest: resolve(__dirname, '../docs/c2pa-python-example/readme.md'),
147152
repo: 'contentauth/c2pa-python-example',

0 commit comments

Comments
 (0)