Signaturprüfung mit MOA-SP

  • Hier eine Infos für alle, die daran denken, eine signierte Rechnung mit MOA-SP zu prüfen:

    (Der Originaltext wurde an die moa-developermailinglist gepostet):

    Beim Signaturprüfen mit MOA-SP einer signierten Rechnung nach ebInvoice-Standard (http://www.ebinterface.at/) tritt folgendes Phänomen auf:

    Das signierte Dokument http://test.baumann.at/ebInterface_MO…e_CB_signed.xml wird an MOA-SP (1.3.0) übergeben (per SOAP-Call)

    MOA-SP meldet, dass die Signatur nicht korrekt ist, siehe http://test.baumann.at/ebInterface_MOASP/MOASP_Response.xml
    .

    Das Logfile sagt:
    WARN | 13 05:27:49,831 | moa.spss.server | http-5028-Processor22 | TID=1148024210308-292 NID=<null> MSG=Fehler beim Parsen: cvc-complex-type.3.2.2: Attribute 'ConsolidatorPayable' is not allowed to appear in element 'eb:PaymentMethod'., SystemID=null, Zeile=158, Spalte=94
    INFO | 13 05:27:49,831 | moa.spss.server | http-5028-Processor22 | TID=1148024210308-292 NID=<null> MSG=Das Signature Environment konnte nicht validierend geparst werden

    Wenn man den Base64-Content ansieht, http://test.baumann.at/ebInterface_MO…_from_MOASP.xml erkennt man, dass (von MOA-SP) ein Attribut (ConsolidatorPayable) bei ein Tag hinzugefügt wurde:

    <eb:PaymentMethod ConsolidatorPayable="false" xsi:type="eb:UniversalBankTransactionType">
    Original war:
    <eb:PaymentMethod xsi:type="eb:UniversalBankTransactionType">

    Und tatsächlich ist es so, dass lt. Schema http://www.ebinterface.at/schema/2p0/Invoice.xsd das retournierte Dokument nun invalid ist.

    --- Nachtrag ---

    Das Problem besteht aus zwei Teilen:

    1) Ergänzt MOA-SP beim Validieren des signierten Dokumentes das Attribut "ConsolidatorPayable":

    <eb:PaymentMethod ConsolidatorPayable="false" xsi:type="eb:UniversalBankTransactionType">

    -> das erscheint mit nicht ganz logisch, denn das Attribut ist im Schema nicht als "use=required" angegeben ... ???

    2) Wird das Attribut OHNE Namespace eingetragen, und das ist m.A. nach auf jeden Fall ein Fehler.

    Und dann noch die Frage, warum bei der Prüfung einer XMLDSig UNBEDINGT validiert werden muss?
    (Ev. wäre es eine Idee für die nächste Release vom MOA-SP, das Validieren per Konfiguration oder (besser) per Schnittstellenparameter ausschaltbar zu machen?)

    ---

    Hat jemand von Ihnen ähnliche Erfahrungen beim Signaturprüfen (z.B. auch mit den IAKI-Libraries) gemacht?

    MfG
    C. Baumann

  • Sehr geehrter Herr Bauman,

    vielen Dank für den Hinweis! Wenn Sie eine Antwort von der moa-developingliste bekommen, können Sie diese bitte auch hier posten?

    Mit besten Dank,
    Maia Zaharieva

  • Also das Problem mit dem PaymentConsolidator-Attribut ist aus meiner Sicht etwas weitreichender und betrifft alle Signaturlösungen.

    Im Prinzip geht es ja darum, ob XMLDSIG-Signaturen über den ebInterface XML-Standard interoperabel sind. Wie wir mittlerweile wissen, fügen manche XML-Parser dieses Attribut (wenn auch ohne Namespace-Prefix) in die XML-Daten hinzu, falls validierend geparsed wird und das Attribut in den Original-Daten nicht angegeben war. Seitens des ebInterface-Standards gibt es allerdings keine Vorschrift, ob dieses Attribut nun in die Signatur eingebettet werden soll oder nicht. Meines Wissens nach macht auch der XMLDSIG-Standard keine Vorschriften, ob validierend geparsed werden muss oder nicht. Somit kann es seitens der Signaturerstellung passieren, dass verschiedene Software-Produkte für die Signaturerstellung dieses Attribut in die Signatur einbeziehen und andere Produkte nicht. Auf der Rechnungsempfangsseite wird die Signatur u. U. wiederum mit anderen Produkten geprüft, die dieses Attribut auch wiederum berücksichtigen oder auch nicht. Somit sind eigentlich Interopatibilitätsprobleme vorprogrammiert.
    Im Prinzip bräuchte man eine klare Vorschrift, ob das Attribut (sofern es im Original-XML nicht angegeben ist) in der Signatur berücksichtigt werden muss oder nicht. Meine Meinung dazu ist, dass man dieses Attribut bei der Signaturerstellung nicht automatisch hinzufügen sollte. Nachdem es in den Original-Daten nicht vorhanden ist, sollten auch genau diese Daten signiert werden und keine Attribute automatisch hinzugefügt werden. Genau diesen Punkt muss man meiner Ansicht nach seitens des ebInterface-Standards klarstellen, damit Produkte (sowohl auf der Signaturerstellungsseite als auch auf der Verifikationsseite) entsprechend implementiert werden können.
    Ein Alternativlösung wäre, auf den Default-Wert zu verzichten und das Attribut lediglich optional zu machen. In diesem Fall ist es egal, ob validierend oder nicht-validierend geparsed wird. Das Attribut wird somit von keinem Parser automatisch hinzugefügt. Allerdings würde dies eine Änderung im Standard bedeuten und ich weiß nicht, ob dies gewünscht / möglich ist.

    Daniel Schmoll

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!