Rückfragen zu 'Signature' und 'verifikation' #15
Comments
|
Hallo Herr Wassmann, zunächst vielen Dank für den wichtigen Input. In der Tat muss das Feld Verifikation noch genauer definiert werden. Ihr Vorschlag klingt sehr sinnvoll. Wir werden das diskutieren und im Rahmen des nächsten XHS-Release berücksichtigen. Das Thema Signature sollten wir auch noch einmal unter die Lupe nehmen. Möglicherweise liegt dieses Thema aber auch außerhalb des fachlichen Payloads und damit nicht mehr im Scope von XHochschule. Eine genauere Abgrenzung ist hier ggf. noch erforderlich. Vielen Dank und beste Grüße |
|
Hallo Herr Herzog, ich denke, dass Signature ein Teil der XSD sein muss. Ich denke, dass man diesen Teil direkt aus der ELMO-Spezifikation übernehmen könnte. Danke und viele Grüße |
|
Guten Tag,
Die Anpassung auf Ebene von |
init-xhochschule
added
the
In Progress
Hallo, ist das wirklich schon berücksichtigt? In der Spezifikation finden wir dazu nichts ... Danke und Grüße |
|
Ich möchte nochmal auf die Dringlichkeit einer Signatur im XML hinweisen. Bitte berücksichtigen Sie dies wieder, damit wir das Ganze zum fliegen bekommen können. HISinOne könnte schon bald XHEIE-Bescheide erstellen und annehmen, wenn es die Signatur wieder gäbe. |
|
Eine Möglichkeit wäre mittels "Enveloping XMLDsig" das XML im PDF einzubinden. Das würde bedeuten, dass die XML-Spezifikation von XBildung/XSchule bzw. XHochschule nicht davon betroffen wäre. <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
...
<Reference URI="#object">
...
</SignedInfo>
<Object Id="object"><!-- XML-Dokument aus XBildung/XSchule/XHochschule --></Object>
</Signature>``` |
|
Hallo Herr Wassmann, Beste Grüße Robin Dietrich |
|
Hallo in die Runde, was mir halt wichtig ist, dass ich eine Signatur auch unabhängig von einem PDF habe. Die PDF-Einbettung ist ja nur eine Krücke bis wir etwas besseres haben, um die elektronischen Daten auszutauschen. Das digitale Dokument brauche im Prozess, aus technischer Sicht, im Grunde gar nicht. HISinOne-Hochschulen könnten z.B., mit Zustimmung des Nutzenden, die Daten im XHEIE-Format auch direkt via Webservices austauschen. Vielen Dank und beste Grüße |
|
Hallo an alle, Wir haben uns mit der Implementierung von Signaturen in unseren Dokumenten beschäftigt und sind zu dem Schluss gekommen, dass die einfachste Lösung für uns die Verwendung von externen/detached Signaturen (also für jedes Dokument eine Signatur in einer getrennten XML-Datei) wäre. Diese könnten ab sofort ohne weitere Änderungen am Modell eingesetzt werden und würden bei der Verarbeitung von XHochschule-Nachweisen keine zusätzlichen Bearbeitungsschritte voraussetzten. Bevor wir uns für diese Variante entscheiden, möchten wir uns gerne mit Ihnen abstimmen und sicherstellen, dass diese Lösung für alle Beteiligten akzeptabel ist. Beste Grüße Robin Dietrich |
|
Hallo @ALL!
Ich bitte dies bei der Empfehlung der "Detached Signature" noch einmal zu überdenken. |
|
Hallo in die Runde,
Wir haben die Variante detached signatures bei uns diskutiert. Unserer Meinung nach wäre sie nicht ohne weiteren Aufwand anwendbar, da der Bezug zwischen Dokument und Signatur nicht klar ist. Unsere Fragen und Anregungen zum Thema:
- Wie wird der Bezug zwischen beiden XML klar, wenn sie einzeln rumliegen? Standard ist URI-Angabe, die benennt, was signiert wurde
- In den Spezifikationen gibt es keine URI-Angabe, auf die referenziert werden kann -> man müsste xbd erweitern um URI, zB mit einem separaten namespace für die URI mit klaren Vorgaben, was dort reingehört (zB ein timestamp für die Eindeutigkeit des Dokuments)
- Werden die XML zusammen abgelegt? Wenn ja, in welchem Format? Bei mehreren Dokumente: In welcher Struktur?
- grundsätzlich: Was sind die Voraussetzungen für die Signierung?
- Welche Signierservices eignen sich für diese Variante? Welche davon sind vertrauenswürdig? Wie wird das beurteilt und wie dokumentiert?
Hat eigentlich eine Kommunikation mit dem Projekt der NBP stattgefunden? Soweit wir wissen, verfolgen die nicht das Konzept der detached signatue. Es wäre doch ärgerlich, in zwei verschiedene Richtungen zu laufen.
Beste Grüße
Jessica Bülau
—
Jessica Bülau
S4Campus AG
Campus Management System vom führenden Digitalisierungspartner für Hochschulen
www.s4campus.ag<http://www.s4campus.ag>
Universitätsplatz 12 | 39104 Magdeburg
Tel.: +49 391 50 54 97 87 | Fax.: +49 391 50 54 97 89
Sitz der Gesellschaft: Magdeburg
Handelsregister: Stendal HRB 30949
Vorstand: Dr. Dirk Pape (Vorstandsvorsitz), Carsten Görling, Ronny Zimmermann
Vorsitzender des Aufsichtsrats: Dr. Lutz Beilschmidt
Von: init-xhochschule ***@***.***>
Datum: Dienstag, 2. Mai 2023 um 15:30
An: OZG-TFBildung/XHochschule ***@***.***>
Cc: Subscribed ***@***.***>
Betreff: Re: [OZG-TFBildung/XHochschule] Rückfragen zu 'Signature' und 'verifikation' (Issue #15)
Hallo an alle,
Wir haben uns mit der Implementierung von Signaturen in unseren Dokumenten beschäftigt und sind zu dem Schluss gekommen, dass die einfachste Lösung für uns die Verwendung von externen/detached<https://ec.europa.eu/digital-building-blocks/wikis/download/attachments/160793673/image2019-10-10_21-34-43.png> Signaturen (also für jedes Dokument eine Signatur in einer getrennten XML-Datei<https://docs.digicert.com/de/digicert-one/software-trust-manager/signing-tools/sign-xml-files-with-detached-signature-using-openssl.html>) wäre. Diese könnten ab sofort ohne weitere Änderungen am Modell eingesetzt werden und würden bei der Verarbeitung von XHochschule-Nachweisen keine zusätzlichen Bearbeitungsschritte voraussetzten. Bevor wir uns für diese Variante entscheiden, möchten wir uns gerne mit Ihnen abstimmen und sicherstellen, dass diese Lösung für alle Beteiligten akzeptabel ist.
Wir würden uns freuen, wenn Sie uns Ihre Meinung dazu mitteilen könnten. Falls Sie sich für die Verwendung von externen Signaturen aussprechen, würden wir gerne wissen, welche Informationen Sie von uns benötigen, um diese Implementierung in Ihre Systeme zu integrieren.
Beste Grüße
Robin Dietrich
—
Reply to this email directly, view it on GitHub<#15 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A56XHRTLXOCMXQO5OVUU5DLXEED7PANCNFSM5OPDQEPA>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
|
Hallo nochmals,
wir möchten zu dem Thema gern noch die User-Sicht hinzufügen:
Damit der User die Übersicht behalten kann, bräuchte es im Grunde noch eine Klammer für beide Dokumente. Wie soll er denn sonst wissen, welche Signatur zu welchem Dokument gehört? Und wie verhält sich das, wenn es mehrere Zertifikate für ein Dokument mit unterschiedlichen timestamps gibt? Wenn der User die falsche Dokument-Signatur-Kombination verschickt, explodiert der Kommunikationsaufwand, nicht nur für ihn, sondern auch für die Verwaltung.
Außerdem müssen verschiedene Ablagesysteme berücksichtigt werden. Schön und gut, wenn wir die beiden XML im CaMS ablegen können, aber der User legt die Dokumente höchst wahrscheinlich in seine Wallet und verschickt sie von hier aus. Kann die das denn so einfach abbilden?
Die Lösung muss also auf jeden Fall auch die UX-Aspekte berücksichtigen.
Beste Grüße
Jessica Bülau
—
Jessica Bülau
S4Campus AG
Campus Management System vom führenden Digitalisierungspartner für Hochschulen
www.s4campus.ag<http://www.s4campus.ag>
Universitätsplatz 12 | 39104 Magdeburg
Tel.: +49 391 50 54 97 87 | Fax.: +49 391 50 54 97 89
Sitz der Gesellschaft: Magdeburg
Handelsregister: Stendal HRB 30949
Vorstand: Dr. Dirk Pape (Vorstandsvorsitz), Carsten Görling, Ronny Zimmermann
Vorsitzender des Aufsichtsrats: Dr. Lutz Beilschmidt
Von: init-xhochschule ***@***.***>
Datum: Dienstag, 2. Mai 2023 um 15:30
An: OZG-TFBildung/XHochschule ***@***.***>
Cc: Subscribed ***@***.***>
Betreff: Re: [OZG-TFBildung/XHochschule] Rückfragen zu 'Signature' und 'verifikation' (Issue #15)
Hallo an alle,
Wir haben uns mit der Implementierung von Signaturen in unseren Dokumenten beschäftigt und sind zu dem Schluss gekommen, dass die einfachste Lösung für uns die Verwendung von externen/detached<https://ec.europa.eu/digital-building-blocks/wikis/download/attachments/160793673/image2019-10-10_21-34-43.png> Signaturen (also für jedes Dokument eine Signatur in einer getrennten XML-Datei<https://docs.digicert.com/de/digicert-one/software-trust-manager/signing-tools/sign-xml-files-with-detached-signature-using-openssl.html>) wäre. Diese könnten ab sofort ohne weitere Änderungen am Modell eingesetzt werden und würden bei der Verarbeitung von XHochschule-Nachweisen keine zusätzlichen Bearbeitungsschritte voraussetzten. Bevor wir uns für diese Variante entscheiden, möchten wir uns gerne mit Ihnen abstimmen und sicherstellen, dass diese Lösung für alle Beteiligten akzeptabel ist.
Wir würden uns freuen, wenn Sie uns Ihre Meinung dazu mitteilen könnten. Falls Sie sich für die Verwendung von externen Signaturen aussprechen, würden wir gerne wissen, welche Informationen Sie von uns benötigen, um diese Implementierung in Ihre Systeme zu integrieren.
Beste Grüße
Robin Dietrich
—
Reply to this email directly, view it on GitHub<#15 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A56XHRTLXOCMXQO5OVUU5DLXEED7PANCNFSM5OPDQEPA>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
|
Die von @jbuelau geschilderten Herausforderungen würden im Fall der Enveloping Signature nicht entstehen, da das "Daten-XML" von dem Signtaur-XML "umhüllt" (enveloping)" ist. Beste Grüße |
|
Hallo, auch aus Sicht der HIS eG ist eine Lösung mit zwei Dateien unpraktisch und nicht zielführend. Wir fordern weiterhin eine technisch saubere und nachhaltige Lösung, so wie es die Kolleginnen und Kollegen ebenfalls schon getan haben. Wir schielen natürlich auch so ein bisschen in Richtung NBP ... Danke und Grüße |
|
Hallo, da im Workshop gerade eine Entwicklung im laufenden Monat angekündigt wurde, stellt sich für uns die Frage, wie wir hier zu einer Entscheidung kommen können, was denn nun entwickelt wird. Soweit ich das jetzt auch außerhalb der Diskussion hier mitbekommen habe, ist keiner der CMS-Hersteller mit der Lösung zufrieden. Wir haben zwischenzeitlich auch mit einem Wallet-Hersteller gesprochen. Von deren Seite wurde ebenfalls die Nutzerunfreundlichkeit der detached signature, wi ich sie oben schon angedeutet habe, unterstrichen. Wie geht es nun weiter? Beste Grüße |
|
Hallo, Ein paar Gedanken rund um die Signatur des xBildungs-"Daten"-XMLs. Ich lasse hier bewusst die "XMLDsig Enveloped" aus, da dies die Konsequenz hätte, dass das Schema xBildung mit der Signatur adaptiert werden müsste. Aktuell soll uns das PDF als "Transport-Objekt" für digital verarbeitbare XML-Daten aus den Bereichen xHochschule, xSchule und xBildung dienen. Damit die richtige XML-Datei (die richtigen XML-Dateien) gefunden werden sollte dies "normiert" werden. Dies hat nichts mit der XML-Schema-Spezifikation zu tun. Enveloping Detached Unabhängig von Enveloping oder Detached: Ebenfalls denken wir, dass das PDF und das XML mit dem selben zertifizierten Signatur-Schlüssel unterzeichnet werden sollte. Beste Grüße Beispiele: <!-- XMLDsig Enveloping ........................................................................... -->
<!-- File "xBildung-Info.xml" -->
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
...
<Reference URI="#xBildung-Data"> ... </Reference>
...
</SignedInfo>
<Object Id="xBildung-Data">
<xsc:schueler.abiturzeugnis.0002>
<!-- XML-Daten-Dokument aus XBildung/XSchule/XHochschule -->
...
</xsc:schueler.abiturzeugnis.0002>
</Object>
</Signature>
<!-- XMLDsig Detached .. signature file ........................................................... -->
<!-- File "xBildung-Signature.xml" -->
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
...
<Reference URI="**file://hostname.de/directory/xBildung-Data.xml**"> ... </Reference>
...
</SignedInfo>
</Signature>
<!-- XMLDsig Detached .. data file ................................................................ -->
<!-- File "xBildung-Data.xml" -->
<xsc:schueler.abiturzeugnis.0002>
<!-- XML-Daten-Dokument aus XBildung/XSchule/XHochschule -->
...
</xsc:schueler.abiturzeugnis.0002>``` |
|
Hallo Frau Bülau, Hallo Herr Huber, wir haben uns, wie wir im Workshop am 17.05. erklärt haben, für eine Enveloped-signatur als optionales Element auf Ebene von den einzelnen XHochschule Nachrichten entschieden. Dieser Ansatz vermeidet die von Ihnen beschriebenen Probleme mit der Zuordnung von Dokument zu Signatur. Nach unserem Verständnis ist dies auch der Ansatz, der zur Signatur von ELMO-Nachrichten verwendet wird und sich bewährt hat. Das Problem mit der Zuordnung von PDF zu XML ist dagegen ein Punkt, der noch größtenteils offen ist. Wie Sie, Herr Huber, richtig angemerkt haben, ist das ein Thema, das nichts mit der XML-Schema-Spezifikation zu tun hat. Es bleibt also hier noch zu klären, wie wir hier eine Standardisierung umsetzen können. Es erscheint auch uns sinnvoll, dass die XML-Datei mit demselben Zertifikat signiert wird, wie das PDF, an das sie angehängt ist, allerdings können wir auch das aus XHochschule nicht prüfen oder vorschreiben. Beste Grüße Robin Dietrich |
|
Sehr geehrte Damen und Herren, ich verfolge den Thread mit großem Interesse! Wer wäre den dafür zuständig, zu klären und zu entscheiden, wie die XML-Datei und das PDF-Dokument zu signieren sind. Wenn das klar ist, könnte man aus X-Hochschule heraus eine entsprechende Unterlage erstellen, um die Festlegung verbindlich entscheiden zu lassen. Viele Grüße |
|
Hallo Herr Dietrich,
Enveloped ist auch in Ordnung. Jedoch denke ich, dass dies auf Grund der Interoperabilität auf der Ebene von xBildung etabliert sein muss. Ggf. als erstes (optionales) Element. Z.B.: -> xbildung-baukasten.xsd <xs:complexType name="Dokument">
<xs:sequence>
<xs:element xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:dsig11="http://www.w3.org/2009/xmldsig11#"
ref="ds:Signature"
minOccurs="0"/>
<!-- ... -->
</xs:sequence>``` |
|
Hallo, wir erwarten hier weiterhin die Signatur als Enveloped-Signatur. Unsere Implementierungen rundum das Framework zur Erzeugung und Verarbeitung von XHEIE-Nachrichten ist weit fortgeschritten und soll jetzt abgeschlossen werden. Wie Sieht es hier auf Seiten von XHochschule aus? Danke und Grüße |
|
Guten Tag! Wir haben in der gestern releasten Version 0.95 wieder eine Enveloped-Signatur eingebaut. Wir haben uns gegen die Einführung auf der Ebene von XBildung entschieden und werden dies pro Teilprojekt umsetzen. Auch eine Setzung an erster Stelle war für uns nicht sinnvoll, da bspw. Oxygen nicht mit einer Setzung an erster Stelle harmoniert und im Rahmen üblicher Praxis automatisch ans Ende setzt. Um hier Konflikte zu vermeiden, haben wir uns für diesen Weg entschieden. Beste Grüße |
|
Hallo, das Signatur-Element in 0.95 ist n.m.E. korrekt und funktioniert wie erwartet. Die anhängige Datei (PDF inkl. PAdES-Signatur) enthält einen Immatrikulationsbescheid gemäß XHochschule 0.95 und inkl. einer Signatur nach XAdES-T. Geben Sie gern Rückmeldung zur Schema-Konformität, ich habe für 0.95 noch keine Schematron-Validierung aktiv. Viele Grüße |
Autor: Arn Waßmann | HIS eG
Art der Organisation: CAMS-Hersteller
Beschreibung:
In der (noch) aktuellen Fassung 0.8 vermisse in der XSD einen Abschnitt 'Signature'. Diesen bitte analog zu ELMO (https://github.com/emrex-eu/elmo-schemas/blob/v1/schema.xsd) grundsätzlich vorsehen (https://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd).
Wie ist der Abschnitt 'verifikation' in 0.8 genau gemeint? Wird hier eine allgemeine 'adresse' zur Verifikationsfunktion des CaMS erwartet, bspw. https://example.his.de/hisinone/pages/start.html?_id=verification (nicht aufrufbar) ? Dann würde aber der Beschreibungstext nicht stimmen: "Dazu enthält die Bescheinigung eine für jeden Studenten einmalige URL." Dann würde ich einen Deeplink hier einstellen, der den Verifikationscode bereits enthält (nicht zu empfehlen). Dieser wird aber laut XSD in einem extra Feld ('schluessel') erwartet und stellt dann eine Redundanz dar. Dann steht in dem Beschreibungstext für 'schluessel' dieses hier: "Dazu enthält die Bescheinigung eine für jeden Studenten einmalige Verifikationsnummer." Welches Dokument soll hier genau referenziert werden? Ist es das PDF, welches der Studie bekommt (automatisch erzeugt) und was schon heute verifiziert werden kann oder ist ein Link auf das elektronische Dokument (XML-Datei nach XHochschule-Vorgabe) gemeint? Oder braucht es vielleicht beides, dann braucht es aber auch zwei Angaben von 'verifikation', also (0...2) und nicht nur (0...1). Auch enthalten die Dokumente eindeutige Nummern, nicht die Studierenden. Letzteres würde dazu führen, dass ich alle Dokumente eines Studierenden sehen könnte. Das wäre fatal. Mir ist auch der Zusammenhang, zwischen trägt keine Unterschrift und der Verifikation unklar. Ich lasse in meinem Vorschlag diese Formulierung aber drin.
Ich mache zur 'verifikation' folgenden Vorschlag, besonders wichtige Änderungswünsche sind fett:
verifikation (0...2): Zusätzliche Informationen der Bildungseinrichtung zur Verifikation der Nachricht. Es können bis zu zwei Adressen angegeben werden. Eine Adresse dient zur Verifikation eines PDF-Dokuments und eine zur Verifikation einer XML-Datei.
jedes Dokument einmalige Verifikationsnummer. Diese darf nicht Teil der Adresse sein.
Beispiel:
Hinweis: Der direkte Download des Dokuments wird in der Regel durch zusätzliche Sicherheitsmaßnahmen, wie bspw. die Eingabe eines Captchas, verhindert. Sollte das gewünscht sein, muss man über weitere Sicherheitsmaßnahmen nachdenken. Auch wäre dann das Senden des Codes via GET nicht zu empfehlen. Es müsste min. ein POST sein.
Vielen Dank und beste Grüße
Arn Waßmann
The text was updated successfully, but these errors were encountered: