gemSpec_Kon_KomfSig_V1.1.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Ergänzung zur Spezifikation

Konnektor (PTV4)

    

     

      
Version
      
1.1.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
07.04.2021
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_Kon_KomfSig
     
    

Dokumentinformationen

Änderungen zur Vorversion

Es handelt sich um die Erstversion des Dokumentes.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Das vorliegende Dokument ergänzt das Dokument [gemSpec_Kon_V5.9.0] um die Funktionalität "Komfortsignatur". Das Ziel ist, alle Anforderungen zur Herstellung, Test und Betrieb des Produkttyps "Konnektor PTV4Plus mit Komfortsignatur" bereitzustellen. 

1.2 Zielgruppe

Das Dokument richtet sich an Konnektorhersteller sowie Hersteller und Anbieter von Produkttypen, die hierzu eine Schnittstelle besitzen.

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 bekanntgegeben.

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 Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert.

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps "Konnektor PTV4Plus mit Komfortsignatur" verzeichnet.

1.5 Methodik

1.5.1 Anforderungen

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID 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 innerhalb der Afo-ID und der Textmarke angeführten Inhalte.

1.5.2 Hinweise zur Benutzung dieses Ergänzungsdokuments

In diesem Dokument stehen nur die geänderten Passagen zur zugrunde liegenden Konnektor-Spezifikation. Alle anderen Teile gelten wie in [gemSpec_Kon_V5.9.0] beschrieben. Die Kapitelstruktur von [gemSpec_Kon_V5.9.0] wurde beibehalten, um dem Leser die Zuordnung der für die Komfortsignatur geänderten Anforderungen zu erleichtern. Bei Kapiteln ohne Änderungen ist nur die Überschrift genannt.

2 Systemüberblick

Die Komfortsignaturfunktion stellt einen Modus des Konnektors bereit, bei dem für die QES mit ein- und denselben HBA mehrere vom Clientsystem initiierte Signaturaufträge (Einzel- oder Stapelsignatur) abgearbeitet werden, ohne dass der Inhaber des HBA für jeden einzelnen dieser Signaturaufträge die PIN.QES am Kartenterminal eingegeben muss.

3 Übergreifende Festlegungen

3.1 Konnektoridentität und gSMC-K

3.2 Bootup-Phase

3.3 Betriebszustand (Kap 3.3)

[Hinweis: Die Anforderung TIP1-A_4510-03 wird nach der Anforderung TIP1A_4510 eingefügt und ersetzt TIP1-A_4510-02 ]

[Hinweis: In der Tabelle TAB_KON_504 werden für den Bereich "Operation der Basisdienste" im Signaturdienst drei Operationen ergänzt: ActivateComfortSignature, DeactivateComfortSignature, GetSignatureMode]

Tabelle 2: TAB_KON_504 Ausführungserlaubnis für Dienste in kritischen Fehlerzuständen

4 Funktionsmerkmale

4.1 Anwendungskonnektor

4.1.1 Kartendienst

[Hinweis: In der Tabelle TAB_KON_531 bleiben die Einträge zu "CM_CARD_LIST" unberührt; im Abschnitt "CARD.CARDSESSION_ LIST" wird der Parameter "CARDSESSION. SIGNMODE" ergänzt.]

Der Kartendienst verwaltet mindestens die in der informativen Tabelle TAB_KON_531 ausgewiesenen Parameter, weitere herstellerspezifische Parameter sind möglich. Die normative Festlegung wann welche Parameter wie belegt werden, erfolgt in den folgenden Abschnitten und Unterkapiteln.

Tabelle 3: TAB_KON_531 Parameterübersicht des Kartendienstes

4.1.1.1 Funktionsmerkmalweite Aspekte

4.1.2 Dokumentvalidierungsdienst

4.1.3 Dienstverzeichnisdienst

4.1.4 Kartenterminaldienst

4.1.5 Kartendienst

4.1.6 Systeminformationsdienst

4.1.7 Verschlüsselungsdienst

4.1.8 Signaturdienst (Kap 4.1.8)

4.1.8.1 Funktionsmerkmalweite Aspekte

4.1.8.1.1 Dokumentensignatur

4.1.8.1.2 Signaturrichtlinien

4.1.8.1.3 Signaturzeitpunkt

4.1.8.1.4 Jobnummer

4.1.8.1.5 Komfortsignatur (Kap. 4.1.8.1.5 - neu)

Für die QES unterstützt der Konnektor die Komfortsignaturfunktion. In diesem Modus können für ein- und denselben HBA mehrere vom Clientsystem initiierte Signaturaufträge (Einzel- oder Stapelsignatur) abgearbeitet werden, ohne dass der Inhaber des HBA für jeden einzelnen dieser Signaturaufträge die PIN.QES am Kartenterminal eingegeben haben muss.

Im Auslieferungszustand ist die Komfortsignaturfunktion ausgeschaltet (SAK_COMFORT_SIGNATURE = Disabled), d. h. mit dem Konnektor können zunächst keine Komfortsignaturen durchgeführt werden. Die Komfortsignaturfunktion kann vom Administrator eingeschaltet werden. Dies ist nur möglich, wenn an der Clientsystemschnittstelle des Konnektors verpflichtend TLS mit Clientauthentisierung (Konfigurationsvariante SOAP1 und SOAP2 in TAB_KON_852) konfiguriert ist. Das Einschalten der Komfortsignaturfunktion im Konnektor hat zur Folge, dass alle Operationen an der Clientsystemschnittstelle nur über TLS mit Clientauthentisierung angesprochen werden können (außer ggf. Dienstverzeichnisdienst).

Bei eingeschalteter Komfortsignaturfunktion können potentiell alle HBAs in der Umgebung, in der der Konnektor eingesetzt ist, Komfortsignaturen durchführen. Die eigentliche Aktivierung der Komfortsignatur muss separat für jeden einzelnen HBA erfolgen.

Durch Aufruf der Operation ActivateComfortSignature des Konnektors durch das Primärsystem wird die Nutzung der Komfortsignatur für einen HBA (Komfortsignaturmodus) aktiviert. Dazu muss der HBA-Inhaber die PIN.QES eingeben.

Der Konnektor merkt sich für die Cardsession des HBA, dass die Komfortsignatur aktiviert wurde. Bei den folgenden Aufrufen von SignDocument werden dann Komfortsignaturen ausgeführt, solange bis eines der folgenden Abbruchkriterien eintritt:

·       Die vom HBA (entsprechend Personalisierung) oder die vom Konnektor (entsprechend Konfiguration SAK_COMFORT_SIGNATURE_MAX) durchgesetzte maximale Anzahl von Signaturen wurde erreicht.

·       Das konfigurierte Zeitintervall für die Komfortsignatur (entsprechend Konfiguration SAK_COMFORT_SIGNATURE_TIMER) ist für die Cardsession abgelaufen (Signaturaufträge, die zum Zeitpunkt des Ablaufens des konfigurierten Zeitintervalls bereits zur Bearbeitung angenommen wurden, werden vollständig abgearbeitet).

·       Der Komfortsignaturmodus wurde für die betroffene Cardsession deaktiviert.

·       Der HBA wurde gezogen.

·       Der Sicherheitszustand des HBA wurde zurückgesetzt.

·       Die Komfortsignaturfunktion wurde für den Konnektor durch den Administrator deaktiviert.

A_18597 kann z. B. umgesetzt werden, indem

·       ein dedizierter logischer Kanal des HBA für die Komfortsignatur verwendet wird und

·       im dedizierten logischen Kanal des HBA die Selektion von DF.QES solange beibehalten wird, bis ein Verlassen von DF.QES durch die Spezifikation explizit gefordert wird.

Wenn während der Abarbeitung eines Signaturauftrags der Timer abläuft, werden Signaturaufträge, die bereits zur Bearbeitung angenommen wurden, noch vollständig abgearbeitet, wenn kein anderes relevantes Abbruchkriterium eintritt (z. B. gezogener HBA oder zurückgesetzter Sicherheitszustand des HBA).

4.1.8.2 Durch Ereignisse ausgelöste Reaktionen

keine

4.1.8.3 Interne TUCs, nicht durch Fachmodule nutzbar

Abbildung PIC_KON_102 Use Case Diagramm Signaturdienst (Komfortsignatur) beschreibt die Aufrufbeziehungen der TUCs des Signaturdienstes für die Komfortsignatur.

Abbildung 1: PIC_KON_102 Use Case Diagramm Signaturdienst (Komfortsignatur)

4.1.8.3.1 TUC_KON_158 "Komfortsignaturen erstellen" (Kap 4.1.8.3.7 - neu)

Der TUC_KON_158 führt die Komfortsignatur für ein Dokument oder mehrere Dokumente eines Stapels aus. Da die Komfortsignatur auf der Zielkarte passende CVC voraussetzt, die auf den HBA-Vorläuferkarten nicht vorhanden sind, unterstützt dieser TUC nur den HBA.

4.1.8.4 Interne TUCs, auch durch Fachmodule nutzbar (Kap. 4.1.8.4)

4.1.8.4.1 TUC_KON_170 „Dokumente mit Komfort signieren” (Kap. 4.1.8.4.7 - neu)

4.1.8.4.2 TUC_KON_171 „Komfortsignatur einschalten” (Kap 4.1.8.4.8 - neu)

4.1.8.4.3 TUC_KON_172 „Komfortsignatur ausschalten” (Kap 4.1.8.4.9 - neu)

4.1.8.4.4 TUC_KON_173 „Liefere Signaturmodus” (Kap. 4.1.8.4.10 -neu)

4.1.8.5 Operationen an der Außenschnittstelle (Kap. 4.1.8.5)

4.1.8.5.1 SignDocument (nonQES und QES) (Kap. 4.1.8.5.1)

TIP1-A_5010-06 - Operation SignDocument (nonQES und QES)

Der Signaturdienst des Konnektors MUSS an der Clientschnittstelle eine an [OASIS-DSS] angelehnte Operation SignDocument anbieten.

Tabelle 16: TAB_KON_065 Operation SignDocument (nonQES und QES)

Name	SignDocument
Beschreibung	Diese Operation lehnt sich an [OASIS-DSS] an. Sie enthält voneinander unabhängige SignRequests. Jeder SignRequest erzeugt eine Signatur für ein Dokument. Für die qualifizierte elektronische Signatur (QES) werden die QES_DocFormate unterstützt. Für nicht-qualifizierte elektronische Signaturen (nonQES) werden die nonQES_DocFormate unterstützt. Zur Signaturerzeugung werden Schlüssel und Zertifikate einer Chipkarte benutzt. Unterstützte Karten sind für die QES der HBAx mit dem QES-Zertifikat. Für die nonQES wird für die Signaturtypen „XML-Signatur, CMS-Signatur, PDF-Signatur, S/MIME-Signatur“ die SM-B mit dem OSIG–Zertifikat unterstützt. Bei der Erstellung von XML-Signaturen MUSS Canonical XML 1.1 verwendet werden [CanonXML1.1]. Es soll der Common-PKI-Standard eingesetzt werden, siehe [Common-PKI]. In Summe für die Größe der Dokumente in allen SignRequests innerhalb einer SignDocument-Anfrage MUSS der Konnektor eine Gesamtgröße von <= 250 MB unterstützen.
Aufruf-parameter
	Name		Beschreibung
	CONN: Card Handle		Identifiziert die zu verwendende Signaturkarte. Die Operation DARF die Signatur mit der eGK NICHT unterstützen. Wird die Operation mit einem nicht unterstützten Kartentypen aufgerufen, so MUSS der Konnektor die Bearbeitung mit dem Fehler 4126 abbrechen.
	SIG: Crypt		Der Parameter crypt steuert die Auswahl der Zertifikate und Schlüssel für die Signaturerstellung abhängig von der durch cardHandle adressierten Karte gemäß TAB_KON_900. Defaultwert:  gemäß TAB_KON_862-01 für die QES  gemäß TAB_KON_863 für die nonQES.
	CCTX: Context		Aufrufkontext QES mit HBAx: MandantId, ClientSystemId, WorkplaceId, UserId verpflichtend Aufrufkontext nonQES mit SM-B: MandantId, ClientSystemId, WorkplaceId verpflichtend; UserId nicht ausgewertet
	TvMode		Der Parameter wird im Konnektor nicht ausgewertet.
	SIG: JobNumber		Die Nummer des Jobs, unter der der nächste Signaturvorgang gestartet wird. Parameter ist verpflichtend.
	SIG: Sign Request		Ein SignRequest kapselt den Signaturauftrag für ein Dokument. Das verpflichtende XML-Attribut RequestID identifiziert einen SignRequest innerhalb eines Stapels von SignRequests eindeutig. Es dient der Zuordnung der SignResponse zum jeweiligen SignRequest.
	SIG: Optional Inputs		Enthält optionale Eingangsparameter (angelehnt an dss:OptionalInputs gemäß [OASIS-DSS] Section 2.7):
	SIG: Document		Dieses an das dss:Document Element aus [OASIS-DSS] Section 2.4.2 angelehnte Element enthält das zu signierende Dokument, wobei die Kindelemente CONN:Base64XML und dss:Base64Data auftreten können. Bei den als dss:Base64Data übergebenen Dokumenten werden folgende (Klassen von) MIME-Types unterschieden: ”application/pdf-a” – für PDF/A-Dokumente, ”text/plain”, ”text/plain; charset=iso-8859-15” oder ”text/plain; charset=utf-8” – für Text-Dokumente, ”image/tiff” – für TIFF-Dokumente und ein beliebiger anderer MIME-Type für nicht näher unterschiedene Binärdaten des spezifizierten Typs. Der MIME-Type „text/plain“ wird interpretiert als „text/plain; charset=iso-8859-15”. Das Element enthält ein Attribut ShortText Es muss für QES-Signaturen bei jedem Aufruf vom Clientsystem übergeben werden, für nonQES-Signaturen ist es optional. Über das Attribut RefURI kann gemäß [OASIS-DSS] (Abschnitt 2.4.1) ein zu signierender Teilbaum eines XML-Dokuments ausgewählt werden. Wenn die Signatur eines Teilbaums für die  Signaturvariante nicht unterstützt wird, muss der Signaturauftrag mit Fehler 4111 abgelehnt werden.
	SIG: Include Revocation Info		Durch diesen verpflichtenden Schalter kann der Aufrufer die Einbettung von zum Zeitpunkt der Signaturerstellung vorliegenden Sperrinformationen anfordern. Es wird ausschließlich die zu erstellende Signatur betrachtet, d.h. es erfolgt keine Einbettung von Sperrinformationen für bereits enthaltene Signaturen. Für nicht-qualifizierte elektronische Signaturen (nonQES) wird diese Funktionalität nicht unterstützt. Für PDF-Signaturen werden keine Sperrinformationen eingebettet.
	dss: Signature Type		Durch dieses in [OASIS-DSS] (Abschnitt 3.5.1) beschriebene Element kann der generelle Typ der zu erzeugenden Signaturen spezifiziert werden. Hierbei MÜSSEN folgende Signaturtypen unterstützt werden: XML-Signatur Durch Übergabe der URI urn:ietf:rfc:3275 wird die Erstellung von XML-Signaturen gemäß [RFC3275], [XMLDSig] angestoßen. Das zu verwendende Profil ist XAdES-BES ([XAdES]). Die Rückgabe einer solchen Signatur erfolgt als ds:Signature-Element. CMS-Signatur Durch Übergabe der URI urn:ietf:rfc:5652 wird eine CMS-Signatur gemäß [RFC5652] angestoßen. Das zu verwendende Profil ist CAdES-BES ([CAdES]).  Die Signatur wird als dss:Base64Signature mit der oben genannten URI als Type zurückgeliefert. S/MIME-Signatur Durch Übergabe der URI „urn:ietf:rfc:5751” wird eine S/MIME-Signatur gemäß [RFC5751] angestoßen. Die CMS-Signatur der übergebenen MIME-Nachricht erfolgt konform der Vorgaben zur CMS-Signatur. Das Rückgabedokument ist eine MIME-Nachricht vom Typ „application/pkcs7-mime“ mit einer CMS-Struktur vom Typ_SignedData. Ist das übergebene Dokument keine MIME-Nachricht, so wie der Fehler 4111 (Ungültiger Signaturtyp oder Signaturvariante) zurückgeliefert. PDF-Signatur Durch Übergabe der URI http://uri.etsi.org/02778/3 wird die Erzeugung einer PAdES-Basic Signatur gemäß [PAdES-3]angestoßen, wobei das Dokument mit der integrierten Signatur als dss:Base64Signature mit der oben genannten URI als Type zurückgeliefert wird. Handelt es sich beim übergebenen Dokument nicht um ein Base64Data-Element mit MIME-Type „application/pdf-a“, so wird ein Fehler 4111 (Ungültiger Signaturtyp oder Signaturvariante) zurückgeliefert. Andere SignatureType-Angaben führen zu einer Fehlermeldung 4111 (Ungültiger Signaturtyp oder Signaturvariante). Die Signaturtypen „XML-Signatur, CMS-Signatur, PDF-Signatur, S/MIME-Signatur“ DÜRFEN für QES der HBAx nur mit dem QES-Zertifikat erfolgen, für nonQES nur mit dem OSIG-Zertifikat der SM-B. In jedem diese Anforderung verletzenden Fall MUSS der Fehler 4058 (Aufruf nicht zulässig) zurückgeliefert werden. Fehlt dieses Element, so wird der Signaturtyp gemäß TAB_KON_583 – Default-Signaturverfahren aus dem Dokumententyp abgeleitet.
	dss: Properties		Durch dieses in [OASIS-DSS] (Abschnitt 3.5.5) definierte Element können zusätzliche signierte und unsignierte Eigenschaften (Properties) bzw. Attribute in die Signatur eingefügt werden. Unterstützt werden genau folgende Attribute: Im CMS-Fall (SignatureType = urn:ietf:rfc:5652) kann es XML-Elemente ./SignedProperties/Property/Value/CMSAttribute und ./UnsignedProperties/Property/Value /CMSAttribute enthalten. Ein solches XML-Element CMSAttribute muss ein vollständiges, base64/DER-kodiertes ASN.1-Attribute enthalten, definiert in [CMS#5.3.SignerInfo Type]. Es muss bei der Erstellung des CMS-Containers unverändert unter SignedAttributes bzw. UnsignedAttributes aufgenommen werden.
	SIG: Include EContent		Durch dieses in [OASIS-DSS] (Abschnitt 3.5.7), definierte Element kann bei einer CMS-basierten Signatur das Einfügen des signierten Dokumentes in die Signatur angefordert werden. Die Verwendung dieses Parameters bei anderen Signaturtypen führt zu einem Fehler 4111 (Ungültiger Signaturtyp oder Signaturvariante).
	SIG: Include Object		Dieses Element enthält zum Anfordern einer Enveloping XML Signatur ein dss:IncludeObject-Element gemäß [OASIS-DSS] (Abschnitt 3.5.6). Ist das Element vorhanden und ein anderer Signaturtyp als eine XML-Signatur angefordert, so wird der Fehler 4111 (Ungültiger Signaturtyp oder Signaturvariante) zurückgeliefert.
	dss: Signature Placement		Durch dieses in [OASIS-DSS] (Abschnitt 3.5.8) definierte Element kann bei XML-basierten Signaturen gemäß [RFC3275] die Platzierung der Signatur im Dokument angegeben werden. Die in [OASIS-DSS] (Abschnitt 2.5, XPath c) beschriebene Deklaration von Namespace-Prefixes im dss:SignaturePlacement-Element muss  nicht unterstützt werden.  Bei anderen Signaturtypen wird das Element ignoriert und eine Warnung (Fehlercode 4197, Parameter SignaturePlacement wurde ignoriert) zurückgeliefert.
	dss: Return Updated Signature		Durch dieses in [OASIS-DSS] (Abschnitt 4.5.8) definierte Element kann eine übergegebene XML- oder CMS-Signatur mit zusätzlichen Informationen und Signaturen (Parallel- und Gegensignaturen) versehen werden. Hierbei sind folgende Ausprägungen für das Type-Attribut vorgesehen: http://ws.gematik.de/conn/sig/sigupdate/parallel Hierdurch wird eine Parallelsignatur zu einer bereits existierenden Signatur erzeugt und entsprechend zurückgeliefert. http://ws.gematik.de/conn/sig/sigupdate/counter/ documentexcluding Hierdurch wird eine dokumentenexkludierende Gegensignatur für alle vorhandenen parallelen Signaturen erzeugt. Bei anderen Type-Attributen wird der Fehler 4111 (Ungültiger Signaturtyp oder Signaturvariante) zurückgeliefert.
	dss: Schemas		Durch das in [OASIS-DSS] (Abschnitt 2.8.5) definierte Element können eine Menge von XML-Schemata übergeben werden, die zur Validierung der übergebenen XML-Dokumente verwendet werden können.
	dss:Schema		Dieses Element enthält ein XML-Schema zur Validierung des übergebenen XML-Dokuments. Das Attribut RefURI ist verpflichtend. Es kennzeichnet dabei den Namensraum des XML-Schemas entsprechend [OASIS-DSS] (Abschnitt 2.8.5)
	sp: Generate Under Signature Policy		Über dieses in [OASIS-SP], Kapitel 2.2.1.1.1.1 Optional Input <GenerateUnderSignaturePolicy>, definierte Element wird die  erforderliche Singnaturrichlinie ausgewählt. Die im Element sp:SignaturePolicyIdentifier übergebene URI identifiziert die Signaturrichtlinie. Die XML-Elemente SignaturePolicyLocation DigestAndAlgorithm werden nicht verwendet. Wenn eine nach TAB_KON_778 notwendige Signaturrichtlinie fehlt oder die übergebene Signaturrichtlinie unbekannt ist, wird Fehler 4111 zurückgeliefert.
	SIG: Viewer Info		Enthält optional die vom Konnektor in die Signatur einzubeziehende Referenzen für die Stylesheets zur Anzeige.
Rückgabe
	SIG: Sign Response		Eine SignResponse kapselt den ausgeführten Signaturauftrag pro Dokument. Die Zuordnung zwischen SignRequest und SignResponse erfolgt über die RequestID.
	CONN: Status	Enthält den Status der ausgeführten Operation pro SignRequest.
	SIG: Optional Outputs	Enthält (angelehnt an dss:OptionalOutputs) optionale Ausgangsparameter:
	SIG: Document With Signature	Pro SignResponse wird ein Element SIG:DocumentWithSignature gemäß [OASIS-DSS] (Abschnitt 3.5.8) zurückgeliefert, in dem das Dokument mit Signatur enthalten ist. Dabei werden die XML-Attribute des Elements SIG:Document auf dem zugehörigen SignRequest übernommen. Ist die Signatur nicht im Dokument enthalten, wird ein leeres Element Base64XML oder Base64Data zurückgegeben. Die Signatur wird dann im Element dss:SignatureObject abgelegt. Wenn die Signatur im Dokument enthalten ist, wird das signierte Dokument im Feld Base64XML bzw. Base64Data zurückgeliefert. In diesem Fall MUSS die dss:SignaturePtr-Alternative in dss:SignatureObject (vgl. [OASIS-DSS] Abschnitt 2.5) dazu genutzt werden, auf die in den Dokumenten enthaltenen Signaturen zu verweisen.
	vr: Verifi cation Report	Vom Konnektor nicht befüllt.
	dss: Signature Object	Enthält im Erfolgsfall die erzeugte Signatur pro SignRequest in Form eines dss:SignatureObject-Elementes gemäß [OASIS-DSS] (Abschnitt 3.2).
Vorbe-dingungen	Keine
Nachbe-dingungen	Keine

Der Ablauf der Operation SignDocument ist in Tabelle TAB_KON_756 Ablauf Operation SignDocument (nonQES und QES) beschrieben:

Tabelle 17: TAB_KON_756 Ablauf Operation SignDocument (nonQES und QES)

Nr.	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Anhand des Kartentyps wird ermittelt, ob eine QES oder eine nonQES erzeugt werden soll. Alle übergebenen Parameterwerte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffs- berechtigung“	Die Prüfung erfolgt durch den Aufruf TUC_KON_000 {     mandantId = $context.mandantId;     clientsystemId  = $context.clientsystemId;     workplaceId = $context.workplaceId;     userId = $context.userId;     cardHandle = $cardHandle } Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
3.	TUC_KON_026 „Liefere CardSession“	Ermittle CardSession über TUC_KON_026 {     mandatId =$context.mandantId;     clientsystemId  = $context.clientsystemId;     cardHandle = $context.cardHandle;     userId = $context.userId }
Im Fall QES wird Schritt 4 ausgeführt. Im Fall nonQES wird Schritt 5 ausgeführt.
4a)	Prüfe Signaturdienst-Modul	Prüfe, ob MGM_LU_SAK=Enabled. Ist dies nicht der Fall, so bricht die Operation mit Fehler 4125 ab.
Wenn für die CardSession die Komfortsignatur aktiviert ist (CARDSESSION.SIGNMODE = Comfort) wird Schritt 4 c) ausgeführt. Andernfalls wird Schritt 4 b) ausgeführt.
4b)	TUC_KON_150 „Dokumente QES signieren“	Die QES wird erzeugt. Tritt hierbei ein Fehler auf, bricht die Operation ab.
4c)	TUC_KON_170 „Dokumente mit Komfort signieren“	Eine Komfortsignatur wird erzeugt. Tritt hierbei ein Fehler auf, bricht die Operation ab.
5)	TUC_KON_160 „Dokumente nonQES signieren“	Die nonQES wird erzeugt. Tritt hierbei ein Fehler auf, bricht die Operation ab.

Tabelle 18: TAB_KON_757 Fehlercodes „SignDocument (nonQES und QES)“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen TUCs können folgende weiteren Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
4111	Technical	Error	ungültiger Signaturtyp oder Signaturvariante
4126	Security	Error	Kartentyp nicht zulässig für Signatur
4125	Technical	Error	LU_SAK nicht aktiviert
4197	Technical	Warning	Parameter SignaturePlacement wurde ignoriert
4252	Technical	Error	Jobnummer wurde in den letzten 1.000 Aufrufen bereits verwendet und ist nicht zulässig

Die zulässigen Zertifikate und Schlüssel sind in TAB_KON_900 aufgelistet.
[<=]

4.1.8.5.2 ActivateComfortSignature (Kap. 4.1.8.5.5 - neu)

A_19107 - Operation ActivateComfortSignature

Der Signaturdienst des Konnektors MUSS an der Clientschnittstelle eine Operation ActivateComfortSignature anbieten.

Tabelle 19: TAB_KON_874 ActivateComfortSignature

Name	ActivateComfortSignature
Beschreibung	Diese Operation aktiviert die Komfortsignatur für einen HBA bezogen auf einen Aufrufkontext.
Aufrufparameter
	Name	Beschreibung
	CONN: Card Handle	Identifiziert die zu adressierende Karte. Es wird nur der HBA unterstützt.
	CCTX:Context	MandantId, ClientSystemId, WorkplaceId, UserId verpflichtend zu übergeben; MandantId, WorkplaceId nicht ausgewertet
Rückgabe
	CONN:Status	Enthält den Ausführungsstatus der Operation.
	SIG: SignatureMode	Signaturmodus des HBA Enthält bei erfolgreicher Ausführung der Operation den Wert „COMFORT“
Vorbedingungen	Keine
Nachbedingungen	Keine

Tabelle 20: TAB_KON_877 Ablauf ActivateComfortSignature

Nr.	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffsberechtigung“	Die Prüfung erfolgt durch den Aufruf TUC_KON_000 {     mandantId = $context.mandantId;     clientsystemId  = $context.clientsystemId;     workplaceId = $context.workplaceId;     userId = $context.userId;     cardHandle = $cardHandle } Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
3.	TUC_KON_026 „Liefere CardSession“	Ermittle CardSession über TUC_KON_026 {     mandatId =$context.mandantId;     clientsystemId  = $context.clientsystemId;     cardHandle = $context.cardHandle;     userId = $context.userId }
4.	TUC_KON_171 „Komfortsignatur einschalten“	Der Komfortsignaturmodus wird für das Tupel (CardHandle, CardSession) eingeschaltet. Tritt hierbei ein Fehler auf, bricht die Operation ab.

 

Tabelle 21: TAB_KON_879 Fehlercodes ActivateComfortSignature

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen TUCs können folgende weiteren Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
4270	Technical	Error	UserId wurde in den letzten 1.000 Vorgängen bereits verwendet
4272	Technical	Error	UserId nicht zulässig

[<=]

4.1.8.5.3 DeactivateComfortSignature (Kap. 4.1.8.5.6 - neu)

A_19108 - Operation DeactivateComfortSignature

Der Signaturdienst des Konnektors MUSS an der Clientschnittstelle eine Operation DeactivateComfortSignature anbieten.

Tabelle 22: TAB_KON_875 DeactivateComfortSignature

Name	DeactivateComfortSignature
Beschreibung	Diese Operation deaktiviert die Komfortsignatur für einen oder mehrere HBA.
Aufrufparameter
	Name		Beschreibung
	CONN: Card Handle		Identifiziert die zu adressierende Karte. Es wird nur der HBA unterstützt.
Rückgabe
	CONN:Status	Enthält den Ausführungsstatus der Operation.
Vorbedingungen	Keine
Nachbedingungen	Keine

Tabelle 23: TAB_KON_878 Ablauf DeactivateComfortSignature

Nr.	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_172 „Komfortsignatur ausschalten“	Der Komfortsignaturmodus wird für alle Karten aus der CardHandle-Liste ausgeschaltet.

 

Tabelle 24: TAB_KON_880 Fehlercodes DeactivateComfortSignature

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen TUCs können folgende weiteren Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler

[<=]

4.1.8.5.4 GetSignatureMode (Kap. 4.1.8.5.7 - neu)

A_19109-01 - Operation GetSignatureMode

Der Signaturdienst des Konnektors MUSS an der Clientschnittstelle eine Operation GetSignatureMode anbieten.

Tabelle 25: TAB_KON_876 GetSignatureMode

Name	GetSignatureMode
Beschreibung	Diese Operation liefert den aktuell konfigurierten Status der Komfortsignaturfunktion im Konnektor und, falls vorhanden, Informationen zu der aktuell im Konnektor existierenden Komfortsignatursession für das CardHandle und den Aufrufkontext.
Aufrufparameter
	Name		Beschreibung
	CONN:CardHandle		Identifiziert die zu adressierende Karte. Es wird nur der HBA unterstützt.
	CCTX:Context		MandantId, ClientSystemId, WorkplaceId, UserId verpflichtend zu übergeben
Rückgabe
	CONN:Status	Enthält den Ausführungsstatus der Operation.
	SIG: ComfortSignatureStatus	Komfortsignatur-Konfigurationsstatus des Konnektors
	SIG:ComfortSignatureMax	Im Konnektor konfigurierte Anzahl von Komfortsignaturen, die ohne erneute PIN-Eingabe ausgeführt werden dürfen
	SIG: ComfortSignatureTimer	Im Konnektor konfiguriertes Zeitintervall, in dem Komfortsignaturen ohne erneute PIN-Eingabe ausgeführt werden dürfen, Format: "PTnHnMnS" (gemäß Datenttyp xsd:duration)
	SIG:SessionInfo	Falls vorhanden, Informationen zu der aktuell im Konnektor existierenden Komfortsignatursession für das CardHandle und den Aufrufkontext
	SIG:SignatureMode	Signaturmodus der Komfortsignatursession (="Comfort")
	SIG:CountRemaining	Verbleibende Anzahl von Komfortsignaturen, die ohne erneute PIN-Eingabe ausgeführt werden dürfen
	SIG:TimeRemaining	Verbleibende Zeit, in der Komfortsignaturen ohne erneute PIN-Eingabe ausgeführt werden dürfen Format: "PTnHnMnS" (gemäß Datenttyp xsd:duration)
Vorbedingungen	Keine
Nachbedingungen	Keine

Tabelle 26: TAB_KON_882 Ablauf GetSignatureMode

Nr.	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffsberechtigung“	Die Prüfung erfolgt durch den Aufruf TUC_KON_000 {     mandantId = $context.mandantId;     clientsystemId  = $context.clientsystemId;     workplaceId = $context.workplaceId;     userId = $context.userId;     cardHandle = $cardHandle } Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
3.	TUC_KON_026 „Liefere CardSession“	Ermittle CardSession über TUC_KON_026 {     mandatId =$context.mandantId;     clientsystemId  = $context.clientsystemId;     cardHandle = $context.cardHandle;     userId = $context.userId }
4.	TUC_KON_173 „Liefere Signaturmodus“	Der Komfortsignatur-Konfigurationsstatus des Konnektors und der im Konnektor hinterlegte Signaturmodus werden für den dem Konnektor bekannten Aufrufkontext des HBA aus dem übergebenen CardHandle zurück geliefert.

 

Tabelle 27: TAB_KON_881 Fehlercodes GetSignatureMode

Fehlercode	ErrorType	Severity	Fehlertext
Folgende Fehlercodes können auftreten:
4000	Technical	Error	Syntaxfehler

[<=]

4.1.8.6 Betriebsaspekte (Kap 8.1.8.6)

5 Anhang D – Übersicht über die verwendeten Versionen

[konsolidierte Übersicht der zu unterstützenden Versionen von SignatureService für den PTV4Plus Komfortsignatur]

Tabelle 29: TAB_KON_688 Version der Schemas aus dem Namensraum des Konnektors

Tabelle 30: TAB_KON_798 Schnittstellenversionen