gemSpec_Kon_SigProxy_V1.5.0
Elektronische Gesundheitskarte und Telematikinfrastruktur
Spezifikation
Konnektor Signaturproxy
Version | 1.5.0 |
Revision | 548770 |
Stand | 15.05.2019 |
Status | freigegeben |
Klassifizierung | öffentlich |
Referenzierung | gemSpec_Kon_SigProxy |
Dokumentinformationen
Änderungen zur Vorversion
Einarbeitung Änderungsliste P18.1
Dokumentenhistorie
Version |
Stand |
Kap./ Seite |
Grund der Änderung, besondere Hinweise |
Bearbeitung |
---|---|---|---|---|
Initialversion Online-Produktivbetrieb (Stufe 2.1) |
||||
1.1.0 |
02.08.17 |
freigegeben |
gematik |
|
05.12.17 |
Änderungsliste P15.1 |
gematik |
||
1.3.0 |
18.12.17 |
freigegeben |
gematik |
|
Anpassungen auf Grundlage von P 15.2 |
gematik |
|||
1.4.0 |
14.05.18 |
freigegeben |
gematik |
|
Einarbeitung P18.1 |
gematik |
|||
1.5.0 |
15.05.2019 |
freigegeben |
gematik |
Inhaltsverzeichnis
1 Einordnung des Dokumentes
1.1 Zielsetzung
Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Konnektor Signaturproxy.
Der Signaturproxy ist eine Komponente, die zwischengeschaltet auf der Kommunikationsstrecke zwischen Client-System und Konnektor dafür sorgt, dass die zu signierenden oder zu prüfenden Dokumente dem Nutzer angezeigt werden.
Herstellern von Primärsystemen ist es freigestellt, die Ansichtsfunktion umzusetzen, und auf die Verwendung des Signaturproxy zu verzichten. Bei der Umsetzung der Ansichtsfunktion im Primärsystem sollte sich der Primärsystemhersteller an der Spezifikation des Signaturproxy richten.
1.2 Zielgruppe
Das Dokument ist maßgeblich für die Hersteller von Konnektoren und für die Primärsystemhersteller.
1.3 Geltungsbereich
Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.
Schutzrechts-/Patentrechtshinweis
Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.
1.4 Abgrenzungen
Spezifiziert werden in dem Dokument die von dem Konnektor Signaturproxy bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang A5).
Die vollständige Anforderungslage für den Konnektor Signaturproxy ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps Konnektor verzeichnet.
1.5 Methodik
Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.
Sie werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]
Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und Textmarke [<=] angeführten Inhalte.
1.5.1 Hinweis auf offene Punkte
- Vollständig anzeigbare XML-Formate (Signaturrichtlinien) sind aktuell nicht vorgesehen, könnten aber z.B. mit NFDM ergänzt werden.
2 Systemüberblick
2.1 Funktion des Signaturproxy
Der Signaturproxy hat zwei Hauptaufgaben: die erste Aufgabe besteht darin, eine lokale und optionale Anzeige für die Signaturerstellung und Signaturprüfung zur Verfügung zu stellen, die zweite Aufgabe ist die Weiterleitung des Signaturauftrages an den Konnektor und der Signaturantwort an das Primärsystem.
Um die lokale Anzeige für die Signaturerstellung und Signaturprüfung zu realisieren, ermittelt der Signaturproxy alle Informationen, die für die Anzeige notwendig sind und bereitet die Informationen sowie das Dokument zur Anzeige auf. Im Rahmen der Anzeige bietet der Signaturproxy dem Anwender Möglichkeiten, mit dem Signaturvorgang zu interagieren.
Der Signaturproxy stellt dabei keine „sichere“ Anzeige im Sinne des Signaturgesetzes (SigG/SigV) bereit, wie es der sicherheitsbestätigte xTV in älteren Versionen der Konnektorspezifikation getan hat. Erhalten geblieben sind die beiden Qualitätsniveaus der Anzeige, die jetzt als einfache und vollständige Anzeige bezeichnet werden.
Da durch die aktuelle Gesetzeslage (eIDAS-Verordnung) für die Erstellung einer QES keine sichere Anzeigekomponente notwendig ist, kann sich der Anwender auch mit anderen Mitteln als dem hier spezifizierten Signaturproxy eine hinreichende Sicherheit über den Gegenstand seiner Signatur verschaffen. Der Einsatz des Signaturproxy ist für den Leistungserbringer/Primärsystemhersteller optional und die Anzeigefunktion kann im aufrufenden Primärsystem realisiert werden. Die Bereitstellung des Signaturproxy ist für den Konnektorhersteller obligatorisch.
Um die Weiterleitung des Signaturauftrages an den Konnektor zu implementieren, befindet sich der Signaturproxy im Informationsfluss zwischen dem aufrufenden Primärsystem und dem Konnektor. Der Signaturauftrag wird so vom Primärsystem an den Signaturproxy übergeben und von dem Signaturproxy an den Konnektor. Die Antwort des Konnektors wird genauso über den Signaturproxy an das Primärsystem zurückgemeldet.
2.2 Deployment des Signaturproxy
Der Signaturproxy ist als lokale Anzeigesoftware zum Einsatz auf dem Clientrechner vorgesehen. Daher sollen seine Schnittstellen zum Clientsystem nur auf dem lokalen Interface (localhost) zur Verfügung stehen. Für den Konnektor stellt sich der Signaturproxy wie ein Clientsystem dar. Da der Signaturproxy den Kontext (Clientsystem-ID, Arbeitsplatz-ID, Mandant) aus dem Aufruf weiterreicht, hat der Signaturproxy keine eigene Entität im Informationsmodell des Konnektors.
2.3 Zielstellung für den Signaturproxy
Durch die in diesem Dokument beschriebene Definition des Signaturproxy soll vor allem erreicht werden, dass die Anzeigefunktionalität für die zu signierenden Dokumente sowie bestimmte Validierungsaspekte dieser Dokumente aus dem Konnektor entfernt und in den externen Signaturproxy verlagert werden. In diesem Zusammenhang wird die Komplexität des Konnektors reduziert, die Performance des Signaturvorgangs verbessert und der Evaluierungsaufwand für den Konnektor verringert.
2.4 Schnittstellen des Signaturproxy
In der Abbildung 1 sind sowohl die am Signaturproxy angebotenen als auch die vom Signaturproxy benutzten Schnittstellen dargestellt. Die Zuordnung der einzelnen Operationen zu den entsprechenden Schnittstellen erfolgt in den Kapiteln 2.4.1 und 2.4.2.
2.4.1 Genutzte Logische Operationen
Folgende Operationen des Konnektors werden vom Signaturproxy verwendet:
- Schnittstelle I_Sign_Operations
- I_Sign_Operations::sign_Document
- I_Sign_Operations::verify_Document
- I_Sign_Operations::get_Certificate
- I_Sign_Operations::get_Jobnummer
- I_Sign_Operations::stop_signatur
- Schnittstelle I_SAK_Operations
- I_SAK_Operations::sign_Document_QES
- I_SAK_Operations::verify_Document_QES
- Schnittstelle I_Reg_Notification
- I_Reg_Notification::register_for_Notifications
- Schnittstelle I_Cert_Verification
- I_Cert_Verification::verify_CertificateSchnittstelle I_Poll_System_Information
- I_Poll_System_Information::Get_Ressource_Information
Der Notification-Mechanismus ist für alle Clientsysteme (einschließlich Signaturproxy) gleich: Beim Erstellen einer Subscription wird die Senke für die Events dieser Subscription angegeben. Dadurch kann der Konnektor die Events an die entsprechenden Systeme zustellen, z. B. an das Primärsystem oder an den Signaturproxy.
2.4.2 Angebotene Logische Operationen
Folgende Operationen vom Signaturproxy angeboten:
- Schnittstelle I_Notification
- I_Notification::notify
- Schnittstelle I_TV_User_Interaction
- I_TV_User_Interaction::display_Document
- I_TV_User_Interaction::display_Metadata
- I_TV_User_Interaction::request_Confirmation
- Schnittstelle I_Sign_Operations
- I_Sign_Operations::sign_Document
- I_Sign_Operations::verify_Document
- Schnittstelle I_SAK_Operations
- I_SAK_Operations::sign_Document
- I_SAK_Operations::verify_Document
2.5 Anwendungsfälle
Die in der Abbildung 2 dargestellten interaktiven Anwendungsfälle werden durch folgende logische Operationen umgesetzt:
- Sign_Document(_QES):
- Signaturauftrag freigeben:
Der Signaturauftrag wird nach Prüfung in der Anzeige zur Erstellung der Signatur freigegeben. - Signaturauftrag ablehnen
Der Signaturauftrag wird nach Prüfung in der Anzeige abgebrochen. Es wird ein Fehler an das aufrufende System gemeldet - Dokument aus Signaturstapel entfernen
Aus einem Stapelsignaturauftrag wird ein Dokument entfernt. Der geänderte Signaturauftrag kann dann freigegeben werden. - Signaturfortschritt einsehen
Der Fortschritt eines Stapelsignaturauftrags wird dem Anwender angezeigt. Die erfolgreiche Erstellung der Signatur wird dem Benutzer angezeigt. Die Anzeige wird vom Benutzer oder nach Zeitablauf gelöscht. - Stapelsignatur abbrechen
Ein Stapelsignaturauftrag wird abgebrochen. Bereits signierte Dokumente werden zurückgeliefert. - Verify_Document(_QES):
- Signaturprüfung freigeben
Eine Signaturprüfung mit Warnungen wird von dem Benutzer als gültig akzeptiert und mit Status „OK“ an das führende System zurückgemeldet. - Signaturprüfung ablehnen
Eine Signaturprüfung mit Warnungen wird von dem Benutzer als ungültig eingestuft und mit Status „Fehler“ an das führende System zurückgemeldet.
2.6 Abläufe (exemplarisch)
Die in diesem Kapitel enthaltenen Ablaufdiagramme haben einen informativen Charakter. Die abgebildeten Parameter können eine Untermenge aller erlaubten Parameter darstellen. Die Aufrufe der spezifizierten Methoden sind mit dem definierten Namen identifiziert, alle übrigen Abläufe sind rein informativ umschrieben.