Skip to content

Commit c3dd874

Browse files
committed
Reorg files and add some new files to cover all reading/writing cases separately
1 parent d170f89 commit c3dd874

14 files changed

+298
-193
lines changed

docs/manifest/ingredients.md

Lines changed: 0 additions & 120 deletions
This file was deleted.

docs/manifest/reading.md

Lines changed: 0 additions & 13 deletions
This file was deleted.

docs/manifest/ingredients-reading.md renamed to docs/manifest/reading/ingredients-reading.md

Lines changed: 6 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,13 @@
11
---
22
id: reading-ingredients
3-
title: Reading ingredient data
3+
title: Reading ingredients
44
---
55

66
## Overview
77

8-
The C2PA specification defines three kinds of ingredients:
9-
- V1, with label `c2pa.ingredient`.
10-
- V2, with label `c2pa.ingredient.v2`.
8+
Existing manifests may contain any of these three kinds of ingredients:
9+
- V1, with label `c2pa.ingredient` (deprecated).
10+
- V2, with label `c2pa.ingredient.v2` (deprecated).
1111
- V3, with label `c2pa.ingredient.v3`, which addresses the issue of validating ingredients after redaction.
1212

1313
:::note
@@ -18,7 +18,7 @@ The C2PA Technical Specification describes _ingredient assertions_ but the CAI S
1818

1919
The `ingredients` array contains an element for each ingredient used to create an asset. When an ingredient itself has Content Credentials, those manifests are included in the composed asset's manifest store to keep the provenance data intact.
2020

21-
The `ingredients` array contains an [ingredient object](json-ref/manifest-def.mdx#ingredient) for each ingredient. The only required property of the `ingredient` object is the `title` property, which usually is the source file name.
21+
The `ingredients` array contains an [ingredient object](manifest/json-ref/manifest-def.mdx#ingredient) for each ingredient. The only required property of the `ingredient` object is the `title` property, which usually is the source file name.
2222

2323
Other important properties of the ingredient object include:
2424
- `format`: MIME type of the source file (optional).
@@ -58,9 +58,7 @@ The ingredient object's `relationship` property describes its relationship to th
5858

5959
## Validation results
6060

61-
_This is now validation results_
62-
63-
json-ref/reader#validationresults
61+
The [ValidationResults](/docs/manifest/json-ref/reader#validationresults) object contains the the validation results for the active manifest and any changes to ingredients.
6462

6563
When ingredients are added, the SDK validates their Content Credentials (if any). However, the validation status of an ingredient does not imply anything about the validation status of the composed asset containing the ingredient. In other words:
6664
- A composed asset's Content Credentials may be valid, but one or more of its ingredients may have invalid Content Credentials. For example, test file [adobe-20220124-XCA.jpg](https://contentcredentials.org/verify?source=https://c2pa.org/public-testfiles/image/jpeg/adobe-20220124-XCA.jpg)

docs/manifest/legacy.md renamed to docs/manifest/reading/legacy.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -130,4 +130,4 @@ Old manifests may have training and data mining assertions with the following en
130130
- `c2pa.ai_generative_training`
131131
- `c2pa.ai_inference`
132132

133-
These assertions have been replaced by [CAWG training and data mining assertions](assertions-actions.md#cawg-training-and-data-mining-assertion) with `cawg.*` entry keys.
133+
These assertions have been replaced by [CAWG training and data mining assertions](../writing/assertions-actions.md#cawg-training-and-data-mining-assertion) with `cawg.*` entry keys.
Lines changed: 155 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,155 @@
1+
---
2+
id: reading-cawg-id
3+
title: Reading CAWG identity assertions
4+
---
5+
6+
The [Creator Assertions Working Group (CAWG)](https://cawg.io/) identity assertion enables a credential holder to prove control over a digital identity and to use that identity to document a content creator’s role(s) in a C2PA asset’s lifecycle.
7+
8+
<div class="review-comment">
9+
Revise to focus on reading these assertions.
10+
</div>
11+
12+
The SDK can read and validate CAWG identity assertions provided:
13+
14+
- Using an [X.509 certificate](https://cawg.io/identity/1.1/#_x_509_certificates_and_cose_signatures) to sign the identity claims. Enterprises or large organizations can use this approach to assert their identity in a particular trust ecosystem; for example, a news organization or publisher. The SDK can validate and sign these claims.
15+
- Using an [identity claim aggregator](https://cawg.io/identity/1.1/#_identity_claims_aggregation). Individuals can use this approach to document their role in creating an asset by using identity signals collected and verified by a third-party aggregator. The SDK can validate these claims only. Signing is not supported.
16+
17+
## Identity assertions provided using an X.509 certificate
18+
19+
In an identity assertion by using an X.509 certificate, the value of `signer_payload.sig_type` is `cawg.x509.cose`. The signature value must be a COSE signature as described in the [CAWG Identity Assertion technical specification](https://cawg.io/identity/1.1/#_x_509_certificates_and_cose_signatures).
20+
21+
## Identity assertions provided using a claim aggregator
22+
23+
As defined in the [CAWG Identity Assertion technical specification](https://cawg.io/identity/1.1/#_identity_claims_aggregation), an identity assertion can be signed using a trusted third-party intermediary known as a _identity claims aggregator_ to gather these signals and to restate them on their behalf.
24+
25+
The identity claims aggregator:
26+
27+
- Collects and verifies identity attestation claims from various identity providers such as social media sites and ID verification vendors.
28+
- Creates a unique asset-specific credential that binds the identity attestation claims to a specific asset.
29+
30+
## Identity assertion
31+
32+
An identity assertion using an identity claims aggregator has this general form in JSON:
33+
34+
```json
35+
"assertions": [
36+
...
37+
{
38+
"label": "cawg.identity",
39+
"data": {
40+
"@context": [
41+
"https://www.w3.org/ns/credentials/v2",
42+
"https://cawg.io/identity/1.1/ica/context/"
43+
],
44+
"type": [
45+
"VerifiableCredential",
46+
"IdentityClaimsAggregationCredential"
47+
],
48+
"issuer": "did:web:connected-identities.identity.adobe.com",
49+
"validFrom": "2025-04-29T17:34:44Z",
50+
"verifiedIdentities": [
51+
{
52+
"type": "cawg.<type>",
53+
"username": "<string>",
54+
"uri": "<uri>",
55+
"verifiedAt": "<DateTime>",
56+
"provider": {
57+
"id": "<string>",
58+
"name": "<string>"
59+
}
60+
},
61+
...
62+
]
63+
}
64+
}
65+
]
66+
```
67+
68+
### Verified identity types
69+
70+
The following table describes the allowed values of the `type` property of `verifiedIdentities` array elements.
71+
72+
| Value | Meaning |
73+
|--------------|----------|
74+
| `cawg.document_verification` | The identity provider verified one or more government-issued identity documents presented by the content creator.
75+
| `cawg.web_site` | The content creator has proven control over a specific domain to the identity claims aggregator._
76+
| `cawg.affiliation` | The identity provider is attesting to the content creator’s membership in an organization. This could be a professional organization or an employment relationship.
77+
| `cawg.social_media` | The content creator has demonstrated control over an account (typically a social media account) hosted by the identity provider.
78+
| `cawg.crypto_wallet` | The content creator has demonstrated control over an account (typically a crypto-wallet) hosted by the identity provider.
79+
80+
:::note
81+
The above table is based on the [CAWG identity assertion technical specifications](https://cawg.io/identity/1.1/#vc-credentialsubject-verifiedidentity-type).
82+
:::
83+
84+
### Example
85+
86+
```json
87+
"assertions": [
88+
...
89+
{
90+
"label": "cawg.identity",
91+
"data": {
92+
"@context": [
93+
"https://www.w3.org/ns/credentials/v2",
94+
"https://cawg.io/identity/1.1/ica/context/"
95+
],
96+
"type": [
97+
"VerifiableCredential",
98+
"IdentityClaimsAggregationCredential"
99+
],
100+
"issuer": "did:web:connected-identities.identity.adobe.com",
101+
"validFrom": "2025-04-29T17:34:44Z",
102+
"verifiedIdentities": [
103+
{
104+
"type": "cawg.social_media",
105+
"username": "xyz",
106+
"uri": "https://www.instagram.com/xyz",
107+
"verifiedAt": "2024-10-08T18:04:08Z",
108+
"provider": {
109+
"id": "https://instagram.com",
110+
"name": "instagram"
111+
}
112+
},
113+
{
114+
"type": "cawg.social_media",
115+
"username": "xyz",
116+
"uri": "https://www.behance.net/xyz",
117+
"verifiedAt": "2024-10-22T19:31:17Z",
118+
"provider": {
119+
"id": "https://behance.net",
120+
"name": "behance"
121+
}
122+
},
123+
{
124+
"type": "cawg.social_media",
125+
"username": "J Smith",
126+
"uri": "https://www.linkedin.com/in/jsmith",
127+
"verifiedAt": "2024-10-08T18:03:41Z",
128+
"provider": {
129+
"id": "https://linkedin.com",
130+
"name": "linkedin"
131+
}
132+
},
133+
{
134+
"type": "cawg.social_media",
135+
"username": "xyz",
136+
"uri": "https://twitter.com/xyz",
137+
"verifiedAt": "2024-10-08T18:03:49Z",
138+
"provider": {
139+
"id": "https://twitter.com",
140+
"name": "twitter"
141+
}
142+
}
143+
],
144+
"credentialSchema": [
145+
{
146+
"id": "https://cawg.io/identity/1.1/ica/schema/",
147+
"type": "JSONSchema"
148+
}
149+
]
150+
}
151+
}
152+
...
153+
]
154+
```
155+

docs/manifest/reading/reading.md

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
---
2+
id: reading-index
3+
title: Reading and validating manifest data
4+
---
5+
6+
Use a [Reader](manifest/json-ref/reader.mdx) structure to read and validate manifest data. The Rust library and other language libraries provide methods and objects for working with this structure.
7+
8+
- [Reading ingredients](ingredients-reading.md)
9+
- [Reading CAWG identity assertions](reading-cawg-id.md)
10+
- [Reading legacy manifest data](legacy.md)
11+
- [Validating manifests](validation.md)
12+
- [Reader JSON reference](manifest/json-ref/reader.mdx) generated from the JSON schema for [Reader](https://docs.rs/c2pa/latest/c2pa/struct.Reader.html) object (_struct_ in Rust terminology).

docs/manifest/validation.md renamed to docs/manifest/reading/validation.md

Lines changed: 5 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -3,11 +3,11 @@ id: manifest-validation
33
title: Validating manifests
44
---
55

6-
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.
6+
Processing an asset includes [validating the manifests](https://c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_validation) in the associated manifest store. During validation, errors can occur in the active manifest and in ingredients.
77

88
## Validation errors in manifests
99

10-
When you load an asset, all the manifests in the manifest store are validated and any [failure codes](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_failure_codes) are assigned to the `validation_status` array. Inspect the array to find the validation errors.
10+
When you load an asset, all the manifests in the manifest store are validated and any [failure codes](https://c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_failure_codes) are assigned to the `validation_status` array. Inspect the array to find the validation errors.
1111

1212
:::tip
1313
Validation returns ONLY error codes; success is not explicitly indicated. If there are no validation errors, then the manifest won't have the `validation_status` element.
@@ -27,11 +27,11 @@ Don't assume that just because you didn't get an error from the function return
2727

2828
Ingredients are validated when they are imported into an asset and the result is stored in the ingredient's `validation_status` array.
2929

30-
Only errors that are not already recorded in the `validation_status` of an ingredient are reported. See [ValidationStatus](./manifest-ref.mdx#validationstatus) object in Manifest store reference.
30+
Only errors that are not already recorded in the `validation_status` of an ingredient are reported. See [ValidationStatus](../json-ref/manifest-def.mdx#validationstatus) object in Manifest store reference.
3131

3232
## Error status codes
3333

34-
The following table describes some common validation error status codes. Refer to the [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_failure_codes) for the full list.
34+
The following table describes some common validation error status codes. Refer to the [C2PA Technical Specification](https://c2pa.org/specifications/specification2.2/specs/C2PA_Specification.html#_failure_codes) for the full list.
3535

3636
| Validation Status Code| Description | Type of URI |
3737
| --------------------- | ------------ | ----------- |
@@ -51,7 +51,7 @@ Validation error status codes can contain JUMBF URIs that reference assertions o
5151
- **Assertion URI**: A URI like `self#jumbf=c2pa.assertions/<ASSERTION>` where `<ASSERTION>` is either `stds.schema-org.*` or `c2pa.*`.
5252
- **Signature Box URI**: A URI like `self#jumbf=c2pa.signature`.
5353

54-
For more information, see the [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_uri_references).
54+
For more information, see the [C2PA Technical Specification](https://c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_uri_references).
5555

5656
<!--
5757
Actions and assertions:
@@ -73,7 +73,5 @@ Assertions
7373
- DNT - Special assertion
7474
- EXIF
7575
76-
Verify has a URL - how do I put it in?
77-
7876
User-defined assertion
7977
-->

0 commit comments

Comments
 (0)