content-provenance — every piece of content with its own signature.

Architecture

Classes/
├── Domain/          # Signature models, key value objects, contracts
├── Application/     # Signing services, verification orchestration
├── Infrastructure/  # Key providers, repositories, API middleware
└── Presentation/    # Controllers, event listeners

API endpoints

Database tables

AI Asset Provenance (EU AI Act Art. 50, since v0.6.0)

From v0.6.0 the package covers the regulatory core of EU AI Act Article 50: machine-readable labelling of AI-generated images, auto-detection on upload and IPTC XMP write-back into the file.

Three building blocks

• TCA asset-origin tagging — a new “AI Provenance” tab on sys_file_metadata, sys_file_reference and pages with fields for origin (Human / AiGenerated / AiAssisted), AI system, AI prompt and C2PA status.
• Auto-detection on upload — the AfterFileAddedEvent listener reads C2PA manifests (via c2patool) and IPTC XMP tags (via exiftool) and seeds the TCA fields automatically. ChatGPT, DALL-E and Adobe Firefly images are classified correctly without editor intervention.
• IPTC XMP write-back — when an AI-tagged file is saved, the EmbedAiMetadataOnFileSave listener writes Iptc4xmpExt:DigitalSourceType, AISystemUsed and AIPromptInformation back into the file. Machine-readable disclosure, satisfies Art. 50.

Extended TCA columns (v0.6.0+)

Container binaries (optional)

For auto-detection and IPTC write to work, exiftool (read/write IPTC XMP tags across all image, video and audio formats) and c2patool (read/write C2PA manifests; releases at contentauth/c2pa-rs) must be present inside the httpd container. Without those binaries, the extension keeps running — only the auto-detection and IPTC write steps become no-ops with a log warning. Defensive binary handling in the listener catches that case; the editor’s manual tag remains a fallback at any time.

C2PA Manifest Signing (Enterprise Provenance Layer, since v0.7.0)

Positioning: This layer is not a regulatory must for EU AI Act Article 50 — the machine-readable disclosure (IPTC XMP plus Schema.org) and the visible FE badge from phases 1–4 already cover the regulatory core. C2PA signing is the enterprise authenticity layer: provability, anti-stripping, chain of custody, forensics and interoperability.

From v0.7.0 the package contains a cryptographic C2PA sign pipeline:

• C2paCertificateProvider — resolves cert and key from /run/c2pa/ (delivered by cert-manager, 90-day lifetime, quarterly leaf rotation).
• C2paManifestSigner — subprocess wrapper around c2patool. Auto-detects c2pa.created (fresh) vs. c2pa.metadata with parent_ingredient (append) — upstream signatures (OpenAI, Adobe) stay in the chain.
• ReSignDerivativeFiles listener on AfterFileProcessingEvent — also signs TYPO3-generated thumbnails and resizes so the provenance chain survives the FAL image processing pipeline.
• provenance:resign CLI for opt-in backfill of existing AI-tagged files (idempotent, --force for re-sign).

c2pa_status state model

Trust model

The signing pipeline establishes a private provenance chain: the signing cert comes from the project-owned Step-CA (self-anchored), tamper evidence via hash-anchored manifest, append mode preserves the upstream trust chain (OpenAI/Adobe remain visible), strip detection via c2pa_status=stripped provides a strong forensic signal in the BE. External validators like contentcredentials.org/verify show our signature as “untrusted (unknown CA)” — the signature is cryptographically valid and tamper-evident, but our root is not in the C2PA trust list. This is intentional for phase 1: internal provability and forensics without an external onboarding programme.

Configuration and requirements

Configure key providers and signing policies through TYPO3 site settings. Multiple key providers for different environments (development, staging, production) are supported — the backend is pluggable (file, environment, vault).

Requirements

• PHP 8.3+
• TYPO3 14.0
• ext-sodium (mandatory — for Ed25519 operations)

Optional dependencies

EU AI Act Art. 50 compliance and Google AI Search

The regulatory minimum for Art. 50 (in force from August 2026) is “machine-readable labelled AND recognisable as artificially generated”. That is covered by phases 1–4 of this package and the site packages:

Art. 50 currently does not require cryptographic provenance, PKI, trust-list CAs, watermarks or blockchain. The C2PA signing layer (phase 5) is a strategic complement for provability, forensics and enterprise authenticity use cases — not a regulatory must.

Google AI Search conformance (May 2026)

Google’s official guides confirm the stack approach: the AI Optimization Guide states explicitly that no new machine-readable files, AI text files, markup or Markdown are needed to appear in generative AI search, and that structured data is not required. The only hard technical mandatory point Google sets for AI images is IPTC DigitalSourceType TrainedAlgorithmicMedia — covered by phase 3 (IptcXmpWriter). Schema.org extensions (phase 4) stay useful for classic SERP features but are not required for generative AI search. C2PA signing (phase 5) is currently not evaluated by Google for search ranking — it remains strategic as an enterprise authenticity layer.

Note: This documentation is not legal advice. For the formal Art. 50 assessment we recommend an independent risk analysis and a disclosure concept that names the layers implemented in the project and documents the strip-detection strategy (c2pa_status=stripped).

Where we use this …

This package is the provenance layer for AI-Ready CMS, AI-Ready Commerce and Open Source & Digital Sovereignty. Managed variant: AI-Ready CMS as a Service.