Complete table with all fields including TCR4CAP comments.
| ID | Name | Type | File-level | Content-level | Media Integrity | Metadata Integrity | Chain of Custody | URL | Awareness | Tamper Evidence | Binding | AI Attribution | Substantiation | Interoperability |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
flac-features | FLAC Specific Integrity Features | format-specific | embedded-writable | fixed | checksum | none | none | — | STREAMINFO MD5 and per-frame CRCs are defined in RFC 9639 and are present in all conformant FLAC files. These fields are not mapped to CAP vocabularies in any current CAP framework or policy document. | Any modification to the audio bitstream would produce a different MD5 or CRC value during verification, detectable by recomputing against the stored values. Metadata blocks are not covered. | The MD5 is computed over the unencoded audio content at the time of encoding and stored in the same file. No mechanism links the MD5 to an external identity or signing authority. | No fields in the FLAC format specification address AI generation, training, or processing provenance. | No fields in the FLAC format specification link to external policies, transformation histories, or rights statements. | Defined in RFC 9639 (IETF). Implemented by all conformant FLAC encoders and decoders. Verifiable by flac --test, ffmpeg, and any FLAC-capable tool. |
bwf-features | BWF Specific Features (BEXT Chunk) | format-specific | embedded-writable | append | none | none | none | — | BEXT fields are defined in EBU Tech 3285 and are present in all conformant BWF files. Originator, OriginatorReference, OriginationDate/Time, and CodingHistory are recognized provenance fields in broadcast and archival audio workflows. FADGI and EBU publish guidelines for consistent field use. | BEXT fields have no integrity protection. Any field can be overwritten without detection. CodingHistory is appended by convention; no mechanism enforces append-only behavior or detects deletion of history entries. | BEXT is embedded in the RIFF container alongside the audio data. No cryptographic mechanism links BEXT field values to the audio bitstream. | No fields in the BEXT specification address AI generation, training, or processing provenance. CodingHistory is a free-text field that could carry AI processing notes by convention. | CodingHistory documents processing steps in a structured free-text format. UMID provides a globally unique material identifier. No mechanism links BEXT fields to external policies or trust anchors. | Defined in EBU Tech 3285. Implemented across broadcast and archival audio tools. FADGI and EBU publish open guidelines for field use. |
jpeg-features | JPEG Specific Features (APP Segments) | format-specific | embedded-writable | overwrite | none | none | signed | — | APP segment structure is defined in ISO/IEC 10918. APP11 C2PA embedding is defined in the C2PA Technical Specification Appendix A. APP1 EXIF, XMP, and APP13 IPTC-IIM are widely implemented across image tools. | APP segments can be added, removed, or replaced without detection in the base format. C2PA APP11 provides cryptographic tamper-evidence when present; any modification to the signed content invalidates the manifest signature. | C2PA APP11 provides hard binding: the manifest contains a hash of the image content, cryptographically linking the manifest to the specific image bitstream at signing time. EXIF and XMP are structurally embedded but not cryptographically bound. | C2PA AI attribution assertions (c2pa.ai.generatedWith, training data references) are carried in APP11 when present. IPTC 2025.1 AI fields are carried in XMP via APP1. | C2PA manifest store in APP11 preserves transformation history with external trust anchor support. XMP xmpMM:History and IPTC fields provide additional descriptive provenance. | JPEG/JFIF is defined in ISO/IEC 10918 and widely implemented. APP11 C2PA is supported by c2patool and c2pa-rs reference implementations. |
png-features | PNG Specific Features (Chunks) | format-specific | embedded-writable | overwrite | checksum | checksum | signed | — | PNG chunk structure is defined in ISO/IEC 15948. caBX C2PA embedding is defined in the C2PA Technical Specification. Per-chunk CRC-32 is implemented by all conformant PNG encoders and decoders. | Per-chunk CRC-32 detects accidental corruption of any chunk. C2PA caBX provides cryptographic tamper-evidence when present. CRC-32 does not detect intentional replacement of a chunk with a recalculated CRC. | C2PA caBX provides hard binding: the manifest contains a hash of the image content. Per-chunk CRC-32 binds each chunk's integrity check to its content but is not a cryptographic signature. | C2PA AI attribution assertions are carried in caBX when present. IPTC 2025.1 AI fields are carried in XMP via iTXt. | C2PA manifest store in caBX preserves transformation history. XMP in iTXt provides additional descriptive provenance. | PNG is defined in ISO/IEC 15948 and widely implemented. caBX C2PA is supported by c2patool and c2pa-rs reference implementations. |
tiff-features | TIFF Specific Features (IFD Tags) | format-specific | embedded-writable | overwrite | none | none | none | — | TIFF IFD tag structure is defined in TIFF 6.0. Tag 700 XMP and tag 33723 IPTC are widely implemented in archival imaging tools. No C2PA embedding path exists in the current specification. | IFD tags have no integrity protection and can be silently overwritten or stripped without detection. | Metadata tags are structurally embedded in the IFD alongside the image data but there is no cryptographic binding between tag values and the image bitstream. | IPTC 2025.1 AI fields can be carried via XMP in tag 700. No purpose-built AI attribution fields exist in the TIFF 6.0 specification. | Tag 700 XMP and tag 33723 IPTC provide descriptive provenance fields. No mechanism links IFD tags to external policies or trust anchors. | TIFF 6.0 is an open specification widely implemented across archival imaging tools and repository systems. |
mp4-features | MP4 / ISOBMFF Specific Features (Atoms) | format-specific | embedded-writable | overwrite | none | none | signed | — | ISOBMFF atom structure is defined in ISO 14496-12. C2PA uuid atom embedding is defined in the C2PA Technical Specification Appendix A. uuid atom XMP embedding is defined in the XMP specification. | Metadata atoms have no integrity protection in the base specification. C2PA uuid atom provides cryptographic tamper-evidence when present; modification of the media data invalidates the C2PA hard binding. | C2PA uuid atom provides hard binding: the manifest contains a hash of the media content. udta and moov metadata atoms are structurally embedded but not cryptographically bound. | C2PA AI attribution assertions are carried in the uuid atom when present. | C2PA manifest store in uuid atom preserves transformation history with external trust anchor support. | ISO 14496-12 is an ISO standard. MP4 is widely implemented across broadcast, streaming, and archival video tools. C2PA uuid atom is supported by c2patool and c2pa-rs. |
mkv-features | Matroska Specific Features (EBML Tags, CRC-32, and Attachments) | format-specific | embedded-writable | overwrite | checksum | checksum | none | — | Matroska tag structure and CRC-32 behavior are defined in IETF RFC 9559 and RFC 8794. Tag elements are implemented in mkvtoolnix, FFmpeg, and VLC. No CAP-specific tag vocabulary is defined in the Matroska specification. The ORIGINAL, SAMPLE, and DATE_* tags provide a richer provenance vocabulary than most container formats but are not mapped to any current CAP framework. | CRC-32 elements on each top-level EBML element detect accidental corruption of that element's data. They do not prevent intentional modification; any writer can recompute a valid CRC-32 after altering content. EBML tag elements have no cryptographic integrity protection. | Tag elements are structurally embedded in the EBML container. CRC-32 binds element content to its checksum at write time but there is no cryptographic binding between tag values and the media data, and no external identity is involved. | No AI attribution fields are defined in the Matroska tag vocabulary. | The ORIGINAL, ORIGINAL_MEDIA_TYPE, SAMPLE, ENCODER, ENCODER_SETTINGS, and DATE_* tags provide a structured record of encoding history and source material. LICENSE and TERMS_OF_USE fields support rights documentation. No mechanism links these values to external policies or trust anchors. | Matroska is defined in IETF RFC 9559. Tag vocabulary is defined in the IETF CELLAR tags draft. Widely implemented in FFmpeg, VLC, and mkvtoolnix. CRC-32 verification is supported by mkvinfo and ffprobe. |
vorbis-comment | Vorbis Comment | embedded-metadata | embedded-writable | overwrite | none | none | none | — | Vorbis Comment fields are widely understood in audio workflows but there is no standardized mapping to CAP vocabularies. | Vorbis Comment fields have no integrity protection and can be silently overwritten or stripped without detection. | Fields are structurally embedded in the file but there is no cryptographic binding between comment values and the audio content. | No defined AI attribution fields; any AI documentation must repurpose general comment fields with no standardized vocabulary. | Values are readable but there is no mechanism for linking to external policies or transformation histories. | Vorbis Comment is an open, widely implemented specification; fields are plain text and broadly readable. |
id3-geob-c2pa | ID3 General Encapsulated Object (GEOB) — C2PA | embedded-c2pa | embedded-writable | append-only | signed | signed | signed | — | C2PA is a defined, published standard; the GEOB embedding path is specified in the C2PA Technical Specification, though not yet widely implemented in FLAC-specific tooling. | Individual manifests are cryptographically signed and immutable; the append-only store preserves the full provenance chain. Tampering with the GEOB payload invalidates the signature. | C2PA hard binding links the manifest cryptographically to the audio content; the GEOB frame provides a standardized embedding location within the ID3 structure. | C2PA supports structured AI attribution assertions (c2pa.ai.generatedWith, training data, model identity) within the manifest. | C2PA manifests can reference external trust anchors and credential issuers; transformation history is preserved in the manifest store across the asset lifecycle. | C2PA is an open, published specification; GEOB is a standard ID3 frame; implementation breadth in FLAC tooling is currently limited. |
bwf-bext | BWF BEXT Chunk | embedded-metadata | embedded-writable | append | none | none | none | guidelines: https://www.digitizationguidelines.gov/guidelines/digitize-embedding.html | BEXT is defined in EBU Tech 3285. Originator, OriginatorReference, OriginationDate/Time, and CodingHistory are recognized provenance fields in broadcast and archival audio workflows. FADGI and EBU publish guidelines for consistent field use. | BEXT fields have no integrity protection. Any field can be overwritten without detection. CodingHistory is appended by convention; no mechanism enforces append-only behavior or detects deletion of history entries. | BEXT is embedded in the RIFF container alongside the audio data. No cryptographic mechanism links BEXT field values to the audio bitstream. | No fields in the BEXT specification address AI generation, training, or processing provenance. CodingHistory is a free-text field that could carry AI processing notes by convention. | CodingHistory documents processing steps in a structured free-text format. UMID provides a globally unique material identifier. No mechanism links BEXT fields to external policies or trust anchors. | Defined in EBU Tech 3285. Implemented across broadcast and archival audio tools. FADGI and EBU publish open guidelines for field use. |
bwf-info | BWF LIST-INFO Chunk | embedded-metadata | embedded-writable | overwrite | none | none | none | guidelines: https://www.digitizationguidelines.gov/guidelines/digitize-embedding.html | INFO tags are widely understood as descriptive metadata but are not specifically designed for provenance; no standardized mapping to CAP vocabularies. | LIST-INFO fields have no integrity protection and can be silently overwritten or stripped without detection. | Fields are structurally embedded in the file but there is no cryptographic binding between INFO field values and the audio content. | No defined AI attribution fields; general comment fields could be repurposed but with no standardized vocabulary. | Plain text fields with no mechanism for linking to external policies or transformation histories. | RIFF INFO is an open, widely implemented specification; fields are plain text and broadly readable across tools. |
bwf-xml | BWF XML Chunks (aXML / iXML) | embedded-metadata | embedded-writable | overwrite | none | none | none | guidelines: https://www.digitizationguidelines.gov/guidelines/digitize-embedding.html | iXML and aXML/EBU-ISRC are well-established in broadcast production workflows but are not yet addressed in FADGI preservation guidelines. | aXML and iXML fields have no integrity protection and can be silently overwritten or stripped without detection. | Chunks are structurally embedded in the file but there is no cryptographic binding between chunk content and the audio bitstream. | No defined AI attribution fields in iXML or aXML vocabularies. | iXML provides structured production context (scene, take, recorder); aXML/EBU-ISRC supports rights and identifier linkage. No mechanism for linking to external trust anchors. | iXML is an open specification; aXML/EBU-ISRC is an EBU standard. Both are broadly supported in professional audio and DAW tooling. |
bwf-md5 | BWF Audio-Data MD5 Checksum | integrity | embedded-writable | fixed | checksum | none | none | guidelines: https://www.digitizationguidelines.gov/guidelines/digitize-embedding.html | Audio-data MD5 is a well-understood fixity practice in broadcast and preservation workflows; BWF MetaEdit's implementation follows FADGI guidance. | Detects accidental or unintentional changes to the audio bitstream. Does not cover metadata chunks. MD5 is not collision-resistant for adversarial tampering; the checksum value itself is not signed. | The MD5 is computed over and embedded alongside the specific audio data chunk, providing a direct integrity link between the checksum value and the audio content within the same file. | No relevance to AI attribution; the checksum documents data integrity only. | Provides a verifiable, reproducible integrity record for the audio bitstream. Supported by FADGI guidance. Exportable for external audit. Limited to the data chunk. | MD5 is a universal algorithm; the checksum can be verified by any MD5 tool. The embedding convention is specific to BWF MetaEdit / FADGI practice and not universally standardized across all WAVE-capable tools. |
bwf-c2pa | BWF C2PA Chunk | embedded-c2pa | embedded-writable | append-only | signed | signed | signed | — | C2PA Technical Specification is published by the Coalition for Content Provenance and Authenticity. The C2PA RIFF chunk is defined in the specification Appendix A. No current version of BWF MetaEdit writes this chunk. | The manifest is cryptographically signed; any modification to the signed content invalidates the signature. Hard binding means any modification to the audio data is detectable. | Hard binding: the C2PA Manifest Store is embedded in the file and the Claim covers a hash of the audio data chunk, cryptographically linking the manifest to the specific audio bitstream at signing time. | C2PA defines standardized assertions for AI generative and training provenance: c2pa.ai.generatedWith, c2pa.training-mining, and related fields for model identity and generation parameters. | Signed assertions are verifiable against a public certificate chain and optional timestamp authority. Manifest history preserves a chain of custody across multiple signing events. | C2PA is an open, published specification. Tooling support for WAV/BWF is nascent; c2patool and c2pa-rs support it but broadcast and preservation tools do not yet recognize the chunk. |
xmp-embedded | XMP Embedded Metadata | embedded-metadata | embedded-writable | overwrite | none | none | none | — | XMP is defined in ISO 16684. Implemented across creative, archival, and repository tools. xmpMM:History and xmpMM:DerivedFrom are recognized provenance fields in digital asset management workflows. | XMP packets have no integrity protection and can be silently overwritten or stripped without detection. xmpMM:History entries are advisory and unverified. | XMP is structurally embedded in host files but there is no cryptographic binding between XMP content and the primary media data. The packet can be removed without affecting the media bitstream. | Iptc4xmpExt:DigitalSourceType and IPTC 2025.1 AI fields (AiPrompt, AiSystemUsed, AiSystemVersion) are carried in XMP namespaces. No purpose-built AI attribution fields exist in the core XMP specification itself. | xmpMM:History and xmpMM:DerivedFrom provide a readable provenance record. XMP sidecar files can be published independently. No mechanism for cryptographic verification of history entries. | XMP is defined in ISO 16684. Implemented across all major creative, archival, and repository tools. Embedded in a wide range of format containers. |
exif-embedded | EXIF Embedded Metadata | embedded-metadata | embedded-writable | overwrite | none | none | none | — | EXIF is defined by CIPA DC-008. Implemented universally across cameras, phones, and image processing tools. Capture device identity and datetime fields are widely used as provenance indicators in photojournalism and archival workflows. | EXIF data has no integrity protection and can be silently overwritten or stripped without detection. | EXIF is structurally embedded in host files but there is no cryptographic binding between EXIF tag values and the image content. | No AI attribution fields are defined in the EXIF specification. Software (0x0131) can record processing tool identity but has no structured AI attribution vocabulary. | Capture datetime, GPS, and device fields provide a factual provenance record. No mechanism links EXIF fields to external policies or transformation histories. | EXIF is defined by CIPA DC-008. Universally implemented across cameras, phones, and image processing tools. |
iptc-photo | IPTC Photo Metadata | embedded-metadata | embedded-writable | overwrite | none | none | none | — | IPTC Photo Metadata Standard is published by IPTC. Version 2025.1 AI fields are defined in the IPTC specification. Widely implemented in photo editing, DAM, and publishing tools. | IPTC fields carried in XMP have no integrity protection and can be silently overwritten or stripped without detection. | IPTC fields are structurally embedded via XMP in host files but there is no cryptographic binding between field values and the image content. | Version 2025.1 defines AiPrompt, AiSystemUsed, AiSystemVersion, and DataMiningPermission as purpose-built, standardized AI attribution fields within the IPTC vocabulary. | IPTC fields provide a structured, readable provenance record. The standard is publicly documented. No mechanism links field values to external trust anchors. | IPTC Photo Metadata Standard is an open standard. Implemented in photo editing, DAM, and publishing tools including Adobe Photoshop, Lightroom, and Capture One. |
jumbf-c2pa | JUMBF C2PA Manifest Store (Embedded) | embedded-c2pa | embedded-writable | append-only | signed | signed | signed | — | C2PA Technical Specification is published by the Coalition for Content Provenance and Authenticity. Adopted by Adobe, Microsoft, Google, camera manufacturers, and news organizations. Reference implementation available as c2pa-rs under an open-source license. | Each manifest is cryptographically signed; any modification invalidates the signature. The append-only store preserves the full provenance chain. Hard binding means any modification to the asset content invalidates the active manifest. | Hard binding provides cryptographic linkage between manifest and asset content via content hash. Soft binding provides a defined alternative for non-embeddable assets using perceptual identifiers. | C2PA defines purpose-built assertions for AI generative and training provenance: c2pa.ai.generatedWith, c2pa.training-mining, and related fields for model identity and generation parameters. | Manifest store preserves full transformation history. External trust anchors (credential issuers, TSA) are supported. Public verification is possible via the C2PA trust list and open verification tools. | Open published specification. Reference implementation (c2patool, c2pa-rs) available under open-source license. Adopted across image, video, and audio tools and camera manufacturers. Format-specific embedding paths are defined in the C2PA Technical Specification Appendix A. |
sidecar-c2pa | C2PA Sidecar Manifest | sidecar-c2pa | sidecar-writable | append-only | signed | signed | signed | — | C2PA sidecar delivery is defined in the C2PA Technical Specification. Used for formats where embedding is not defined or not practical. | Each manifest is cryptographically signed; modification of the sidecar payload invalidates the signature. The sidecar can be deleted or separated from the asset without detection at the file level. | Hard binding via content hash links the sidecar to the specific asset bitstream. Physical co-location of sidecar and asset depends on file management conventions and is not enforced by the format. | C2PA AI attribution assertions are carried in the sidecar manifest store identically to the embedded path. | Manifest store preserves full transformation history. External trust anchors are supported. Sidecar files can be published or transferred independently of the asset. | C2PA sidecar is defined in the open C2PA Technical Specification. Supported by c2patool and c2pa-rs. Sidecar association conventions vary across repository and DAM systems. |
sidecar-premis | PREMIS Sidecar / Embedded Event Record | sidecar-metadata | sidecar-writable | append | external-only | none | external-only | — | PREMIS Data Dictionary is published by the Library of Congress. Implemented in Archivematica, DSpace, Fedora, and other repository systems. Event types and agent types are defined vocabularies. | PREMIS XML has no integrity protection. The document can be modified without detection. Tamper-evidence depends on the repository or packaging layer (e.g. BagIt fixity, audit logs). | PREMIS Object elements reference described files by identifier and path. Fixity values in objectCharacteristics/fixity link the PREMIS record to a specific file state, but the linkage is not cryptographically enforced within the PREMIS document itself. | No purpose-built AI attribution fields in the PREMIS Data Dictionary. The agent/agentType vocabulary could accommodate AI agents; eventType could accommodate AI processing events by convention. | PREMIS event records provide a structured, policy-driven transformation history. The PREMIS Data Dictionary is an open standard. Event records are auditable by repository administrators. | PREMIS Data Dictionary is published by the Library of Congress as an open standard. Implemented across major digital preservation systems and repository platforms. |
bagit-features | BagIt Package Fixity | package-integrity | package-writable | fixed | checksum | checksum | external-only | — | BagIt is defined in IETF RFC 8493. Widely adopted in digital preservation, library, and archival transfer workflows. Implemented in bagit-python, Bagger, and Archivematica. | Manifest checksums detect modification of any payload or tag file. No signing mechanism; the manifest files themselves could be replaced along with modified payload files without detection at the BagIt level. | Manifest entries bind each checksum to a specific file path within the bag. No cryptographic binding between the bag as a whole and an external identity or signing authority. | No AI attribution fields in the BagIt specification. bag-info.txt custom fields could carry AI processing notes by convention. | Manifest files provide a verifiable, reproducible integrity record for all payload and tag files. bag-info.txt carries descriptive provenance fields. No mechanism for linking to external trust anchors. | BagIt is defined in IETF RFC 8493. Implemented across digital preservation, library, and archival transfer tools and systems. |