Version

1.01.0

Revision

548770

Stand

05.11.202007.04.2021

Status

freigegeben

Klassifizierung

öffentlich

Referenzierung

gemSpec_Kon_KomfSig

Fehlercode

ErrorType

Severity

Fehlertext

4002

Security

Fatal

Der Konnektor befindet sich in einem kritischen Betriebszustand

ReferenzID

Belegung

Zustandswerte

CM_CARD_LIST

Liste von Card-Objekten

Eine Liste von Repräsentanzen (CardObjects) der dem Konnektor bekannten Karten.
Die Attribute der Card-Objekte sind im Folgenden gelistet.

CARD.CARDHANDLE

vom Konnektor vergebenen eindeutigen Identifikator (Handle).

CARD.CTID

Kartenterminal, in dem die Karte steckt

CARD.SLOTNO

Slot, in dem die Karte steckt

CARD.ICCSN

ICCSN der Karte (sofern auslesbar),

CARD.TYPE

Typ der Karte gemäß Tabelle TAB_KON_500 Wertetabelle Kartentypen

CARD.CARDVERSION

die Versionsinformationen zum Produkttyp der Karte und den gespeicherten Datenstrukturen gemäß [gemSpec_Karten_Fach_TIP].

CARD.CARDVERSION.
COSVERSION

Produkttypversion des COS

CARD.CARDVERSION.
OBJECTSYSTEMVERSION

Produkttypversion des Objektsystems

CARD.CARDVERSION.
CARDPTPERSVERSION

Produkttypversion der Karte bei Personalisierung

CARD.CARDVERSION.
DATASTRUCTUREVERSION

Version der Speicherstrukturen (aus EF.Version)

CARD.CARDVERSION.
LOGGINGVERSION

Version der Befüllvorschrift für EF.Logging

CARD.CARDVERSION.
ATRVERSION

Version der Befüllvorschrift für EF.ATR

CARD.CARDVERSION.
GDOVERSION

Version der Befüllvorschrift für EF.GDO

CARD.CARDVERSION.
KEYINFOVERSION

Version der Befüllvorschrift für KeyInfo

CARD.INSERTTIME

Timestamp

Zeitpunkt, an dem die Karte gesteckt wurde

CARD.CARDHOLDERNAME

String

Name des Karteninhabers bzw. der Institution/Organisation (subject.commonName)

CARD.KVNR

String

Versicherten-ID (unveränderbarer Teil der KVNR)

CARD.
CERTEXPIRATIONDATE

Ablaufdatum des AUT-Zertifikats der Karte

CARD.CARDSESSION_
LIST

Liste von CardSession-Objekten

Eine Liste von Repräsentanzen (CardSession-Objects) der pro Karte vorhandenen Kartensitzungen.
Die Attribute der CardSession-Objekte sind im Folgenden gelistet.
Das Tripel aus MandantID, CSID und UserID bildet den Kontext ab, in welchem diese Kartensitzung initiiert wurde.

CARDSESSION.
AUTHSTATE

Liste von Einträgen aus a)C2C:KeyRef, Role
oder
b) CHV: PINRef

Liste von erreichten Sicherheitszuständen.
Jeder einzelne Sicherheitszustand kann entweder über C2C gegen KeyRef (mit einer bestimmten Rolle gemäß [gemSpec_PKI_TI#Tab_PKI_918]) oder Card Holder Verification (CHV) gegen eine referenzierte PIN erreicht worden sein.
Für eGK G2.0 wird der Zustand der MRPINs nicht in AuthState gespeichert.

CARDSESSION.
MANDANTID

Mandant-ID

CARDSESSION.CSID

Clientsystem-ID

CARDSESSION.USERID

Nutzer-ID

CARDSESSION.AUTHBY

Referenz auf CardSession

Kartensitzung, über die diese Karte freigeschaltet wurde (nur für eGK belegt)

CARDSESSION.
SIGNMODE

„PIN“ oder
„Comfort“

Signaturmodus
„PIN“: Komfortsignaturmodus ist für die Karte ausgeschaltet
"Comfort“: Komfortsignaturmodus ist eingeschaltet
Default-Wert=“PIN“
Nur relevant für den HBA

Karte/
Kontext

PIN-Referenz

I/O

Terminal-Anzeige

ANW
(max.Anz. Zeichen)

eGK
/PIN-Eingabe für Vertreter-PIN

PIN.AMTS_REP

I

Vertreter-PIN•0x0Bfür•0x0BANW
0x0FVertr-PIN:

22

eGK
/PIN-Eingabe für Vertreter-PIN ändern

PIN.AMTS_REP

I

Vertreter-PIN•0x0Bändern
0x0FPIN.eGK:

eGK
/PIN-Eingabe für Vertreter-PIN entsperren

PIN.AMTS_REP

I

Vertreter-PIN•0x0entsperren
0x0FPIN.eGK:

eGK
/PIN-Eingabe für PIN-Schutz einschalten

MRPIN.NFD, MRPIN.DPE, MRPIN.AMTS,
MRPIN.GDD

I

PIN-Schutz•0x0BANW•0x0Beinschalten
0x0FPIN.eGK:

16

eGK
/PIN-Eingabe für PIN-Schutz abschalten

MRPIN.NFD, MRPIN.DPE, MRPIN.AMTS,
MRPIN.GDD

I

PIN-Schutz•0x0BANW•0x0Babschalten
0x0FPIN.eGK:
 

16

eGK
/Sonstige

ALLE (außer PIN.AMTS_REP)

I

PIN•0x0Bfür•0x0BANW
0x0FPIN.eGK:

32

HBAx

PIN.CH

I

Eingabe•0x0BFreigabe-PIN•0x0BHBA
0x0FPIN.HBA:

PIN.QES
(Signatur auslösen)

I

#UVW-XYZ•0x0BEingabe•0x0BSignatur- PIN•0x0BHBA
0x0FPIN.QES:

HBA

PIN.QES (Komfortsignatur aktivieren)

I

Komfortsignatur•0x0Baktivieren•0x0BHBA
 0x0FPIN.QES:

SMC-B
 

PIN.SMC

I

Eingabe•0x0BPIN•SMC-B•0x0BSLOT:X
0x0FPIN.SMC:

ANDERE

BELIEBIG

I

        Herstellerspezifisch

Erfolgreiche PIN-Eingabe

ALLE

O

PIN•0x0Berfolgreich•0x0Bverifiziert!

Fehlerhafte PIN-Eingabe

ALLE

O

PIN•0x0Bfalsch•0x0Boder•0x0Bgesperrt!

PUK-Eingabe

eGK
PUK.CH

I

Eingabe•0x0BVersicherten-0x0BPUK
0x0FPUK.eGK:

HBAx
PUK.CH

I

Eingabe•0x0BFreigabe-PUK•0x0BHBA
0x0FPUK.HBA:

HBAx
PUK.QES

I

Eingabe•0x0BSignatur-PUK•0x0BHBA
0x0FPUK.QES:

SMC-B
PUK.SMC

I

Eingabe•0x0BPUK•SMC-B•0x0BSLOT:X
0x0FPUK.SMC:

Erfolgreiche PUK-Eingabe

ALLE

O

PIN•0x0Berfolgreich•0x0Bentsperrt!

Fehlerhafte PUK-Eingabe

ALLE

O

PUK•0x0Bfalsch•0x0Boder•0x0Bgesperrt!

Eingabe einer neuen PIN

eGK
ALLE (außer PIN.AMTS_REP)

I

Eingabe•
0x0Bneue•0x0BVersicherten-0x0BPIN•
0x0B(6-8•Ziffern)
0x0FPIN.eGK:

eGK
PIN.AMTS_REP

I

Eingabe•
0x0Bneue•0x0BVertreter-PIN•
0x0B(6-8•Ziffern)
0x0FVertr-PIN:

HBAx
PIN.CH

I

Eingabe•0x0Bneue•0x0BFreigabe-PIN•0x0BHBA•0x0B(6-8•Ziffern)
0x0FPIN.HBA:

HBAx
PIN.QES

I

Eingabe•
0x0Bneue•0x0BSignatur-PIN•0x0BHBA•0x0B(6-8•Ziffern)
0x0FPIN.QES:

SMC-B
PIN.SMC

I

Eingabe•0x0Bneue•0x0BPIN•SMC-B•
0x0BSLOT:X•0x0B(6-8•Ziffern)
0x0FPIN.SMC:

Eingabe einer Transport-PIN

eGK
PIN.CH

I

Eingabe•0x0BTransport-0x0BVersicherten-0x0BPIN
0x0FT-PIN.eGK:

HBAx
PIN.CH

I

Eingabe•0x0BTransport-0x0BPIN•0x0BHBA
0x0FT-PIN.HBA:

HBAx
PIN.QES

I

Eingabe•0x0BTransport-0x0BPIN•0x0BHBA
0x0FT-PIN.QES:

SMC-B
PIN.SMC

I

Eingabe•0x0BTransport-0x0BPIN•SMC-B•0x0BSLOT:X
0x0FT-PIN.SMC:

Wieder-holung einer neuen PIN

eGK
PIN.CH

I

Eingabe•0x0BVersicherten-0x0BPIN•0x0B
wiederholen!
0x0FPIN.eGK:

eGK
PIN.AMTS_REP

I

Eingabe•
0x0Bneue•0x0BVertreter-PIN•
0x0B wiederholen!
0x0FVertr-PIN:

HBAx
PIN.CH

I

Eingabe•0x0Bfür•HBA•0x0Bwiederholen!
0x0FPIN.HBA:

HBAx
PIN.QES

I

Eingabe•0x0Bfür•HBA•0x0Bwiederholen!
0x0FPIN.QES:

SMC-B
PIN.SMC

I

Eingabe•0x0BPIN.SMC•0x0BSLOT:X• 0x0Bwiederholen!
0x0FPIN.SMC:

Ungleichheit bei der Wieder-holung der Eingabe der neuen PIN

ALLE

O

PINs•0x0B nicht•0x0Bidentisch!•0x0BAbbruch!

Erfolgreiche PIN-Änderung

ALLE

O

PIN•0x0Berfolgreich•0x0Bgeändert!

Anzeigen am lokalen Terminal beim Remote-PIN-Verfahren für das Ergebnis der Verschlüsselung durch die gSMC-KT

Erfolgreiche Verschlüsselung

ALLE

O

Eingabe•0x0Bwird•0x0Bbearbeitet.

Fehler bei der Verschlüsselung

ALLE

O

Eingabe•0x0Bfehlgeschlagen.

Element

Beschreibung

Name

TUC_KON_158 „Komfortsignaturen erstellen“

Beschreibung

 

Die Data To Be Signed (DTBS) werden erzeugt, an die Signaturkarte gesendet und dort signiert.
Die Übertragung der DTBS erfolgt mit Secure Messaging.
Die Abarbeitung der Signatur erfolgt im SE#2.

Auslöser

TUC_KON_170 „Dokumente mit Komfort signieren“

Vorbedingungen

 

Die Ressource Signaturkarte ist für den Vorgang reserviert.
DF.QES ist selektiert.
PIN.QES ist initial verifiziert

Eingangsdaten

 

·         Zu signierendes Dokument bzw. zu signierende Dokumente

·         cardSession (nur HBA erlaubt)

·         zu verwendende Identität (Zertifikatsreferenz)

·         crypt [SIG_CRYPT_QES] - optional ;
default und  Wertebereich: siehe TAB_KON_862-01
(Dieser Parameter steuert, ob RSA-basierte oder ECC-basierte Signaturen erzeugt werden.)

·         WorkplaceId

Komponenten

Konnektor, Kartenterminal, Signaturkarte (HBA)

Ausgangsdaten

·         Signierte Dokumente

Standardablauf

 

1.    Wenn noch nicht erfolgt, wird basierend auf SAK.AUTD_CVC und HPC.AUTD_SUK_CVC und den zugehörigen privaten Schlüsseln ein sicherer Kanal zwischen der gSMC-K des Konnektors und dem HBA aufgebaut mittels Aufruf TUC_KON_005 „Card-to-Card authentisieren“ {  
     sourceCardSession = gSMC-K;
     targetCardSession = CardSession;
     authMode = „gegenseitig+TC“}

Die folgenden Schritte werden für jedes Dokument des Stapels durchgeführt.

2.    Das zu signierende Dokument wird, soweit noch nicht erfolgt, für die Signatur gemäß des entsprechenden Formats vorbereitet. Ein Ergebnis dieser Vorbereitung sind die Data To Be Signed (DTBS): der Hash-Wert (Digest des SignedInfo-Elementes), der zur Signatur an die Karte gesendet werden soll.

3.    Es wird geprüft, ob der Komfortsignatur-Zähler der cardSession den Wert SAK_COMFORT_SIGNATURE_MAX überschritten hat .

4.    Es wird geprüft, ob der Komfortsignatur-Timer der cardSession (SAK_COMFORT_SIGNATURE_TIMER) abgelaufen ist. 

54.    Für das zu signierende Dokument werden die DTBS zur Signatur im sicheren Kanal an den HBA übermittelt (Aufruf TUC_KON_218 „Signiere“). Dabei werden der Schlüssel und der Algorithmusidentifier über die Tabelle TAB_KON_900 bestimmt.

65.    Der Komfortsignatur-Zähler der cardSession wird um 1 erhöht.

76.    Die erstellte Signatur wird mathematisch geprüft.

87.    Der ermittelte Signaturwert wird in den zuvor vorbereiteten Signaturprototypen eingefügt.

98.    Der Konnektor löst TUC_KON_256 {"SIG/SIGNDOC/NEXT_SUCCESSFUL"; Op; Info; „$Jobnummer"; noLog; $doInformClients } aus.

Varianten/
Alternatien

Keine


 

Fehlerfälle

 

In den Fehlerfällen, die zum Abbruch des Komfortsignaturmodus mit Fehlercode 4271 führen, wird vor dem Abbruch TUC_KON_172 für das cardHandle des HBA ausgeführt.
(->3) Der Komfortsignatur-Zähler der cardSession hat den Maximalwert überschritten: Fehlercode 4271
(->4) Der Komfortsignatur-Timer der cardSession ist abgelaufen: Fehlercode 4271
(->5

(->4) Der PIN.QES-Nutzungszähler der Karte ist abgelaufen (erkennbar z. B. daran, dass die Karte einen Autorisierungsfehler zurückmeldet): Fehlercode 4271
(->54) Fehler im Signaturvorgang führen zum Abbruch des gesamten Signaturvorgangs: Fehlercode 4123
(->76) Fehler in mathematischer Prüfung der Signatur führen zum Abbruch des Signaturvorgangs: Fehlercode 4120
Das weitere Verhalten des TUCs bei einem Fehlerfall oder beim Abbruch durch den Benutzer ist in TAB_KON_192, Verhalten des Konnektors beim Abbruch einer Stapelsignatur, beschrieben.

Sicherheitsanforderungen

 

Zum Aufbau des sicheren Kanals bzw. zur Aushandlung des symmetrischen Schlüssels DARF DF.QES NICHT verlassen werden. Benötigte CVCs des HBA MÜSSEN also bereits vor dem Signaturvorgang eingelesen und gecached werden. Dies KANN bereits beim Stecken des HBA geschehen.
Komfortsignaturen MÜSSEN im SE#2 abgearbeitet werden.
Die in [gemSpec_Krypt] angegebenen Festlegungen der zu unterstützenden Algorithmen MÜSSEN berücksichtigt werden.

Fehlercode

ErrorType

Severity

Fehlertext

Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:

4120

Security

Error

Kartenfehler

4123

Security

Error

Fehler bei Signaturerstellung

4271

Technical

Error

Komfortsignaturmodus abgebrochen

Element

Beschreibung

Name

TUC_KON_170 ”Dokumente mit Komfort signieren”

Beschreibung

Im Rahmen von Fachanwendungen werden ein oder mehrere Dokumente mit einer Komfortsignatur versehen. Es werden die QES_DocFormate unterstützt.

Auslöser

 

Aufruf durch ein Clientsystem (Operation SignDocument) oder ein Fachmodul.

Vorbedingungen

Die Signaturkarte muss gesteckt sein.

Eingangsdaten


 

·         signRequests
(Liste von Signaturaufträgen)
Jeder Signaturauftrag (SignRequest) kapselt:

•       documentsToBeSigned
(Zu signierendes Dokument bzw. zu signierende Dokumente);
darin u.a.
documentFormat
(Formatangabe für das zu signierende Dokument)

•       optionalInputs
(weitere optionale Eingabeparameter zur Steuerung der Details bei der zu erstellenden Signatur, siehe Operation SignDocument, Parameter dss:OptionalInputs); darin u.a. signatureType (URI für den Signaturtyp  XML-, CMS-, PDF-Signatur)

•       includeRevocationInfo [Boolean]: – optional; Default: true
(Dieser optionale Parameter steuert die Einbettung von OCSP Antworten in die Signatur; siehe Operation SignDocument, Parameter SIG:IncludeRevocationInfo)

·         cardSession
(Kartensitzung. Unterstützte Kartentypen: HBA)

·         crypt [SIG_CRYPT_QES] - optional ;
default und Wertebereich: siehe TAB_KON_862-01
(Dieser Parameter steuert, ob RSA-basierte oder ECC-basierte Signaturen erzeugt werden.)

·         workplaceId

Komponenten

Konnektor, Kartenterminal, Signaturkarte (HBA)

Ausgangsdaten

 

·         signedDocuments
(Liste der signierten Dokumente)

Standardablauf


 

Der Konnektor KANN die Schritte 1 bis 45 in einer beliebigen Reihenfolge durchführen.

1.    Prüfe SAK_COMFORT_SIGNATURE = Enabled
2. Prüfe, ob der Komfortsignatur-Timer der cardSession (SAK_COMFORT_SIGNATURE_TIMER) abgelaufen ist.   

23.    Der Signaturtyp und die Signaturvariante werden für jedes Dokument der Liste entsprechend signatureType und SignatureVariant festgelegt (ggf. in optionalInputs enthalten). Wenn SignatureType oder SignatureVariant nicht übergeben wurden, wird das dem Dokumentformat entsprechende Default-Verfahren gewählt (siehe TAB_KON_583 – Default-Signaturverfahren).

34.    Für alle Dokumente des Stapels wird die Zulässigkeit des Kartentyps geprüft. Das für die Signatur zu nutzende Zertifikat wird anhand des Kartentyps und des Parameters crypt ausgewählt.

45.    Es werden die Voraussetzungen für die Signatur geprüft. Dies erfolgt im TUC_KON_152 „Signaturvoraussetzungen für QES prüfen“.
Wenn includeRevocationInfo=true, dann setze ocspResponses auf Rückgabewert von TUC_KON_152.

56.    Die am Signaturvorgang beteiligte RessourceSignaturkarte wird für die exklusive Nutzung durch diesen Signaturvorgang reserviert. Die Reservierung der Signaturkarte erfolgt durch Aufruf von
TUC_KON_023 „Karte reservieren“ {
    cardSession;
    doLock = true }.

67.    Zum Vorbereiten der Dokumente für die Signatur wird TUC_KON_155 „Dokumente zur Signatur vorbereiten“ mit ocspResponses aufgerufen.

Die Zugriffe auf die Signaturkarte im Schritt 78 müssen im DF.QES erfolgen. DF.QES darf am Ende des TUCs nicht verlassen werden.

78.    Die Signaturen werden erstellt. Dies erfolgt gemäß TUC_KON_158 „Komfortsignaturen erstellen“.

89.    Die reservierte Ressource Signaturkarte wird wieder freigegeben. Zur Freigabe der Signaturkarte wird TUC_KON_023 „Karte reservieren“ 
   cardSession;
   doLock = false }
aufgerufen.

910.    Die signierten Dokumente werden an den Aufrufer zurückgegeben.

Varianten/
Alternativen

keine

Fehlerfälle


 

Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes:
(->1) Komfortsignaturfunktion im Konnektor nicht aktiviert: Fehlercode 4263
(->2) Der Komfortsignatur-Timer der cardSession ist abgelaufen: Fehlercode 4271
(->3) Ungültige Angabe des Signaturtyps oder Signaturvariante:
         Fehlercode 4111
         Übergabe eines für die QES nicht unterstützten Dokumentformats:
         Fehlercode 4110
(->34) Kartentyp nicht zulässig für Signatur: Fehlercode 4126
(->56) Fehler bei der Reservierung der Signaturkarte: Fehlercode 4060
(->78) Karte ist kein HBA, sondern HBA-Vorläuferkarte: Fehlercode 4274


Im Fehlerfall:
 a)      … DARF DF.QES NICHT verlassen werden
 b)      … MÜSSEN alle reservierten Ressourcen freigegeben werden
 c)      … MUSS der Fehler immer an das Clientsystem zurückgemeldet
    werden

Sicherheits-anforderungen

Der Konnektor MUSS sicherstellen, dass der erhöhte Sicherheitszustand der PIN.QES nur für die Komfortsignatur mittels TUC_KON_170 innerhalb einer Kartensitzung nachgenutzt werden darf.

Fehlercode

ErrorType

Severity

Fehlertext

Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:

4060

Technical

Error

Ressource belegt

4110

Technical

Error

ungültiges Dokumentformat (%Format%)
Der Parameter Format enthält das übergebene Dokumentformat.

4111

Technical

Error

ungültiger Signaturtyp oder Signaturvariante

4126

Security

Error

Kartentyp nicht zulässig für Signatur

4049

Technical

Error

Abbruch durch den Benutzer

4263

Technical

Error

Komfortsignaturfunktion nicht aktiviert

4271

Technical

Error

Komfortsignaturmodus abgebrochen

4274

Technical

Error

Komfortsignaturen werden nur für den HBA unterstützt

Element

Beschreibung

Name

TUC_KON_171 „Komfortsignatur einschalten“

Beschreibung

 

Zum Einschalten des Komfortsignaturmodus wird die PIN.QES verifiziert und der Signaturmodus „Comfort“ für die cardSession gesetzt.

Auslöser

 

·         Operation ActivateComfortSignature

·         Aufruf durch ein Fachmodul

Vorbedingungen

Der Karte muss gesteckt sein.

Eingangsdaten

·         cardSession (nur HBA erlaubt)

Komponenten

Konnektor, Kartenterminal, Karte (HBA)

Ausgangsdaten

·         signatureMode

Standardablauf

 

1.    Prüfe SAK_COMFORT_SIGNATURE = Enabled

2.    Die am Vorgang beteiligten Ressourcen (Karte sowie PIN-Pad und Display des PIN-Eingabe-Kartenterminals) werden für die exklusive Nutzung durch diesen Vorgang reserviert. Die Reservierung der Karte erfolgt durch Aufruf von
TUC_KON_023 „Karte reservieren“ {
    cardSession;
    doLock = true }

Der Zugriff auf die Karte im Schritt 3 muss im DF.QES erfolgen. Das DF.QES darf danach nicht verlassen werden, damit der PIN-Status der PIN.QES erhalten bleibt.

3.    Die Einschaltung der Komfortsignatur wird durch den Anwender autorisiert. Dies erfolgt durch Aufruf von TUC_KON_012 „PIN verifizieren“ { cardSession;
workplaceId;
pinRef = PIN.QES;
verificationType = Mandatorisch }
Für die Anzeige am Kartenterminal ist die Displaymessage für „Komfortsignatur aktivieren“ aus TAB_KON_090 zu verwenden.

4.    Setze CARDSESSION.SIGNMODE = Comfort

5.    Starte Komfortsignatur-Timer für die cardSession bei „0“

6.    Die reservierten Ressourcen (Karte sowie PIN-Pad und
Display des PIN-Eingabe-Kartenterminals) werden wieder freigegeben.
Zur Freigabe der Karte wird TUC_KON_023 „Karte reservieren“ 
   cardSession;
   doLock = false }
aufgerufen.

Varianten/
Alternativen

Keine

Fehlerfälle

 

Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes:
(->1) Komfortsignaturfunktion im Konnektor nicht aktiviert: Fehlercode 4263
(->2) Fehler bei der Reservierung von Ressourcen: Fehlercode 4060
(->3) Karte ist kein HBA, sondern HBA-Vorläuferkarte: Fehlercode 4274
(->3) pinResult = BLOCKED: Fehlercode 4275
(->3) pinResult = REJECTED: Fehlercode 4276
(->4) Fehler beim Setzen des Signaturmodus: Fehlercode 4267
(->5) Fehler beim Starten des Komfortsignatur-Timers: Fehlercode 4267
Im Fehlerfall, inklusive Timeout bei der PIN-Eingabe, oder bei Abbruch durch den Benutzer (Fehler 4049):
 a)      … MUSS (ab Schritt 3) DF.QES verlassen werden
 b)      … MÜSSEN alle reservierten Ressourcen freigegeben werden
 c)      … MUSS der Fehler immer an das Clientsystem zurückgemeldet werden

Fehlercode

ErrorType

Severity

Fehlertext

Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:

4049

Technical

Error

Abbruch durch den Benutzer

4060

Technical

Error

Ressource belegt

4263

Technical

Error

Komfortsignaturfunktion nicht aktiviert

4267

Technical

Error

Fehler beim Aktivieren des Komfortsignaturmodus <cardHandle>

4274

Technical

Error

Komfortsignaturen werden nur für den HBA unterstützt

4275

Technical

Error

Security Error PIN jetzt gesperrt (BLOCKED)

4276

Technical

Error

Security Error PIN falsch (REJECTED)

Element

Beschreibung

Name

TUC_KON_172 „Komfortsignatur ausschalten“

Beschreibung

 

Zum Ausschalten des Komfortsignaturmodus werden die Sicherheitszustände der Karte(n), die im Konnektor verwalteten Sicherheitszustände und der Signaturmodus der cardSession(s) zurückgesetzt.

Auslöser

 

·         Operation DeactivateComfortSignature

·         TUC_KON_158

·         Der Administrator setzt SAK_COMFORT_SIGNATURE = Disabled

·         Aufruf durch ein Fachmodul

Vorbedingungen

Die Karten müssen gesteckt sein.

Eingangsdaten

 

Bei Auslösen des TUCs durch den Administrator:

·         Keine

Ansonsten:

·         cardHandles : Liste von cardHandles (nur HBA erlaubt)

Komponenten

Konnektor, Kartenterminal, Karte (HBA)

Ausgangsdaten

Keine

Standardablauf

 

1.    Wenn der TUC nicht durch den Administrator ausgelöst wurde:
Prüfe SAK_COMFORT_SIGNATURE = Enabled

2.    Wenn der TUC durch den Administrator ausgelöst wurde: Ermittle die cardHandles aller gesteckten HBA.

3.    Für jedes übergebene bzw. ermittelte cardHandle:

4.    Ermittle cardSessions zu cardHandle

5.    Für jede ermittelte cardSession:

a.    Setze den PIN-Status der PIN.QES zurück (z. B. durch Verlassen von DF.QES für alle logischen Kanäle der Karte)

b.    Lösche den im Konnektor verwalteten Sicherheitszustand aus CARDSESSION.AUTHSTATE (PINRef=PIN.QES)

c.    Setze CARDSESSION.SIGNMODE = PIN

d.    Stoppe Komfortsignatur-Timer für die cardSession

Varianten/
Alternativen

Keine

Fehlerfälle


 

(->1) Komfortsignaturfunktion im Konnektor nicht aktiviert: Fehlercode 4263
Fehler und Warnungen in den folgenden Schritten werden über alle cardHandle akkumuliert und die <komma-separierte Liste von cardHandle> für den jeweiligen Fehlertext erzeugt.
(->3) Bei einem ungültigen cardHandle wird mit dem nächsten cardHandle aus cardHandles fortgesetzt. Fehlercode 4265
(->4) Ist zu einem cardHandle keine cardSession vorhanden wird mit dem nächsten cardHandle fortgesetzt. Fehlercode 4266
(->5) Tritt in Schritt 4 ein Fehler auf wird mit dem nächsten cardHandle fortgesetzt. Fehlercode 4268

Fehlercode

ErrorType

Severity

Fehlertext

4263

Technical

Fehler

Komfortsignaturfunktion nicht aktiviert

4265

Technical

Warning

Karten-Handle ungültig <komma-separierte Liste von cardHandle>

4266

Technical

Warning

Keine Kartensitzung vorhanden <komma-separierte Liste von cardHandle>

4268

Technical

Fehler

Fehler beim Deaktivieren des Komfortsignaturmodus <komma-separierte Liste von cardHandle>

Element

Beschreibung

Name

TUC_KON_173 „Liefere Signaturmodus“

Beschreibung

 

Der aktuell konfigurierte Status der Komfortsignaturfunktion im Konnektor und der aktuelle Signaturmodus für alle dem Konnektor bekannten Aufrufkontexte zu den übergebenen HBA-CardHandles wird, falls vorhanden, Informationen
zu der aktuell im Konnektor existierenden Komfortsignatursession werden ermittelt und an den Aufrufer zurückgegeben.

Auslöser

 

·         Operation GetSignatureMode

·         Aufruf durch ein Fachmodul

Vorbedingungen

Keine

Eingangsdaten

·         Liste von cardHandles (nur HBA erlaubt  cardSession 
(Kartensitzung. Unterstützte Kartentypen: HBA)

Komponenten

Konnektor, Kartenterminal, Signaturkarte (HBA)

Ausgangsdaten

 

·         comfortSignatureStatus

·         comfortSignatureMax

·         comfortSignatureTimer

·         signatureModessessionInfo (optional): Struktur aus

•      Liste von cardHandles (nur HBA erlaubt)

•      Liste von Tupeln (signatureContext, signatureMode, countRemaining, timeRemaining)

Standardablauf

 

1. Ermittle den Status der Komfortsignaturfunktion: comfortSignatureStatus=SAK_COMFORT_SIGNATURE
2. Ermittle comfortSignatureMax= SAK_COMFORT_SIGNATURE_MAX
3. Ermittle comfortSignatureTimer= SAK_COMFORT_SIGNATURE_Timer

4.   Für jedes übergebene cardHandle:

4. Ermittle cardSession zu cardHandlesessionInfo

2.   Für jede ermittelte cardSession:

                                         i.    Ermittle den Kontext (signatureContext) der cardSession aus
CARDSESSION.MANDANTID,
CARDSESSION.CSID, CARDSESSION.USERID

1.                                         ii.    Ermittle den Signaturmodus (signatureMode) aus CARDSESSION.SIGNMODE
2.                                        iii.    Ermittle Differenz von SAK_COMFORT_SIGNATURE_MAX und Komfortsignatur-Zähler der cardSession (countRemaining)
    
   3.                                        iv.    Ermittle verbleibende Zeit aus SAK_COMFORT_SIGNATURE_TIMER und Komfortsignatur-Timer der cardSession (timeRemaining)
       
3. Wenn signatureMode = "Comfort" wird sessionInfo an den Aufrufer zurückgegeben.

Varianten/
Alternativen

Wenn SAK_COMFORT_SIGNATURE = Disabled
(->4 b iii) countRemaining = 0
(->4 b iv) timeRemaining = 0Keine

Fehlerfälle

 

(->2) Bei einem ungültigen cardHandle wird mit dem nächsten cardHandle aus cardHandles fortgesetzt. Fehlercode 4265
(->2a) Ist zu einem cardHandle keine cardSession vorhanden wird mit dem nächsten cardHandle fortgesetzt. Fehlercode 4266
(->2b) Tritt in Schritt 2b ein Fehler auf wird mit dem nächsten cardHandle fortgesetzt. Fehlercode 4269
Die Fehler und Warnungen werden über alle cardHandle akkumuliert und die <komma-separierte Liste von cardHandle> für den jeweiligen Fehlertext erzeugtWenn im Standardablauf ein Fehler auftritt, wird mit Fehler 4269 abgebrochen.

Fehlercode

ErrorType

Severity

Fehlertext

4265

Technical

Warning

Karten-Handle ungültig <komma-separierte Liste von cardHandle>

4266

Technical

Warning

Keine Kartensitzung vorhanden <komma-separierte Liste von cardHandle>

4269

Technical

Error

Fehler beim Ermitteln des Signaturmodus <komma-separierte Liste von cardHandle>

Name

SignatureService

Version (KDV)

7.4.0 (WSDL-Version), 7.4.2 (XSD-Version)
7.4.2 (WSDL-Version), 7.4.4 (XSD-Version)
7.5.25 (WSDL- und XSD-Version)
Siehe Anhang D

Namensraum

Siehe Anhang D

Namensraum-Kürzel

SIG für Schema und SIGW für WSDL

Operationen

Name

Kurzbeschreibung

SignDocument

Dokument signieren

VerifyDocument

Signatur verifizieren

StopSignature

Signieren eines Dokumentenstapels abbrechen

GetJobNumber

Liefert eine Jobnummer für den nächsten Signiervorgang

ActivateComfortSignature

Aktiviert die Komfortsignatur für einen HBA

DeactivateComfortSignature

Deaktiviert die Komfortsignatur für einen oder mehrere HBA

GetSignatureMode

Liefert den Status der Komfortsignaturfunktion und den Signaturmodus für einen oder mehrereInformationen zur Komfortsignatursession eines HBA

WSDL

SignatureService_V7_5_25.wsdl
SignatureService_V7_4_2.wsdl
SignatureService.wsdl (WSDL-Version 7.4.0)

Schema

SignatureService_V7_5_25.xsd
SignatureService_V7_4_4.xsd
SignatureService.xsd (XSD-Version 7.4.2)

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

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

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.

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

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

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.

Fehlercode

ErrorType

Severity

Fehlertext

Neben den Fehlercodes der aufgerufenen TUCs können folgende weiteren Fehlercodes auftreten:

4000

Technical

Error

Syntaxfehler

Name

GetSignatureMode

Beschreibung

Diese Operation liefert den aktuell konfigurierten Status der Komfortsignaturfunktion im Konnektor und die im Konnektor aktuell hinterlegten Signaturmodus zu allen HBA aus der übergebenen CardHandle-Liste, falls vorhanden, Informationen
zu der aktuell im Konnektor existierenden Komfortsignatursession für das CardHandle und den Aufrufkontext.

Aufrufparameter

 

Name

Beschreibung

CONN:
Card
HandleCardHandle

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)

CONN:CardHandle
 SIG:SessionInfo

Liste von HBA-CardHandlesFalls vorhanden, Informationen zu der aktuell im Konnektor existierenden Komfortsignatursession für das CardHandle und den Aufrufkontext

SIG:Context
 SignatureMode

Liste von im Konnektor hinterlegten Aufrufkontexten für das jeweilige HBA-CardHandle
MandantId, ClientSystemId, UserId verpflichtendSignaturmodus der Komfortsignatursession (="Comfort")

SIG:SignatureModeCountRemaining

Im Konnektor hinterlegter Signaturmodus für den jeweiligen AufrufkontextVerbleibende Anzahl von Komfortsignaturen, die ohne erneute PIN-Eingabe ausgeführt werden dürfen

SIG:CountRemainingTimeRemaining

Verbleibende Anzahl vonZeit, in der Komfortsignaturen, die ohne erneute PIN-Eingabe ausgeführt werden dürfen
Format: "PTnHnMnS" (gemäß Datenttyp xsd:duration)

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

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 }

24.

TUC_KON_173 „Liefere Signaturmodus“

 

Der Komfortsignatur-Konfigurationsstatus des Konnektors und dieder im Konnektor hinterlegtenhinterlegte Signaturmodus werden für alleden dem Konnektor bekannten Aufrufkontexte derAufrufkontext des HBA aus derdem übergebenen CardHandle-Liste zurückgeliefert zurück geliefert.

Fehlercode

ErrorType

Severity

Fehlertext

Folgende Fehlercodes können auftreten:

4000

Technical

Error

Syntaxfehler