content-provenance — jeder Inhalt mit eigener Signatur.

Architektur

Classes/
├── Domain/          # Signatur-Modelle, Key-Value-Objects, Contracts
├── Application/     # Signing-Services, Verifizierungs-Orchestrierung
├── Infrastructure/  # Key-Provider, Repositories, API-Middleware
└── Presentation/    # Controller, Event-Listener

API-Endpoints

Datenbank-Tabellen

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

Mit v0.6.0 deckt das Package den regulatorischen Kern von EU AI Act Artikel 50 ab: maschinen-lesbare Kennzeichnung KI-generierter Bilder, Auto-Detection beim Upload und IPTC-XMP-Write-Back ins File.

Drei Bausteine

• TCA-Asset-Origin-Tagging — neuer „AI Provenance"-Tab auf sys_file_metadata, sys_file_reference und pages mit den Feldern Origin (Human/AiGenerated/AiAssisted), AI-System, AI-Prompt und C2PA-Status.
• Auto-Detection beim Upload — AfterFileAddedEvent-Listener liest C2PA-Manifests (via c2patool) und IPTC-XMP-Tags (via exiftool) und seedet die TCA-Felder automatisch. ChatGPT/DALL-E/Adobe-Firefly-Bilder werden ohne Editor-Eingriff korrekt klassifiziert.
• IPTC-XMP-Write-Back — beim Save eines AI-tagged Files schreibt der EmbedAiMetadataOnFileSave-Listener Iptc4xmpExt:DigitalSourceType, AISystemUsed und AIPromptInformation zurück ins File. Maschinen-lesbare Disclosure, erfüllt Art. 50.

Erweiterte TCA-Spalten (v0.6.0+)

Container-Binaries (optional)

Für Auto-Detection und IPTC-Write müssen exiftool (Lesen/Schreiben aller Image/Video/Audio-Formate) und c2patool (Lesen/Schreiben von C2PA-Manifests; Releases bei contentauth/c2pa-rs) im httpd-Container vorhanden sein. Ohne die Binaries läuft die Extension weiter, nur Auto-Detection und IPTC-Write werden zu No-Ops mit Log-Warning. Defensive Binary-Handling-Logik im Listener fängt das ab — der Editor-Manual-Tag bleibt jederzeit Fallback.

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

Positionierung: Diese Schicht ist kein regulatorisches Muss für EU AI Act Artikel 50 — die maschinen-lesbare Disclosure (IPTC-XMP plus Schema.org) und das sichtbare FE-Badge aus Phase 1–4 deckt den regulatorischen Kern bereits ab. C2PA-Signing ist die Enterprise-Authenticity-Schicht: Beweisbarkeit, Anti-Stripping, Chain-of-Custody, Forensik und Interoperabilität.

Ab v0.7.0 enthält das Package eine kryptografische C2PA-Sign-Pipeline:

• C2paCertificateProvider — resolved Cert und Key aus /run/c2pa/ (vom cert-manager beschickt, 90 Tage Lifetime, quartalsweise Leaf-Rotation).
• C2paManifestSigner — Subprocess-Wrapper um c2patool. Auto-detected c2pa.created (fresh) vs. c2pa.metadata mit parent_ingredient (append) — Upstream-Signaturen (OpenAI, Adobe) bleiben in der Chain.
• ReSignDerivativeFiles-Listener auf AfterFileProcessingEvent — signiert auch TYPO3-generierte Thumbnails und Resizes, sodass die Provenance-Chain die FAL-Image-Processing-Pipeline überlebt.
• provenance:resign-CLI für opt-in Backfill bestehender AI-tagged Files (idempotent, --force für Re-Sign).

c2pa_status-Statusmodell

Trust-Model

Die Signatur-Pipeline etabliert eine Private Provenance Chain: Signatur-Cert kommt von der projekteigenen Step-CA (self-anchored), Tamper-Evidenz über Hash-Anchored Manifest, Append-Mode preserved Upstream-Trust-Chain (OpenAI/Adobe bleiben sichtbar), Strip-Detection über c2pa_status=stripped liefert ein starkes Forensik-Signal im BE. Externe Validatoren wie contentcredentials.org/verify zeigen unsere Signatur als „untrusted (unknown CA)" — die Signatur ist kryptografisch valid und tamper-evident, aber unsere Root steht nicht in der C2PA-Trust-List. Das ist gewollt für Phase 1: interne Beweisbarkeit und Forensik ohne externes Onboarding-Programm.

Konfiguration & Voraussetzungen

Key-Provider und Signing-Policies konfigurieren Sie über die TYPO3 Site Settings. Mehrere Key-Provider für unterschiedliche Umgebungen (Development, Staging, Production) sind unterstützt — Backend austauschbar (Datei, Environment, Vault).

Voraussetzungen

• PHP 8.3+
• TYPO3 14.0
• ext-sodium (zwingend — für Ed25519-Operationen)

Optionale Abhängigkeiten

EU-AI-Act-Art.-50-Compliance und Google AI Search

Das regulatorische Minimum für Art. 50 (gültig ab August 2026) ist „maschinen-lesbar gekennzeichnet UND als künstlich erzeugt erkennbar". Das wird durch die Phasen 1–4 dieses Packages und der Site-Packages abgedeckt:

Art. 50 fordert nach aktuellem Stand nicht kryptografische Provenance, keine PKI, keine Trust-List-CA, keine Watermarks, keine Blockchain. Die C2PA-Sign-Schicht (Phase 5) ist eine strategische Ergänzung für Beweisbarkeit, Forensik und Enterprise-Authenticity-Use-Cases, nicht eine regulatorische Pflicht-Schicht.

Google AI Search Konformität (Mai 2026)

Googles offizielle Guides bestätigen den Stack-Ansatz: der AI Optimization Guide sagt explizit, dass keine neuen maschinen-lesbaren Files, AI Text Files, Markup oder Markdown nötig sind, um in Generative AI Search aufzutauchen, und dass Structured Data dafür nicht erforderlich ist. Der einzige harte technische Pflicht-Punkt von Google für AI-Bilder ist IPTC DigitalSourceType TrainedAlgorithmicMedia — abgedeckt durch Phase 3 (IptcXmpWriter). Schema.org-Erweiterungen (Phase 4) bleiben für klassische SERP-Features sinnvoll, sind aber für Generative AI Search nicht erforderlich. C2PA-Signing (Phase 5) wird von Google aktuell nicht für Search-Ranking ausgewertet — bleibt strategisch als Enterprise-Authenticity-Layer.

Hinweis: Diese Doku ist keine juristische Beratung. Für die formelle Art.-50-Bewertung empfehlen wir eine eigene Risikoanalyse und ein Disclosure-Konzept, das die im Projekt umgesetzten Layer benennt und die Strip-Detection-Strategie (c2pa_status=stripped) dokumentiert.

Setzen wir ein bei …

Dieses Paket ist die Provenance-Schicht für AI-Ready CMS, AI-Ready Commerce und Open Source & Digitale Souveränität. In der betreuten Variante: AI-Ready CMS as a Service.