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.
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 [deprecated_constructs_table] of [versioning_annex].
+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.
A validator shall be compatible with at least one version of the specification, but may be compatible with additional versions. A validator that is compatible with a specific version of the specification shall support all non-deprecated constructs listed for that version. If the validator encounters a manifest that uses constructs from a version of the specification that the validator does not support (either because they are deprecated or unknown), it may ignore the deprecated construct and process the rest of manifest as if that construct were not present. Alternatively, the validator may treat the entire manifest as having unknown provenance, by returning either the ingredient.unknownProvenance or manifest.unknownProvenance status code as appropriate.
-# Version History
2.1 - July 2024
+A validator shall be compatible with at least one version of the specification, but may be compatible with additional versions. A validator that is compatible with a specific version of the specification shall support all non-deprecated constructs listed for that version. If the validator encounters a manifest that uses constructs from a version of the specification that the validator does not support (either because they are deprecated or unknown), it may ignore the deprecated construct and process the rest of manifest as if that construct were not present. Alternatively, the validator may treat the entire manifest as having unknown provenance, by returning either the ingredient.unknownProvenance or manifest.unknownProvenance status code as appropriate.
This version focuses on both technical and editorial changes to the specification for the purposes of improving the security and reliability of Content Credentials. All publicly disclosed security vulnerabilities have been addressed, and the specification has been updated to reflect the latest best practices in the field.
+Clear definitions of Manifest & Asset states
Well-formed Manifests
+Valid Manifests
+Trusted Manifests
+Valid Assets
+Clear definitions and processes for handling deprecation and versioning
+New c2pa URN namespace for labelling manifests!
including a fully specified ABNF
+New ingredients v3 assertion
Added new validation status fields to accompany the new status info
dc:title and dc:format are now optional
New c2pa.hash.bmff.v3 assertion
Supports hashing of fixed & variable block sizes for BMFF-based assets
+Detailed validation instructions for all standard assertions
+Validation of ingredients is now required when using the ingredients assertion
Hashed URIs to data boxes, and any custom boxes, are now validated
Defined procedure for handling manifests with matching unique IDs
+Address "orphaned manifests" in the validation process
+LOTS of new validation status codes, including a new "informational" code type
Either a c2pa.created or a c2pa.opened is now mandatory in a standard manifest
Some new standard action types were added
Added some missing compatibility support for JPEG Trust
Cleaned up all CDDLs, including removing any normative language
+And various areas of editorial improvements
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:
If the current URN does not contain a "Claim Generator identifier string", then the claim generator shall append a :.
In all cases, the claim generator shall append a : to the URN followed by a monotonically increasing integer, starting with 1, followed by an underscore (_) and then an integer from the list below representing the reason for the re-labeling.
1: Conflict with another C2PA Manifest
For example, if the claim generator has to re-label a C2PA Manifest for the second time due to a conflict, the appended string would be :2_1.
6332746D-0011-0010-8000-00AA00389B71 (c2tm)) to add the time-stamp in a later operation when a TSA can be contacted.
A Time-Stamp Manifest shall contain only a single assertion, which is the c2pa.ingredient.v3 assertion that (a) includes a activeManifest field with a value that is the URI reference to that C2PA Manifest that is being updated and (b) has the value of parentOf for the relationship field.
A Time-Stamp Manifest shall contain only a single assertion, which is the c2pa.ingredient.v3 assertion that (a) includes an activeManifest field with a value that is the URI reference to that C2PA Manifest that is being updated and (b) has the value of parentOf for the relationship field.
If a validator reports that the portions of the asset that are covered by content bindings have not been modified since the active manifest was produced [Section 15.12, “Validate the Asset’s Content”], and its active manifest is either Valid or Trusted, then the asset itself can be considered to be a Valid asset.
A C2PA Manifest is Well-Formed if validation determines that each of the following is true:
The assertions of the manifest meet all the requirements for assertions [Section 15.10.3, “Assertion Validation”].
Any ingredients present in the manifest meet all the requirements for ingredients[Section 15.11, “Validate the Ingredients”].
+Any ingredients present in the manifest meet all the requirements for ingredients [Section 15.11, “Validate the Ingredients”].
A C2PA Manifest is Valid if validation determines that each of the following is true:
The manifest is Well-Formed [Section 14.3.1, “Well-Formed Manifest”].
+The manifest is Well-Formed [Section 14.3.4, “Well-Formed Manifest”].
The manifest has not been modified since the manifest was signed [Section 13.2.5, “Cryptographic validation”].
@@ -3703,14 +3778,14 @@A C2PA Manifest is Trusted if validation determines that each of the following is true:
The manifest is Valid [Section 14.3.2, “Valid Manifest”].
+The manifest is Valid [Section 14.3.5, “Valid Manifest”].
The signing credential of the C2PA Manifest receives the success code of signingCredential.trusted [Section 15.7, “Validate the Signature”].
timeStamp.untrusted
The time-stamp credential is not listed on the validator’s trust lists.
The time-stamp credential is not listed on the validator’s TSA trust lists.
C2PA Claim Signature Box
Manifest Consumers should not display data from manifests which are not Valid. If the Manifest Consumer chooses to display such data, it shall include as part of the display:
+Manifest Consumers should not display data from manifests which are not Valid nor from assets which are not Valid. If the Manifest Consumer chooses to display such data, it shall include as part of the display:
The last C2PA Manifest superbox in the C2PA Manifest Store superbox shall be considered the active manifest, but locating the C2PA Manifest Store may involve looking in a number of possible locations.
The C2PA Manifest Store shall be located by the validator embedded inside the asset at the standard locations for embedding manifests. However, if an asset was retrieved via an HTTP connection, a validator may look for a Link header, as described in the Link Header clause below, to determine if a C2PA Manifest Store is present.
Retrieve the val property from the tstToken, which shall be an RFC3161-compliant TimeStampResp (time-stamp response)
Retrieve the val property from the tstToken, which shall be an RFC3161-compliant TimeStampResp (time-stamp response).
Check the value of the status field PKIStatusInfo, which is the value of the status field of TimeStampResp.
A validator will encounter one of two scenarios:
+A validator will encounter one of the following three scenarios:
Depending on the type of manifest, there are assertions that are either required or forbidden. A validator shall check for required and not-permitted assertions.
Validate that there is exactly one hard binding to content assertion - either a c2pa.hash.data, a c2pa.hash.boxes, a c2pa.hash.collection.data, c2pa.hash.bmff.v2 (deprecated), or a c2pa.hash.bmff.v3 based on the type of asset for which the manifest is destined. If no such assertion is present, the manifest shall be rejected with a failure code of claim.hardBindings.missing. If there is more than one such assertion, the manifest shall be rejected with a failure code of assertion.multipleHardBindings.
Validate that there is exactly one hard binding to content assertion - either a c2pa.hash.data, a c2pa.hash.boxes, a c2pa.hash.collection.data, c2pa.hash.bmff.v2 (deprecated), or a c2pa.hash.bmff.v3. If no such assertion is present, the manifest shall be rejected with a failure code of claim.hardBindings.missing. If there is more than one such assertion, the manifest shall be rejected with a failure code of assertion.multipleHardBindings.
Validate that there are zero or one c2pa.ingredient assertions whose relationship is parentOf. If there is more than one, the manifest shall be rejected with a failure code of manifest.multipleParents.
Each assertion in the created_assertions and gathered_assertions fields of the claim is a hashed_uri structure. For each assertion, the validator shall first determine if the URI reference in the url field is in the list of redacted assertions.
The contents of a cloud data assertion contains the URI references to and hashes of external data, are validated like any other assertion, but those references are not retrieved and validated as part of standard validation. A validator shall first successfully validate a claim before attempting to retrieve the external data referenced. A validator shall not attempt to retrieve external data from a rejected claim. As the retrieval of external data is optional, the inability to retrieve or validate external data shall not cause a claim to become rejected.
If the current manifest is an update manifest, its hard bindings shall be inherited from the parentOf ingredient’s manifest. If that manifest is also an update manifest, the search for a standard manifest shall recurse though the chain of ingredients. If no standard manifest is found, then the manifest shall be rejected with a failure code of manifest.update.wrongParents.
The asset’s content shall be validated using the hard binding in the active manifest if the active manifest is a standard manifest. If the active manifest is an update or time-stamp manifest, the hard binding shall be found in the parentOf ingredient’s manifest, or if that manifest is also an update or time-stamp manifest, by following the chain of parentOf ingredients to the first standard manifest. If no standard manifest is found, or the standard manifest has no hard binding, then the malformed manifest shall be rejected in accordance with Section 15.10.1, “Validate the correct assertions for the type of manifest”.
Once a standard manifest (and its bindings) has been located, the exclusion range(s) shall be extracted from the c2pa.hash.data assertion.
Validation of a collection data hash assertion (c2pa.hash.collection.data) that has been located in a standard manifest shall be performed by iterating over the array of uris in the collection-data-hash-map. If there is no uris field present, then the manifest shall be rejected with a failure code of assertion.collectionHash.malformed.
It is important that consumers of C2PA manifests be able to understand the information in their native language, when possible. To this end, it is possible to add localization information for an assertion with a dictionary that is included in the assertion’s metadata.
When it is necessary to provide a URL to a web page with information about the ingredient, such as detailed information about an AI/ML model, it should be placed as the value of the informational_URI field of the ingredient assertion.
When it is necessary to provide a URL to a web page with information about the ingredient, such as detailed information about an AI/ML model, it should be placed as the value of the informationalURI field of the ingredient assertion.
| + + | +
+Older (and deprecated) versions of the ingredient assertion named this field informational_URI.
|
If the ingredient has an existing C2PA Manifest Store, then all C2PA Manifests in the ingredient’s C2PA Manifest Store that have undergone validation, and that do not already exist in the asset’s C2PA Manifest Store, shall be copied by the claim generator into the asset’s C2PA Manifest Store, except as outlined in Section 18.13.12, “Determining the need to copy or copy and re-label existing manifests” or when directed not to do so (for example via user input or via configuration).
In addition, when the ingredient assertion references a C2PA Manifest, the claim generator shall also act as a validator, performing validation of the ingredient as described in validation steps. The result of that validation - all success codes, informational codes, and failure codes - shall be used in populating the ingredient assertion’s validationResults or validationStatus field as described below. This field is required to be present so that it can be used in future validations.
In a v2 ingredient assertion with no c2pa_manifest field, the validationStatus field shall contain an empty array.
In a v2 ingredient assertion with no c2pa_manifest field, the validationStatus field is optional, but if present may contain an empty array.
In a v2 ingredient assertion with c2pa_manifest field, each object in the validationStatus array consists of a code field whose value describes the validation status of a specific part of the manifest along with an optional success field whose boolean value indicates whether the code reflects success (true) or failure (false). An optional description of the validation status may be present in the explanation field if there is a need for an additional human readable explanation. In addition, each status-map object has a url field which should contain, in the case of failures, a JUMBF URI reference to the specific element in the manifest about which the status refers. Depending on the code, the url will be to a C2PA Claim, a C2PA Claim Signature or a specific C2PA Assertion. Status codes are defined in Section 15.2.1, “Standard Status Codes”.
All C2PA Manifest Stores shall be embedded using embedded file streams (ISO 32000, 7.11.4). The file specification dictionary shall have an AFRelationship key (ISO 32000, 7.11.3) whose value is C2PA_Manifest. If a C2PA Manifest Store is embedded into an encrypted PDF, the embedded file stream shall use an Identity crypt filter.
'c2pa' Boxes for Large and Fragmented FilesSome files have one or more very large 'mdat' boxes (e.g., large video or image files which may be downloaded and rendered progressively) or large numbers of independent 'mdat' boxes (e.g., fMP4 where each fragment can be downloaded independently).
Because of its longevity and being an openly published specification, many command file formats are really ZIP archives, but with a specific organization of the content files. This includes formats such as EPUB, Office Open XML, Open Document and OpenXPS.
For more information about these, see http://ns.useplus.org/LDF/ldf-XMPSpecification.
+For more information about these, see http://ns.useplus.org/LDF/ldf-XMPSpecification. +:revdate: 2024-09-19 +:version-label!: +:sectnums: +:sectnumlevels: 5 +:chapter-label: +:source-highlighter: rouge
+| Construct | +Type | +v1.3 | +v1.4 | +v2.0 | +v2.1 | +
|---|---|---|---|---|---|
urn:uuid namespace |
+Label |
++ | + | + | DEPRECATED |
+
urn:c2pa namespace |
+Label |
+UNDEFINED |
+UNDEFINED |
+UNDEFINED |
++ |
sigTst timestamp |
+Time-stamp |
++ | + | + | + |
sigTst2 timestamp |
+Time-stamp |
+UNDEFINED |
+UNDEFINED |
+UNDEFINED |
++ |
c2pa.claim |
+Assertion |
++ | + | DEPRECATED |
+DEPRECATED |
+
c2pa.claim.v2 |
+Assertion |
+UNDEFINED |
+UNDEFINED |
++ | + |
c2pa.assertion.metadata |
+Assertion |
++ | + | + | + |
c2pa.asset-ref |
+Assertion |
++ | + | + | + |
c2pa.asset-type |
+Assertion |
++ | + | + | + |
c2pa.action |
+Assertion |
++ | DEPRECATED |
+DEPRECATED |
+DEPRECATED |
+
c2pa.action.v2 |
+Assertion |
+UNDEFINED |
++ | + | + |
c2pa.cloud-data |
+Assertion |
++ | + | + | + |
c2pa.depthmap.GDepth |
+Assertion |
++ | + | + | + |
c2pa.hash.bmff |
+Assertion |
+DEPRECATED |
+DEPRECATED |
+DEPRECATED |
+DEPRECATED |
+
c2pa.hash.bmff.v2 |
+Assertion |
++ | + | + | + |
c2pa.hash.boxes |
+Assertion |
++ | + | + | + |
c2pa.hash.collection.data |
+Assertion |
++ | + | + | + |
c2pa.hash.data |
+Assertion |
++ | + | + | + |
c2pa.ingredient |
+Assertion |
++ | + | DEPRECATED |
+DEPRECATED |
+
c2pa.ingredient.v2 |
+Assertion |
+UNDEFINED |
++ | + | DEPRECATED |
+
c2pa.ingredient.v3 |
+Assertion |
+UNDEFINED |
+UNDEFINED |
+UNDEFINED |
++ |
c2pa.metadata |
+Assertion |
++ | + | + | + |
c2pa.soft-binding |
+Assertion |
++ | + | + | + |
c2pa.thumbnail.claim.* |
+Assertion |
++ | + | + | + |
c2pa.thumbnail.ingredient.* |
+Assertion |
++ | + | + | + |
font.info |
+Assertion |
++ | + | + | + |
stds.iptc |
+Assertion |
++ | + | DEPRECATED |
+DEPRECATED |
+
stds.exif |
+Assertion |
++ | + | DEPRECATED |
+DEPRECATED |
+
role in region-map |
+Field |
++ | + | + | DEPRECATED |
+
To re-label a manifest:
-- If the current URN does not contain a "Claim Generator identifier string", then the claim generator shall append a :.
-- In all cases, the claim generator shall append a : to the URN followed by a monotonically increasing integer, starting with 1, followed by an underscore (_) and then an integer from the list below representing the reason for the re-labeling.
To re-label a manifest:
If the current URN does not contain a "Claim Generator identifier string", then the claim generator shall append a :.
In all cases, the claim generator shall append a : to the URN followed by a monotonically increasing integer, starting with 1, followed by an underscore (_) and then an integer from the list below representing the reason for the re-labeling.
1: Conflict with another C2PA Manifest
For example, if the claim generator has to re-label a C2PA Manifest for the second time due to a conflict, the appended string would be :2_1.
6332746D-0011-0010-8000-00AA00389B71 (c2tm)) to add the time-stamp in a later operation when a TSA can be contacted.
A Time-Stamp Manifest shall contain only a single assertion, which is the c2pa.ingredient.v3 assertion that (a) includes a activeManifest field with a value that is the URI reference to that C2PA Manifest that is being updated and (b) has the value of parentOf for the relationship field.
A Time-Stamp Manifest shall contain only a single assertion, which is the c2pa.ingredient.v3 assertion that (a) includes an activeManifest field with a value that is the URI reference to that C2PA Manifest that is being updated and (b) has the value of parentOf for the relationship field.
If a validator reports that the portions of the asset that are covered by content bindings have not been modified since the active manifest was produced [Validate the Asset’s Content], and its active manifest is either Valid or Trusted, then the asset itself can be considered to be a Valid asset.
A C2PA Manifest is Well-Formed if validation determines that each of the following is true:
The assertions of the manifest meet all the requirements for assertions [Assertion Validation].
Any ingredients present in the manifest meet all the requirements for ingredients[Validate the Ingredients].
+Any ingredients present in the manifest meet all the requirements for ingredients [Validate the Ingredients].
A C2PA Manifest is Valid if validation determines that each of the following is true:
A C2PA Manifest is Trusted if validation determines that each of the following is true:
timeStamp.untrusted
The time-stamp credential is not listed on the validator’s trust lists.
The time-stamp credential is not listed on the validator’s TSA trust lists.
C2PA Claim Signature Box
Manifest Consumers should not display data from manifests which are not Valid. If the Manifest Consumer chooses to display such data, it shall include as part of the display:
+Manifest Consumers should not display data from manifests which are not Valid nor from assets which are not Valid. If the Manifest Consumer chooses to display such data, it shall include as part of the display:
The last C2PA Manifest superbox in the C2PA Manifest Store superbox shall be considered the active manifest, but locating the C2PA Manifest Store may involve looking in a number of possible locations.
The C2PA Manifest Store shall be located by the validator embedded inside the asset at the standard locations for embedding manifests. However, if an asset was retrieved via an HTTP connection, a validator may look for a Link header, as described in the Link Header clause below, to determine if a C2PA Manifest Store is present.
Retrieve the val property from the tstToken, which shall be an RFC3161-compliant TimeStampResp (time-stamp response)
Retrieve the val property from the tstToken, which shall be an RFC3161-compliant TimeStampResp (time-stamp response).
Check the value of the status field PKIStatusInfo, which is the value of the status field of TimeStampResp.
A validator will encounter one of two scenarios:
+A validator will encounter one of the following three scenarios:
Depending on the type of manifest, there are assertions that are either required or forbidden. A validator shall check for required and not-permitted assertions.
Validate that there is exactly one hard binding to content assertion - either a c2pa.hash.data, a c2pa.hash.boxes, a c2pa.hash.collection.data, c2pa.hash.bmff.v2 (deprecated), or a c2pa.hash.bmff.v3 based on the type of asset for which the manifest is destined. If no such assertion is present, the manifest shall be rejected with a failure code of claim.hardBindings.missing. If there is more than one such assertion, the manifest shall be rejected with a failure code of assertion.multipleHardBindings.
Validate that there is exactly one hard binding to content assertion - either a c2pa.hash.data, a c2pa.hash.boxes, a c2pa.hash.collection.data, c2pa.hash.bmff.v2 (deprecated), or a c2pa.hash.bmff.v3. If no such assertion is present, the manifest shall be rejected with a failure code of claim.hardBindings.missing. If there is more than one such assertion, the manifest shall be rejected with a failure code of assertion.multipleHardBindings.
Validate that there are zero or one c2pa.ingredient assertions whose relationship is parentOf. If there is more than one, the manifest shall be rejected with a failure code of manifest.multipleParents.
Each assertion in the created_assertions and gathered_assertions fields of the claim is a hashed_uri structure. For each assertion, the validator shall first determine if the URI reference in the url field is in the list of redacted assertions.
The contents of a cloud data assertion contains the URI references to and hashes of external data, are validated like any other assertion, but those references are not retrieved and validated as part of standard validation. A validator shall first successfully validate a claim before attempting to retrieve the external data referenced. A validator shall not attempt to retrieve external data from a rejected claim. As the retrieval of external data is optional, the inability to retrieve or validate external data shall not cause a claim to become rejected.
If the current manifest is an update manifest, its hard bindings shall be inherited from the parentOf ingredient’s manifest. If that manifest is also an update manifest, the search for a standard manifest shall recurse though the chain of ingredients. If no standard manifest is found, then the manifest shall be rejected with a failure code of manifest.update.wrongParents.
The asset’s content shall be validated using the hard binding in the active manifest if the active manifest is a standard manifest. If the active manifest is an update or time-stamp manifest, the hard binding shall be found in the parentOf ingredient’s manifest, or if that manifest is also an update or time-stamp manifest, by following the chain of parentOf ingredients to the first standard manifest. If no standard manifest is found, or the standard manifest has no hard binding, then the malformed manifest shall be rejected in accordance with Validate the correct assertions for the type of manifest.
Once a standard manifest (and its bindings) has been located, the exclusion range(s) shall be extracted from the c2pa.hash.data assertion.
Validation of a collection data hash assertion (c2pa.hash.collection.data) that has been located in a standard manifest shall be performed by iterating over the array of uris in the collection-data-hash-map. If there is no uris field present, then the manifest shall be rejected with a failure code of assertion.collectionHash.malformed.
It is important that consumers of C2PA manifests be able to understand the information in their native language, when possible. To this end, it is possible to add localization information for an assertion with a dictionary that is included in the assertion’s metadata.
When it is necessary to provide a URL to a web page with information about the ingredient, such as detailed information about an AI/ML model, it should be placed as the value of the informational_URI field of the ingredient assertion.
When it is necessary to provide a URL to a web page with information about the ingredient, such as detailed information about an AI/ML model, it should be placed as the value of the informationalURI field of the ingredient assertion.
| + + | +
+Older (and deprecated) versions of the ingredient assertion named this field informational_URI.
|
If the ingredient has an existing C2PA Manifest Store, then all C2PA Manifests in the ingredient’s C2PA Manifest Store that have undergone validation, and that do not already exist in the asset’s C2PA Manifest Store, shall be copied by the claim generator into the asset’s C2PA Manifest Store, except as outlined in Determining the need to copy or copy and re-label existing manifests or when directed not to do so (for example via user input or via configuration).
In addition, when the ingredient assertion references a C2PA Manifest, the claim generator shall also act as a validator, performing validation of the ingredient as described in validation steps. The result of that validation - all success codes, informational codes, and failure codes - shall be used in populating the ingredient assertion’s validationResults or validationStatus field as described below. This field is required to be present so that it can be used in future validations.
In a v2 ingredient assertion with no c2pa_manifest field, the validationStatus field shall contain an empty array.
In a v2 ingredient assertion with no c2pa_manifest field, the validationStatus field is optional, but if present may contain an empty array.
In a v2 ingredient assertion with c2pa_manifest field, each object in the validationStatus array consists of a code field whose value describes the validation status of a specific part of the manifest along with an optional success field whose boolean value indicates whether the code reflects success (true) or failure (false). An optional description of the validation status may be present in the explanation field if there is a need for an additional human readable explanation. In addition, each status-map object has a url field which should contain, in the case of failures, a JUMBF URI reference to the specific element in the manifest about which the status refers. Depending on the code, the url will be to a C2PA Claim, a C2PA Claim Signature or a specific C2PA Assertion. Status codes are defined in Standard Status Codes.
All C2PA Manifest Stores shall be embedded using embedded file streams (ISO 32000, 7.11.4). The file specification dictionary shall have an AFRelationship key (ISO 32000, 7.11.3) whose value is C2PA_Manifest. If a C2PA Manifest Store is embedded into an encrypted PDF, the embedded file stream shall use an Identity crypt filter.
'c2pa' Boxes for Large and Fragmented FilesSome files have one or more very large 'mdat' boxes (e.g., large video or image files which may be downloaded and rendered progressively) or large numbers of independent 'mdat' boxes (e.g., fMP4 where each fragment can be downloaded independently).
Because of its longevity and being an openly published specification, many command file formats are really ZIP archives, but with a specific organization of the content files. This includes formats such as EPUB, Office Open XML, Open Document and OpenXPS.