Ich hätte gerne alle meine Rechnungen, die ich von Internetversandhändler bekomme auch alle in einer standardisierten maschinenverarbeitbarer Form.
Was ZUGFeRD betrifft. Wenn ich mich nicht irre, dann sind die Daten in einer ZUGFeRD PDF Datei zweifach vorhanden. Einmal als eingebettetes XML und einmal als PDF Konstrukt. D.h. die Daten für die für Menschen gut lesbare PDF Rechnung wird nicht aus den XML Daten rekonstruiert. Was ich schlecht finde, da die Daten so verschieden sein könnten.
Von Jochen Stärk am Fr, 14. Dezember 2018 um 11:05 #
> Was ich schlecht finde, da die Daten so verschieden sein könnten.
technisch richtig, der Standard verbietet zwar abweichende Daten aber das lässt sich nur schwer automatisiert prüfen, etwa durch eine OCR und Vergleich mit den Metadaten.
Bei ZUGFeRD 1 gibt es eine XSL-Transformation um eine "menschenlesbare" Version zum Prüfen zu erzeugen. PDF-A aus XML erzeugen geht ja bspw. über XML:FO und Apache FOP, das ist aber vergleichsweise kompliziert und PDF/A selbst bietet keine "eingebaute" Möglichkeit ein PDF-Dokument anhand XML aufzubauen oder sonstwie , deswegen geht das wohl nicht anders
und wie soll diesem Angriffsvektor dann entgegen gewirkt werden? Szenario: ich bekomme eine Rechnung von einem Händler über 10 Euro, aber die xml Rechnung verbucht 100? Klingt nach dieser Thunderbird Sache neulich, wo die Verschlüsselung nur "optisch" eingeschaltet war...
Ich hätte gerne alle meine Rechnungen, die ich von Internetversandhändler bekomme auch alle in einer standardisierten maschinenverarbeitbarer Form.
Was ZUGFeRD betrifft.
Wenn ich mich nicht irre, dann sind die Daten in einer ZUGFeRD PDF Datei zweifach vorhanden. Einmal als eingebettetes XML und einmal als PDF Konstrukt.
D.h. die Daten für die für Menschen gut lesbare PDF Rechnung wird nicht aus den XML Daten rekonstruiert. Was ich schlecht finde, da die Daten so verschieden sein könnten.
> Was ich schlecht finde, da die Daten so verschieden sein könnten.
technisch richtig, der Standard verbietet zwar abweichende Daten aber das lässt sich nur schwer automatisiert prüfen, etwa durch eine OCR und Vergleich mit den Metadaten.
Bei ZUGFeRD 1 gibt es eine XSL-Transformation um eine "menschenlesbare" Version zum Prüfen zu erzeugen. PDF-A aus XML erzeugen geht ja bspw. über XML:FO und Apache FOP, das ist aber vergleichsweise kompliziert und PDF/A selbst bietet keine "eingebaute" Möglichkeit ein PDF-Dokument anhand XML aufzubauen oder sonstwie , deswegen geht das wohl nicht anders
und wie soll diesem Angriffsvektor dann entgegen gewirkt werden? Szenario: ich bekomme eine Rechnung von einem Händler über 10 Euro, aber die xml Rechnung verbucht 100? Klingt nach dieser Thunderbird Sache neulich, wo die Verschlüsselung nur "optisch" eingeschaltet war...