diff --git a/.gitignore b/.gitignore index 353af2d..be7cfe5 100644 --- a/.gitignore +++ b/.gitignore @@ -4,3 +4,4 @@ node_modules/* package-lock.json alex-out.txt links-out.txt +/.vscode diff --git a/build/site/specifications/2.1/specs/C2PA_Specification.html b/build/site/specifications/2.1/specs/C2PA_Specification.html index 3ec51fc..09417fd 100644 --- a/build/site/specifications/2.1/specs/C2PA_Specification.html +++ b/build/site/specifications/2.1/specs/C2PA_Specification.html @@ -1095,10 +1095,10 @@

5. Versioning

5.1. Compatibility

-

As the Content Credentials specification has evolved, constructs such as box labels, assertions (and their fields), claims and time-stamps have also evolved. New assertions have been added, and some existing assertions and the claim have newer versions with additional fields. In addition, some constructs have been deprecated. In this specification, when a construct is marked as deprecated, that means that a claim generator shall not write that construct (or value), but that a validator should read it.

+

As the Content Credentials specification has evolved, constructs such as box labels, assertions (and their fields), claims and time-stamps have also evolved. New assertions have been added, and some existing assertions and claims have newer versions with additional fields. In addition, some constructs have been deprecated. In this specification, when a construct is marked as deprecated, that means that a claim generator shall not write that construct (or value), but that a validator should read it.

-

To facilitate interoperability between claim generators and validators, a claim generator declares which version of the specification it is using to generate the claim. When a claim generator declares that it is using a version of the specification, it is declaring that the active manifest of the asset is produced in accordance with that version of the specification and thus does not contain any deprecated constructs listed under that version of the specification in Table 19, “Deprecated Constructs” of Appendix C, Considerations for Deprecation.

+

To facilitate interoperability between claim generators and validators, a claim generator declares which version of the specification it is using to generate the claim. When a claim generator declares that it is using a version of the specification, it is declaring that the active manifest of the asset is produced in accordance with that version of the specification and thus does not contain any deprecated constructs listed under that version of the specification in Table 19, “Deprecated Constructs” of Appendix C, Considerations for Deprecation.

@@ -1331,7 +1331,7 @@

5

5.2.2. 2.0 - January 2024

-

This version represents a significant departure from previous versions. It reduces the use of the term "actor", which no longer represents humans and organisations. In addition to validator-configured trust lists, it also introduces a new default trust list, the "C2PA Trust List", which is intended to cover certificates issued to hardware and software. This philosophical change led to the following functional changes in the specification:

+

This version represents a significant departure from previous versions. It reduces the use of the term "actor", which no longer represents humans and organizations. In addition to validator-configured trust lists, it also introduces a new default trust list, the "C2PA Trust List", which is intended to cover certificates issued to hardware and software. This philosophical change led to the following functional changes in the specification:

    @@ -5044,10 +5044,10 @@

    15.5.4. Dec

    15.5.5. Validating a Match

    -

    A validator may wish to validate that the located C2PA Manifest Store is indeed the one associated with asset.

    +

    A validator may wish to validate that the located C2PA Manifest Store is indeed the one associated with the asset.

    -

    If the C2PA Manifest Store was located then the hard binding assertion present in its active manifest shall be used to validate that it is the matching manifest and whether the asset has been modified without manifest updates. If the hard binding does not match, it is unknown if that is because of (a) modification of the asset or (b) the wrong C2PA Manifest Store was located. Accordingly, the validator shall treat this as a non-matching hard binding and reject the manifest with a failure code of assertion.dataHash.mismatch if a data hash assertion is used, assertion.boxesHash.mismatch if a general boxes hash assertion is used, assertion.collectionHash.mismatch if a collection data hash assertion is used, or assertion.bmffHash.mismatch if a BMFF hash assertion is used.

    +

    If the C2PA Manifest Store was located, the hard binding assertion present in its active manifest shall be used to validate that the C2PA Manifest Store is the matching manifest. Additionally, the validator will check whether the asset has been modified without manifest updates. If the hard binding does not match, it is unknown if that is because of (a) modification of the asset or (b) the wrong C2PA Manifest Store was located. Accordingly, the validator shall treat this as a non-matching hard binding and reject the manifest with a failure code of assertion.dataHash.mismatch if a data hash assertion is used, assertion.boxesHash.mismatch if a general boxes hash assertion is used, assertion.collectionHash.mismatch if a collection data hash assertion is used, or assertion.bmffHash.mismatch if a BMFF hash assertion is used.