TIP1-A_5546-01 - VZD, Integritäts- u. Authentizitätsschutz

Der Anbieter des VZD MUSS die Integrität und Authentizität der im VZD gespeicherten Daten gemäß den Richtlinien des Bundesamtes für Sicherheit in der Informationstechnik für allgemeine Verzeichnisdienste, [BSI APP.2.1], implementieren. [<=]

TIP1-A_5547-01 - VZD, Löschen ungültiger Zertifikate

Der VZD MUSS täglich die gespeicherten Zertifikate nach Ablaufdatum (TUC_PKI_002 „Gültigkeitsprüfung des Zertifikats“) und Status (TUC_PKI_006 "OCSP-Abfrage) prüfen. Ungültige Zertifikate werden (inklusive der gesamten Zertifikatsstruktur "Certificate" entsprechend Abb_VZD_logisches_Datenmodell) sofort gelöscht. Ein Eintrag ohne gültige Zertifikate wird nach einem Jahr gelöscht und darf nicht durch eine Anfrage über die Operation search_Directory der Schnittstelle I_Directory_Query gefunden werden.
[<=]

A_21808 - VZD, Hinzufügen von professionOID und entryType in die Basisdaten

Der VZD MUSS beim Hinzufügen von Zertifikaten prüfen, ob der Wert der enthaltenen professionOID bzw. entryType schon in den Basisdaten vorhanden ist. Falls nicht, MUSS der VZD diese professionOID bzw. entryType zu den existierenden Basisdaten hinzufügen. [<=]

A_21809 - VZD, Löschen von professionOID und entryType aus den Basisdaten

Der VZD MUSS gewährleisten, dass nach dem Löschen von Zertifikaten für die Attribute professionOID und entryType in den Basisdaten nur Werte aus den verbleibenden Zertifikaten erhalten bleiben. [<=]

TIP1-A_5548 - VZD, Protokollierung der Änderungsoperationen

Der VZD MUSS Änderungen der Verzeichnisdiensteinträge protokollieren und muss sie 6 Monate zur Verfügung halten.

TIP1-A_5549 - VZD, Keine Leseprofilbildung

Der VZD DARF Suchanfragen NICHT speichern oder protokollieren.

TIP1-A_5550 - VZD, Keine Kopien von gelöschten Daten

Der VZD DARF von gelöschten Daten KEINE Kopien speichern.

TIP1-A_5551 - VZD, Sicher gegen Datenverlust

Der Anbieter des VZD MUSS den Dienst gegen Datenverlust absichern.

TIP1-A_5552 - VZD, Begrenzung der Suchergebnisse

Der VZD MUSS die Ergebnisliste einer Suchanfrage auf 100 Suchergebnisse begrenzen.

TIP1-A_5553 - VZD, Private Schlüssel sicher speichern

Der VZD MUSS seine privaten Schlüssel sicher speichern und ihr Auslesen verhindern um Manipulationen zu verhindern.

TIP1-A_5554 - VZD, Registrierungsdaten sicher speichern

Der VZD MUSS die Integrität und Authentizität der gespeicherten Registrierungsdaten der FAD gewährleisten.

TIP1-A_5555 - VZD, SOAP-Fehlercodes

Der VZD MUSS für seine SOAP-Schnittstelle die generischen Fehlercodes

• Code 2: Verbindung zurückgewiesen

• Code 3: Nachrichtenschema fehlerhaft

• Code 4: Version Nachrichtenschema fehlerhaft

• Code 6: Protokollfehler

aus Tabelle Tab_Gen_Fehler  aus [gemSpec_OM] im SOAP-Fault verwenden. Erkannte Fehler auf Transportprotokollebene müssen auf gematik SOAP Faults (Code 6 aus Tabelle Tab_Gen_Fehler aus [gemSpec_OM]) abgebildet werden.
​​

TIP1-A_5556 - VZD, Fehler Logging

Der VZD MUSS lokal und remote erkannte Fehler in seinem lokalen Speicher protokollieren.

TIP1-A_5557 - VZD, Unterstützung IPv4 und IPv6

Der VZD MUSS IPv4 und IPv6 für alle seine IP-Schnittstellen im Dual-Stack-Mode unterstützen.

TIP1-A_5558 - VZD, Sicheres Speichern der TSL

Der VZD MUSS  die Inhalte der TSL in einem lokalen Trust Store sicher speichern und für X.509-Zertifikatsprüfungen lokal zugreifbar halten.

TIP1-A_5560 - VZD, Erweiterbarkeit für neue Fachdaten

Der Anbieter des VZD MUSS die Erweiterbarkeit des VZD für die Aufnahme der Fachdaten neuer Fachanwendungen gewährleisten.

TIP1-A_5561 - VZD, DNS-SD

Der Anbieter des VZD MUSS alle erforderlichen Einträge zur Dienstlokalisierung der Außenschnittstellen gemäß [RFC6763] beginnend mit folgenden PTR Resource Record-Bezeichnern im Namensdienst der TI-Plattform anlegen:

TIP1-A_5562 - VZD, Parallele Zugriffe

Der Betreiber des VZD MUSS sicherstellen, dass Benutzer gleichzeitig auf den VZD zugreifen können. Dies umfasst alle technischen Schnittstellen. In [gemSpec_Perf] ist die Anzahl der parallelen Zugriffe definiert.

TIP1-A_5563-01 - VZD, Erhöhung der Anzahl der Einträge

Der Anbieter des VZD MUSS sicherstellen, dass 1.000.000 Einträge gespeichert werden können.
[<=]

TIP1-A_5620 - VZD, Nicht-Speicherung von Leading und Trailing Spaces

Der Anbieter des VZD MUSS Leading und Trailing Spaces abschneiden.
[<=]

A_20331 - VZD, Verhinderung LDAP Injection Attack

Der VZD MUSS an allen Schnittstellen - welche LDAP nutzen bzw. auf LDAP abgebildet werden - LDAP Injection Attacks durch geeignete Sicherheitsprüfungen verhindern.
[<=]

A_20262 - VZD, Maximale Anzahl von KOM-LE Adressen in den Fachdaten

Der VZD MUSS bei dem Hinzufügen von KOM-LE Adressen in den Fachdaten folgende Regeln beachten:

• Wenn maxKOMLEadr im Verzeichniseintrag keinen Wert enthält, MUSS der VZD das Eintragen beliebig vieler KOM-LE Adressen in den Fachdaten erlauben.
• Wenn maxKOMLEadr im Verzeichniseintrag einen Wert enthält, MUSS der VZD das Eintragen von maximal so vielen KOM-LE Adressen in den Fachdaten erlauben.
• Wenn der Wert von maxKOMLEadr im Verzeichniseintrag gleich oder kleiner ist als die Anzahl der KOM-LE Adressen in den Fachdaten (z.B. falls der Wert heruntergesetzt wurde), MUSS der VZD das Eintragen von weiteren KOM-LE Adressen in den Fachdaten ablehnen.

A_20263 - VZD, Kein automatisches Löschen von KOM-LE Adressen in den Fachdaten

Der VZD DARF KOM-LE Adressen in den Fachdaten als Folge einer Änderung (Verkleinerung) des Attributwerts von maxKOMLEadr NICHT automatisch löschen.
[<=]

A_23179 - VZD, Zeitnahes Aktualisieren von Zertifikaten entsprechend zeitlicher Gültigkeit

Der VZD MUSS - anhand der Attribute notBefore und notAfter in den Zertifikatsdaten - periodisch die zeitliche Gültigkeit der Zertifikate ermitteln und diese entsprechend ihrer Gültigkeit in die flache Liste synchronisieren bzw. aus ihr löschen. Die Periode dieser Prüfung MUSS konfigurierbar sein. [<=]

A_22224 - VZD, konfigurierbares Mapping von professionOID auf entryType

Der VZD MUSS das Mapping von professionOID auf entryType konfigurierbar implementieren, so dass bei Änderung des Mappings oder neuen professionOIDs oder neuen entryTypes keine Anpassung an der Software des VZD erforderlich ist.
Änderungen am Mapping werden durch den Gesamtbetriebsverantwortlichen TI per betrieblichen Change veranlasst.   
[<=]

TIP1-A_5564 - VZD, Festlegung der Schnittstellen

Der VZD MUSS die Schnittstellen gemäß Tabelle Tab_PT_VZD_Schnittstellen implementieren („bereitgestellte“ Schnittstellen) und nutzen („benötigte“ Schnittstellen).

Tabelle 1: Tab_PT_VZD_Schnittstellen

A_22361 - VZD, Filtermöglichkeiten in Leseoperationen

Der VZD MUSS für die Leseoperationen read_Directory_Entry und read_Directory_Entry_for_Sync der Schnittstellen I_Directory_Administration und I_Directory_Application_Maintenance die folgenden Filtermöglichkeiten unterstützen:

• Suche mit Wildcard "*" in den Parametern
  - givenName
  - sn
  - cn
  - displayName
  - streetAddress
  - postalCode
  - countryCode
  - localityName
  - stateOrProvinceName
  - title
  - organization
  - otherName
  - telematikID
  - specialization
  - domainID
  - holder
  - professionOID
  
• Suche nach Vorhandensein und leerem Inhalt eines Attributs des VZD Datensatzes mit dem Kode \00 in den Parametern.
  - givenName
  - sn
  - cn
  - displayName
  - streetAddress
  - postalCode
  - countryCode
  - localityName
  - stateOrProvinceName
  - title
  - organization
  - otherName
  - specialization
  - domainID
  - holder
  - professionOID
  - maxKOMLEadr
  - changeDateTimeFrom
  - changeDateTimeTo
  Diese Suche findet sowohl Datensätze mit nicht vorhandenem Attribut wie auch vorhandenem aber leerem Attribut. Der Suchparameter darf nur den Kode \00 enthalten, keine weiteren Zeichen.

TIP1-A_5565 - VZD, Schnittstelle I_Directory_Query

Der VZD MUSS für LDAP Clients die Schnittstelle I_Directory_Query gemäß Tabelle Tab_VZD_Schnittstelle_I_Directory_Query anbieten.

Tabelle 2: Tab_VZD_Schnittstelle_I_Directory_Query

TIP1-A_5566 - LDAP Client, LDAPS

Der LDAP Client MUSS die Verbindung zum VZD mittels LDAPS sichern.
Der LDAP Client muss das Zertifikat des VZD C.ZD.TLS-S gemäß TUC_PKI_018 "Zertifikatsprüfung in der TI" und die Rolle (zulässig ist oid_vzd_ti) prüfen. LDAP Clients der Anbieter von WANDA Basic und WANDA Smart sind davon ausgenommen.
Der LDAP Client authentisiert sich nicht.
[<=]

TIP1-A_5567 - VZD, LDAPS bei search_Directory

Der VZD MUSS sicherstellen, dass die Operation search_Directory nur über eine bestehende LDAPS -Verbindung ausgeführt werden kann.

Der VZD muss die TLS-Verbindung 15 Minuten nach dem letzten Meldungsverkehr abbauen, falls sie noch besteht.

TIP1-A_5568 - VZD und LDAP Client, Implementierung der LDAPv3 search Operation

Der VZD und die LDAP-Clients MÜSSEN die search Operation gemäß den LDAPv3 Standards [RFC4510], [RFC4511], [RFC4512], [RFC4513], [RFC4514], [RFC4515], [RFC4516], [RFC4517], [RFC4518], [RFC4519], [RFC4520], [RFC4522] und [RFC4523] implementieren.
[<=]

A_17794 - VZD, Testunterstützung

Der VZD MUSS für die Schnittstelle I_Directory_Query einen technischen User in RU/TU bereitstellen, über den eine unlimitierte Abfrage der Daten des Verzeichnisdienstes (searchView) möglich ist.
[<=]

TIP1-A_5569 - VZD, search_Directory, Suche nach definierten Attributen

Der VZD MUSS die enthaltenen Daten so strukturiert haben, dass mit einer einzigen LDAPv3-Suche alle einer Telematik-ID zugeordneten Attribute (Basisdaten und Fachdaten) in Form einer flachen Liste von Attributen ohne ou-Unterstruktur abgefragt werden können.
Die abgefragten Attribute MÜSSEN durch marktübliche E-Mail Clients nutzbar sein.
[<=]

TIP1-A_5570 - LDAP Client, TUC_VZD_0001 „search_Directory”

Der Anbieter des VZD MUSS für die Nutzung durch LDAP Clients den technischen Use Case TUC_VZD_0001 „search_Directory” gemäß Tabelle Tab_TUC_VZD_0001 unterstützen.

Tabelle 3: Tab_TUC_VZD_0001

TIP1-A_5571 - VZD, Schnittstelle I_Directory_Maintenance

Der VZD MUSS die Schnittstelle I_Directory_Maintenance gemäß Tabelle Tab_VZD_Schnittstelle_I_Directory_Maintenance anbieten.

Tabelle 4: Tab_VZD_Schnittstelle_I_Directory_Maintenance

TIP1-A_5572 - VZD, I_Directory_Maintenance, TLS-gesicherte Verbindung

Der VZD MUSS die Schnittstelle I_Directory_Maintenance durch Verwendung von TLS mit beidseitiger Authentisierung sichern.
Der VZD muss sich mit der Identität ID.ZD.TLS-S authentisieren.
Der VZD muss das vom FAD übergebene AUT-Zertifikat C.FD.TLS-C hinsichtlich OCSP-Gültigkeit und Übereinstimmung mit einem Zertifikat eines zur Nutzung dieser Schnittstelle registrierten Fachdienstes prüfen. Bei negativem Ergebnis wird der Verbindungsaufbau abgebrochen.
[<=]

TIP1-A_5574 - VZD und Nutzer der Schnittstelle I_Directory_Maintenance, WebService

Der VZD und Nutzer der Schnittstelle MÜSSEN die Schnittstelle I_Directory_Maintenance als SOAP-Webservice über HTTPS implementieren. Der Webservice wird durch die Dokumente DirectoryMaintenance.wsdl und DirectoryMaintenance.xsd definiert.

TIP1-A_5575 - VZD, Umsetzung add_Directory_Entry

Der VZD MUSS nach folgenden Vorgaben die Operation add_Directory_Entry implementieren:

1. Ein bereits zur Telematik-ID gehörender Basisdatensatz wird gelöscht und neu angelegt.
   
2. Existiert noch kein Basisdatensatz zur Telematik-ID wird ein neuer angelegt.
   
3. Die Daten aus dem SOAP Request bilden gemäß Tab_VZD_Daten-Transformation und Tab_VZD_Datenbeschreibung den neuen Basisdatensatz.
   

TIP1-A_5576 - Nutzer der Schnittstelle, TUC_VZD_0002 „add_Directory_Entry”

Der Nutzer der Schnittstelle MUSS den technischen Use Case TUC_VZD_0002 „add_Directory_Entry” gemäß Tabelle Tab_TUC_VZD_0002 umsetzen.
Der SOAP-Requests MUSS gemäß Tab_VZD_Datenbeschreibung mit der Bedeutung entsprechenden Daten ausgefüllt sein.

Tabelle 6: Tab_TUC_VZD_0002

TIP1-A_5577 - VZD, Umsetzung read_Directory_Entry

Der VZD MUSS nach folgenden Vorgaben die Operation I_Directory_Maintenance::read_Directory_Entry implementieren:

1. Der zur Telematik-ID gehörende Eintrag wird im LDAP Directory ermittelt.
   
2. Es wird eine SOAP Response VZD:readResponseMsg aus dem kompletten Eintrag (Basisdaten + Fachdaten) gemäßTab_VZD_Daten-Transformation und Tab_VZD_Datenbeschreibung erzeugt.
   

TIP1-A_5578 - Nutzer der Schnittstelle, TUC_VZD_0003 „read_Directory_Entry”

Der Nutzer der Schnittstelle MUSS den technischen Use Case TUC_VZD_0003 „read_Directory_Entry” gemäß Tabelle Tab_TUC_VZD_0003 umsetzen. Der Webservice wird durch die Dokumente DirectoryMaintenance.wsdl und DirectoryMaintenance.xsd definiert.
Die SOAP-Response ist gemäß Tabelle Tab_VZD_Datenbeschreibung mit den zur Telematik-ID gehörenden Daten aus dem VZD ausgefüllt.

Tabelle 7: Tab_TUC_VZD_0003

TIP1-A_5579 - VZD, Umsetzung modify_Directory_Entry

Der VZD MUSS nach folgenden Vorgaben die Operation modify_Directory_Entry implementieren:

1. Der zur Telematik-ID gehörende Basisdatensatz wird im LDAP Directory ermittelt.
   
2. Die Daten im Basisdatensatz werden durch die Daten aus dem SOAP Request gemäß Tab_VZD_Daten-Transformation und Tab_VZD_Datenbeschreibung geändert.
   

TIP1-A_5580 - Nutzer der Schnittstelle, TUC_VZD_0004 „modify_Directory_Entry”

Der Nutzer der Schnittstelle MUSS den technischen Use Case TUC_VZD_0004 „modify_Directory_Entry” gemäß Tabelle Tab_TUC_VZD_0004 umsetzen. Der Webservice wird durch die Dokumente DirectoryMaintenance.wsdl und DirectoryMaintenance.xsd definiert.
Der SOAP-Requests MUSS gemäß Tabelle VZD_TAB_modifyDirectoryEntry_Mapping mit der Bedeutung entsprechenden Daten ausgefüllt sein.

Tabelle 8: Tab_TUC_VZD_0004

TIP1-A_5581 - VZD, Umsetzung delete_Directory_Entry

Der VZD MUSS nach folgenden Vorgaben die Operation I_Directory_Maintenance::delete_Directory_Entry implementieren:

1. Ein zur Telematik-ID gehörender vollständiger Eintrag gelöscht.

Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0005 verwendet werden.

TIP1-A_5582 - Nutzer der Schnittstelle, TUC_VZD_0005 „delete_Directory_Entry”

Der Nutzer der Schnittstelle MUSS den technischen Use Case TUC_VZD_0005 „delete_Directory_Entry” gemäß Tabelle Tab_TUC_VZD_0005 umsetzen. Der Webservice wird durch die Dokumente DirectoryMaintenance.wsdl und DirectoryMaintenance.xsd definiert.

Tabelle 9: Tab_TUC_VZD_0005

TIP1-A_5583-02 - VZD, Schnittstelle I_Directory_Application_Maintenance

Der VZD MUSS die Schnittstelle I_Directory_Application_Maintenance gemäß Tabelle Tab_VZD_Schnittstelle_I_Directory_Application_Maintenance anbieten.

Tabelle 10: Tab_VZD_Schnittstelle_I_Directory_Application_Maintenance

TIP1-A_5584 - VZD, Änderung nur durch registrierte FAD

Der Anbieter des VZD MUSS sicherstellen, dass Fachdaten eines Dienstes nur durch einen beim VZD für diesen Dienst registrierten Fachdienst erzeugt, gelöscht und geändert werden können.

TIP1-A_5585 - VZD, I_Directory_Application_Maintenance, TLS-gesicherte Verbindung

Der VZD MUSS die Schnittstelle I_Directory_Application_Maintenance durch Verwendung von TLS mit beidseitiger Authentisierung sichern.

Der VZD muss sich mit der Identität ID.ZD.TLS-S authentisieren.

Der VZD muss das vom FAD übergebene AUT-Zertifikat C.FD.TLS-C hinsichtlich OCSP Gültigkeit und Übereinstimmung mit einem Zertifikat eines zur Nutzung dieser Schnittstelle registrierten Fachdienstes prüfen. Bei negativem Ergebnis wird der Verbindungsaufbau abgebrochen.

TIP1-A_5586-01 - VZD, I_Directory_Application_Maintenance, Webservice und LDAPv3

Der VZD MUSS die Schnittstelle I_Directory_Application_Maintenance als Webservice (SOAP und REST über HTTPS) und als LDPv3 über LDAPS implementieren. Der Webservice (SOAP) wird durch die Dokumente DirectoryApplicationMaintenance.wsdl und DirectoryApplicationMaintenance.xsd definiert. Der Webservice (REST) wird durch die [Directory_Application_Maintenance.yaml] Datei definiert. Die LDAPv3-Attribute sind in dem Informationsmodell Abb_VZD_logisches_Datenmodell beschrieben.
[<=]

TIP1-A_5587 - VZD, Implementierung der LDAPv3 Schnittstelle

Der VZD MUSS die Schnittstelle I_Directory_Application_Maintenance gemäß den LDAPv3 Standards [RFC4510], [RFC4511], [RFC4512], [RFC4513], [RFC4514], [RFC4515], [RFC4516], [RFC4517], [RFC4518], [RFC4519], [RFC4520], [RFC4522] und [RFC4523] implementieren.

TIP1-A_5588 - FAD, I_Directory_Application_Maintenance, Nutzung LDAP v3 oder Webservice

Ein FAD, der Fachdaten im VZD verwalten will, MUSS entweder die Webservice- oder die LDAPv3-Schnittstelle nutzen.

TIP1-A_5589 - FAD, Implementierung der LDAPv3 Schnittstelle

Der FAD, der die LDAPv3-Schnittstelle I_Directory_Application_Maintenance des VZD nutzt, MUSS diese Schnittstelle gemäß den LDAPv3 Standards [RFC4510], [RFC4511], [RFC4512], [RFC4513], [RFC4514], [RFC4515], [RFC4516], [RFC4517], [RFC4518], [RFC4519], [RFC4520], [RFC4522] und [RFC4523] implementieren. Die LDAPv3-Attribute sind in dem Informationsmodell Abb_VZD_logisches_Datenmodell beschrieben.

A_23728-01 - VZD, I_Directory_Application_Maintenance, Aktualisierung zulässiger Anwendungskennzeichen

Der VZD MUSS täglich um 4:00 Uhr das FHIR CodeSystems mit den Anwendungskennzeichen aus Simplifier (https://simplifier.net/app-transport-framework/app-tags-cs/$download?format=json ) aktualisieren und persistent speichern. [<=]

A_21788-01 - VZD, Umsetzung I_Directory_Application_Maintenance getInfo (REST)

Der VZD MUSS nach folgenden Vorgaben die Operation getInfo implementieren:
In dem Rückgabewerten müssen die aktuell gültigen Metainformationen für Schnittstelle I_Directory_Application_Maintenance zurückgegeben werden. Insbesondere muss

A_21787 - VZD, I_Directory_Application_Maintenance, getInfo

Der VZD MUSS die Operation „getInfo” gemäß Tabelle Tab_VZD „I_Directory_Application_Maintenance-getInfo” umsetzen.

Tabelle 11: Tab_VZD „I_Directory_Application_Maintenance-getInfo”

TIP1-A_5590 - VZD, Umsetzung add_Directory_FA-Attributes (SOAP)

Der VZD MUSS nach folgenden Vorgaben die Operation add_Directory_FA-Attributes implementieren:

1. Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request mit einem gematik SOAP-Fault beendet:
   faultcode: 4312,
   faultstring: Basisdaten konnten nicht gefunden werden.
   
2. Ein bereits zur Telematik-ID gehörender Fachdatensatz wird gelöscht und neu angelegt.
   
3. Ein noch nicht existierender Fachdatensatz zur Telematik-ID wird im LDAP Directory neu angelegt.
   
4. Die Daten aus dem SOAP Request werden gemäß VZD_TAB_I_Directory_Application_Maintenance_Add_Mapping zum Basisdatensatz hinzugefügt.
   

Tabelle 12: VZD_TAB_I_Directory_Application_Maintenance_Add_Mapping

TIP1-A_5591 - FAD, TUC_VZD_0006 “add_Directory_FA-Attributes (SOAP)”

Der FAD MUSS den technischen Use Case TUC_VZD_0006 “add_Directory_FA-Attributes” gemäß Tabelle Tab_TUC_VZD_0006 umsetzen.

Tabelle 13: Tab_TUC_VZD_0006

TIP1-A_5592-03 - FAD, KOM-LE_FA_Add_Attributes

Der FAD MUSS für die FA KOM-LE die Fachdaten nach VZD_TAB_KOM-LE_Add_Attributes administrieren.

Tabelle 14: VZD_TAB_KOM-LE_Attributes

TIP1-A_5593 - VZD, Umsetzung add_Directory_FA-Attributes (LDAPv3)

Der VZD MUSS nach folgenden Vorgaben die Operation add_Directory_FA-Attributes implementieren:

1. Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request mit einer Fehlermeldung beendet.

2. Ein noch nicht existierender Fachdatensatz zur Telematik-ID wird im VZD neu angelegt.

3. Der FAD darf nur die zu seinem Dienst gehörenden Fachdaten schreiben.

Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0007 verwendet werden.

TIP1-A_5594 - FAD, TUC_VZD_0007 “add_Directory_FA-Attributes (LDAPv3)”

Der FAD MUSS den technischen Use Case TUC_VZD_0007 „add_Directory_FA-Attributes(LDAPv3)” gemäß Tabelle Tab_TUC_VZD_0007 unterstützen.

Tabelle 15: Tab_TUC_VZD_0007

A_21834 - VZD, I_Directory_Application_Maintenance, KOM-LE_Version Prüfung LDAP

Der VZD MUSS bei Änderungen an KOM-LE-Fachdaten mit den Operationen “add_Directory_FA-Attributes (LDAPv3)” und "modify_Directory_FA-Attributes (LDAPv3)" den Inhalt von Parameter KOM-LE_Version des Operation Requests gegen die Liste der gültigen Werte prüfen. Im Falle von ungültigen Werten MUSS der VZD mit LDAP Result Code constraintViolation (19) antworten und darf die Operation nicht ausführen. Der VZD MUSS die Liste der gültigen Werte von Attribut KOM-LE_Version konfigurierbar realisieren und der gematik Änderungensmöglichkeiten über einen Service Request bieten. [<=]

A_21835 - VZD, I_Directory_Application_Maintenance, Eindeutige Zuordnung von KOM-LE Adressen zu VZD-Einträgen LDAP

Der VZD MUSS sicherstellen, dass jede KOM-LE-Adresse mit den Operationen “add_Directory_FA-Attributes (LDAPv3)” und "modify_Directory_FA-Attributes (LDAPv3)" nur an maximal einen VZD-Eintrag angehängt wird. Hierzu MUSS er vor einer Eintragung einer KOM-LE Adresse prüfen, ob diese bereits im VZD hinterlegt ist. Ist sie bereits hinterlegt, MUSS der VZD mit LDAP Result Code attributeOrValueExists (20) antworten und darf die Operation nicht ausführen.
[<=]

A_23729 - VZD, I_Directory_Application_Maintenance, Anwendungskennzeichen Prüfung LDAP

Der VZD MUSS bei Änderungen an KOM-LE-Fachdaten mit den Operationen “add_Directory_FA-Attributes (LDAPv3)” und "modify_Directory_FA-Attributes (LDAPv3)" den Inhalt von Parameter Anwendungskennzeichen (appTags) des Operation Requests gegen die Liste der gültigen Werte prüfen. Im Falle von ungültigen Werten MUSS der VZD mit LDAP Result Code constraintViolation (19) antworten und darf die Operation nicht ausführen. [<=]

A_21458 - VZD, Umsetzung add_Directory_FA-Attributes (REST)

Der VZD MUSS nach folgenden Vorgaben die Operation add_Directory_FA-Attributes implementieren:

1. Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request mit einem HTTP-Statuscode beendet:
   HTTP-Statuscode: 404
   
2. Ein bereits zur Telematik-ID gehörender Fachdatensatz wird gelöscht und neu angelegt.
   
3. Ein noch nicht existierender Fachdatensatz zur Telematik-ID wird im LDAP Directory neu angelegt.
   
4. Die Daten aus dem Request werden zum dazugehörenden Fachdatensatz hinzugefügt.

A_23730 - VZD, I_Directory_Application_Maintenance, Anwendungskennzeichen Prüfung REST

Der VZD MUSS bei Änderungen an KOM-LE-Fachdaten mit den Operationen „add_Directory_FA-Attributes“ und "modify_Directory_FA-Attributes" den Inhalt von Parameter Anwendungskennzeichen (appTags) des Operation Requests gegen die Liste der gültigen Werte prüfen. Im Falle von ungültigen Werten MUSS der VZD mit HTTP-Statuscode 400 (attributeName="appTags" , attributeError="erläuternder Fehlertext") antworten und darf die Operation nicht ausführen. [<=]

A_23819 - VZD, I_Directory_Application_Maintenance, Behandlung komLeData & kimData REST

Der VZD MUSS bei Änderungen an KOM-LE-Fachdaten mit den Operationen „add_Directory_FA-Attributes“ und "modify_Directory_FA-Attributes" den Inhalt von Parameter komLeData wie folgendermassen in die LDAP Datenstruktur eintragen:

• komLeData.mail der REST Operation wird in die LDAP Attribute komLeData.mail und kimData.mail eingetragen.
  
• komLeData.version der REST Operation wird in die LDAP Attribute komLeData.version und kimData.version eingetragen.
• komLeData.appTags der REST Operation wird in die LDAP Attribut kimData.appTags eingetragen.

A_21459 - FAD, VZD, TUC_VZD_0012 “add_Directory_FA-Attributes (REST)”

Der FAD MUSS den technischen Use Case TUC_VZD_0012 “add_Directory_FA-Attributes” gemäß Tabelle Tab_TUC_VZD_0012 umsetzen.

Tabelle 16: Tab_TUC_VZD_0012

A_21825-02 - VZD, I_Directory_Application_Maintenance, KOM-LE_Version Prüfung REST

Der VZD MUSS bei Änderungen an KOM-LE-Fachdaten mit den Operationen „add_Directory_FA-Attributes“ und "modify_Directory_FA-Attributes" den Inhalt von Parameter KOM-LE_Version des Operation Requests gegen die Liste der gültigen Werte prüfen. Im Falle von ungültigen Werten MUSS der VZD mit HTTP-Statuscode 400 (attributeName="KOM-LE_Version" , attributeError="erläuternder Fehlertext") antworten und darf die Operation nicht ausführen. Der VZD MUSS die Liste der gültigen Werte von Attribut KOM-LE_Version konfigurierbar realisieren und der gematik Änderungensmöglichkeiten über einen Service Request bieten.
[<=]

A_21826-01 - VZD, I_Directory_Application_Maintenance, Eindeutige Zuordnung von KOM-LE-Adressen zu VZD-Einträgen REST

Der VZD MUSS sicherstellen, dass jede KOM-LE Adresse mit den Operationen „add_Directory_FA-Attributes“ und "modify_Directory_FA-Attributes" nur an maximal einen VZD-Eintrag angehängt wird. Hierzu MUSS er vor einer Eintragung einer KOM-LE Adresse prüfen, ob diese bereits im VZD hinterlegt ist. Ist sie bereits hinterlegt, MUSS der VZD mit HTTP-Statuscode 400 (attributeName="mail" , attributeError="erläuternder Fehlertext") antworten und darf die Operation nicht ausführen.
[<=]

TIP1-A_5595 - VZD, Umsetzung delete_Directory_FA-Attributes

Der VZD MUSS nach folgenden Vorgaben die Operation delete_Directory_ FA-Attributes implementieren:

1. Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request mit einem gematik SOAP-Fault beendet:
   faultcode: 4312,
   faultstring: Basisdaten konnten nicht gefunden werden.
   
2. Ein zur Telematik-ID gehörender Fachdatensatz wird gelöscht.
   
3. Ein nicht existierender Fachdatensatz zur Telematik-ID führt zu keiner Aktion.
   

TIP1-A_5596 - FAD, TUC_VZD_0008 “delete_Directory_FA-Attributes (SOAP)”

Der FAD MUSS den technischen Use Case TUC_VZD_0008 “delete_Directory_FA-Attributes” gemäß Tabelle Tab_TUC_VZD_0008 umsetzen.

Tabelle 17: Tab_TUC_VZD_0008

TIP1-A_5597 - VZD, Umsetzung delete_Directory_FA-Attributes (LDAPv3)

Der VZD MUSS nach folgenden Vorgaben die Operation delete_Directory_FA-Attributes implementieren:

1. Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request beendet.

2. Ein zur Telematik-ID gehörender Fachdatensatz wird gelöscht.

3. Ein nicht existierender Fachdatensatz zur Telematik-ID führt zu keiner Aktion.

4. Der FAD darf nur die zu seinem Dienst gehörenden Fachdaten löschen.

Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0009 verwendet werden.

TIP1-A_5598 - FAD, TUC_VZD_0009 “delete_Directory_FA-Attributes (LDAPv3)”

Der FAD MUSS den technischen Use Case TUC_VZD_0009 „delete_Directory_FA-Attributes(LDAPv3)” gemäß Tabelle Tab_TUC_VZD_0009 unterstützen.

Tabelle 18: Tab_TUC_VZD_0009

A_21460 - VZD, Umsetzung delete_Directory_FA-Attributes (REST)

Der VZD MUSS nach folgenden Vorgaben die Operation delete_Directory_ FA-Attributes implementieren:

1. Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request mit einem HTTP-Statuscode beendet:
   HTTP-Statuscode: 404
   
2. Ein zur Telematik-ID gehörender Fachdatensatz wird gelöscht.
   
3. Ein nicht existierender Fachdatensatz zur Telematik-ID führt zu keiner Aktion und HTTP-Statuscode: 404 im Response.

A_21461 - FAD, TUC_VZD_0013 “delete_Directory_FA-Attributes (REST)”

Der FAD MUSS den technischen Use Case TUC_VZD_0013 “delete_Directory_FA-Attributes” gemäß Tabelle Tab_TUC_VZD_0013 umsetzen.

Tabelle 19: Tab_TUC_VZD_0013

TIP1-A_5599 - VZD, Umsetzung modify_Directory_FA-Attributes

Der VZD MUSS nach folgenden Vorgaben die Operation modify_Directory_ FA-Attributes implementieren:

1. Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request mit einem gematik SOAP-Fault beendet:
   faultcode: 4312,
   faultstring: Basisdaten konnten nicht gefunden werden.
   
2. Ein bereits zur Telematik-ID gehörender Fachdatensatz wird überschrieben.
   
3. Die Daten aus dem SOAP Request werden gemäß VZD_TAB_I_Directory_Application_Maintenance_Modify_Mapping zum Basisdatensatz hinzugefügt.
   

Tabelle 20: VZD_TAB_I_Directory_Application_Maintenance_Modify_Mapping

TIP1-A_5600 - FAD, TUC_VZD_0010 “modify_Directory_FA-Attributes (SOAP)”

Der FAD MUSS den technischen Use Case TUC_VZD_0010 “modify_Directory_FA-Attributes” gemäß Tabelle Tab_TUC_VZD_0010 umsetzen.

Tabelle 21: Tab_TUC_VZD_0010

TIP1-A_5601-03 - FAD, KOM-LE_FA_Modify_Attributes

Der FAD MUSS für die FA KOM-LE die Fachdaten nach VZD_TAB_KOM-LE_Modify_Attributes administrieren.

Tabelle 22: VZD_TAB_KOM-LE_Attributes

TIP1-A_5602 - VZD, Umsetzung modify_Directory_FA-Attributes (LDAPv3)

Der VZD MUSS nach folgenden Vorgaben die Operation modify_Directory_FA-Attributes implementieren:

1. Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request beendet.

2. Ein bereits zur Telematik-ID gehörender Fachdatensatz wird geändert.

3. Der FAD darf nur die zu seinem Dienst gehörenden Fachdaten ändern.

Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0011 verwendet werden.

TIP1-A_5603 - FAD, TUC_VZD_0011 “modify_Directory_FA-Attributes (LDAPv3)”

Der FAD MUSS den technischen Use Case TUC_VZD_0011 „modify_Directory_FA-Attributes(LDAPv3)” gemäß Tabelle Tab_TUC_VZD_0011 unterstützen.

Tabelle 23: Tab_TUC_VZD_0011

A_21462 - VZD, Umsetzung modify_Directory_FA-Attributes (REST)

Der VZD MUSS nach folgenden Vorgaben die Operation modify_Directory_ FA-Attributes implementieren:

1. Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request mit einem HTTP-Statuscode beendet:
   HTTP-Statuscode: 404
   
2. Ein bereits zur Telematik-ID gehörender Fachdatensatz (FADx in Abb_VZD_logisches_Datenmodell) des authentifizierten Fachdienstanbieters wird überschrieben.
   
3. Ein nicht existierender Fachdatensatz zur Telematik-ID führt zu keiner Aktion und HTTP-Statuscode: 404 im Response.

A_21463 - FAD, TUC_VZD_0014 “modify_Directory_FA-Attributes (REST)”

Der FAD MUSS den technischen Use Case TUC_VZD_0014 “modify_Directory_FA-Attributes” gemäß Tabelle Tab_TUC_VZD_0014 umsetzen.

Tabelle 24: Tab_TUC_VZD_0014

A_21464 - VZD, Umsetzung get_Directory_FA-Attributes (REST)

Der VZD MUSS nach folgenden Vorgaben die Operation get_Directory_FA-Attributes implementieren:

1. Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request mit einem HTTP-Statuscode beendet:
   HTTP-Statuscode: 404
   
2. Ein nicht existierender Fachdatensatz zur Telematik-ID führt zur Rückgabe von HTTP-Statuscode: 404 im Response.

A_21465 - FAD, TUC_VZD_0015 “get_Directory_FA-Attributes (REST)”

Der FAD MUSS den technischen Use Case TUC_VZD_0015 “get_Directory_FA-Attributes” gemäß Tabelle Tab_TUC_VZD_0015 umsetzen.

Tabelle 25: Tab_TUC_VZD_0015

A_24007 - VZD, Umsetzung appTags (REST)

Der VZD MUSS nach folgenden Vorgaben die Operation appTags implementieren:

1. Der VZD muss seine Liste der zulässigen appTags periodisch aus simplifier aktualisieren.
2. Die Periode für die appTags Aktualisierung muss konfigurierbar sein.
3. Als Response der Operation appTags gibt der VZD die aktuelle, vollständige Liste der appTags (Anwendungskennzeichen) zurück.

A_24008 - FAD, TUC_VZD_0016 “appTags (REST)”

Der FAD MUSS den technischen Use Case TUC_VZD_0016 “TUC_VZD_0016” gemäß Tabelle Tab_TUC_VZD_0016 umsetzen.

Tabelle 26: Tab_TUC_VZD_0016

TIP1-A_5604 - VZD, Registrierung FADs

Der Anbieter des VZD MUSS einen Registrierungsprozess für FAD implementieren. Der Anbieter des VZD MUSS dazu überprüfen:

• Gültigkeit des TLS-Client-Zertifikat des FADs C.FD.TLS-C (Prüfschritte wie in TUC_PKI_018 und mit admission gemäß vom GTI vorgegebener OID-Liste ),
  
• Name der Fachanwendung (z.B. KOM-LE),
  
• Name des Fachdienstbetreibers.
  

TIP1-A_5605 - VZD, De-Registrierung FADs

Der Anbieter des VZD MUSS einen Deregistrierungsprozess für FAD implementieren.
Der VZD MUSS alle verbliebenen Fachdaten eines deregistrierten FAD löschen.
Der VZD-Anbieter dokumentiert den Prozess und legt ihn dem GTI zur Freigabe vor.
Der Anbieter des VZD informiert alle FAD-Anbieter wie der Prozess genutzt wird.
[<=]

TIP1-A_5606 - VZD, Mandat zur Löschung von Einträgen.

Der Anbieter des VZD MUSS einen Prozess implementieren, der es LE ermöglicht ihren Eintrag im VZD ohne zugehörige Smartcard zu löschen.
Der Anbieter des VZD MUSS vom LE einen Nachweis fordern und prüfen, dass die zu löschenden Daten dem LE gehören. Erst nach positivem Ergebnis der Prüfung darf gelöscht werden.
Der VZD-Anbieter dokumentiert den Prozess und legt ihn dem GTI zur Freigabe vor.
[<=]

A_18371-04 - VZD, Schnittstelle I_Directory_Administration

Der VZD MUSS die Schnittstelle I_Directory_Administration gemäß Tabelle Tab_VZD_Schnittstelle_I_Directory_Administration im Internet anbieten.

Tabelle 27: Tab_VZD_Schnittstelle_I_Directory_Administration

A_18373 - VZD, Schnittstelle I_Directory_Administration

Der VZD MUSS die Schnittstelle I_Directory_Administration als REST-Webservice über HTTPS implementieren. Der Webservice wird durch das Dokument DirectoryAdministration.yaml definiert.
[<=]

A_18408 - VZD, I_Directory_Administration, Registrierung

Der VZD-Anbieter MUSS für Clients der Schnittstelle I_Directory_Administration einen Registrierungsprozess bereitstellen. Während der Registrierung muss die Berechtigung des Antragstellers (Clients) zur Nutzung von Schnittstelle I_Directory_Administration durch den VZD-Anbieter geprüft und durch die gematik bestätigt werden. Nach erfolgreicher Registrierung MÜSSEN dem Antragsteller alle nötigen Daten - inklusive OAuth Client Credentials, CA-Zertifikat (welches zur Prüfung des Serverzertifikats durch den Client benötigt wird), VZD-Serverzertifikat - zur Nutzung der Schnittstelle bereitgestellt werden.
Der VZD-Anbieter MUSS die erfolgreich registrierten Clients immer mit aktuellen Zertifikaten versorgen.
[<=]

A_20267 - VZD, I_Directory_Administration, Registrierung beim IdP als Relying Party

Der Anbieter des VZD MUSS sich über einen organisatorischen Prozess bei einem vertrauenswürdigen Identity Provider (IDP) der Telematikinfrastruktur als Relying Party registrieren und die Bereitstellung der folgenden Claims in für Nutzer ausgestellte ACCESS_TOKEN mit dem IDP vereinbaren:

• name
• sub
• scope
• acr

A_20268 - VZD, Authentifizierung Nutzerrolle

Der VZD MUSS die fachliche Rolle eines Nutzers in jedem Operationsaufruf der Schnittstelle I_Directory_Administration anhand des Attributs "scope" im übergebenen ACCESS_TOKEN feststellen und für die nachfolgende Rollenprüfung je Operationsaufruf verwenden.  [<=]

A_20269 - VZD, Authentifizierung Nutzername

Der VZD MUSS den Namen eines Nutzers in jedem Operationsaufruf anhand des Attributs "name" im übergebenen ACCESS_TOKEN feststellen und für die Protokollierung des Zugriffs verwenden. [<=]

A_18470 - VZD, I_Directory_Administration, Client Secret Qualität

Der VZD-Anbieter MUSS bei der Erzeugung der OAuth client_secret‘s 128 Bit Zufall aus einer Zufallsquelle gemäß GS-A_4367 [gemSpec_Krypt] verwenden.
[<=]

A_18409 - VZD, I_Directory_Administration, Sperrung OAuth Client Credentials

Der VZD-Anbieter MUSS – für die gematik und den Client-Betreiber selbst - einen Service zur Sperrung der OAuth Client Credentials anbieten.
[<=]

A_18372 - VZD, I_Directory_Administration, TLS-gesicherte Verbindung

Der VZD MUSS die Schnittstelle I_Directory_Administration durch Verwendung von TLS mit serverseitiger Authentisierung sichern.
Der VZD MUSS für diese TLS-Verbindungen öffentliche Zertifikate nutzen (keine TI-Zertifikate).
Der VZD MUSS sich mit der Server-Identität von Schnittstelle I_Directory_Administration authentisieren.
[<=]

A_18374 - VZD, I_Directory_Administration, Redirect

Der VZD MUSS für die Schnittstelle I_Directory_Administration Anfragen der Clients – welche kein AccessToken entsprechend [RFC 6750] enthalten – durch ein Redirect zu dem OAuth2-Authentifizierungsdienst weiterleiten.  [<=]

A_18375 - VZD, I_Directory_Administration, OAuth2 Dienst

Der VZD MUSS einen OAuth2-Dienst bereitstellen. Dieser Dienst MUSS die Clients der Schnittstelle I_Directory_Administration anhand ihrer Client Credentials authentisieren und ihnen ein AccessToken entsprechend [RFC 6750] ausstellen. Das AccessToken muss im "sub" claim den Identifier des Clients enthalten. Die Anfrage des Clients MUSS nach erfolgreicher Authentisierung durch ein Redirect wieder zur VZD I_Directory_Administration Schnittstelle weitergeleitet werden.
[<=]

A_18376 - VZD, I_Directory_Administration, Prüfung AccessToken

Der VZD MUSS das vom Client übergebene AccessToken auf Gültigkeit für Schnittstelle  I_Directory_Administration prüfen. Bei negativem Ergebnis muss die Operation mit HTTP Fehler 401 Unauthorized abgebrochen werden.
[<=]

A_18471-01 - VZD, I_Directory_Administration, Datenquelle

Der VZD MUSS bei den Operationen add_Directory_Entry und modify_Directory_Entry das LDAP-Directory-Attribut dataFromAuthority auf den Wert TRUE setzen und bei allen anderen Operationen unverändert belassen.
[<=]

A_18735 - VZD, Disable I_Directory_Maintenance, wenn dataFromAuthority TRUE

Der VZD DARF Änderungen an VZD-Einträgen über die Schnittstelle I_Directory_Maintenance NICHT zulassen, wenn an dem betroffenen VZD-Eintrag das Attribut dataFromAuthority auf TRUE gesetzt ist.
[<=]

A_18472-01 - VZD, I_Directory_Administration, Doubletten

Der VZD MUSS bei den Operationen add_Directory_Entry und modify_Directory_Entry prüfen, ob die Operation eine Doublette im LDAP-Verzeichnis erzeugt und in diesem Fall die Operation mit HTTP-Fehlercode “400 Bad Request“ ablehnen. Zur Prüfung auf eine potentielle Dublette MUSS der VZD alle LDAP-Directory-Attribute des zu erzeugenden Basisdatensatzes (Verzeichnisdienst_Eintrag ohne Certificate und Fachdaten) jedoch ohne den Distinguished Name heranziehen.
[<=]

A_18602 - VZD, I_Directory_Administration, keine Datenänderung über Maintenance Schnittstelle

Der VZD MUSS Änderungen an Basisdatensätzen und Zertifikatseinträgen (Certificate in Abb_VZD_logisches_Datenmodell) über andere Schnittstellen verhindern, wenn für den jeweiligen Eintrag Daten über die Schnittstelle I_Directory_Administration eingetragen wurden (LDAP-Directory Attribut dataFromAuthority == TRUE).
Nicht erlaubte Änderungen MUSS der VZD mit faultcode 4202 (faultstring: SOAP Request enthält Fehler) ablehnen. [<=]

A_23126 - VZD, I_Directory_Administration, Registrierung, Nutzerrolle

Der VZD-Anbieter MUSS für Clients der Schnittstelle I_Directory_Administration im Registrierungsprozess die Auswahl der Nutzerrolle erlauben:

• VZD:DirectoryRead (Erlaubt nur die Nutzung der GET Operationen der Schnittstelle)
• VZD:DirectoryAdministration (Erlaubt die Nutzung aller Operationen der Schnittstelle)

A_21786 - VZD, I_Directory_Administration, getInfo

Der VZD MUSS Operation „getInfo” gemäß Tabelle Tab_VZD „I_Directory_Administration-Info” umsetzen.

Tabelle 28: Tab_VZD „I_Directory_Administration-getInfo”

A_21789-01 - VZD, Umsetzung I_Directory_Administration (REST)

Der VZD MUSS nach folgenden Vorgaben die Operation implementieren:
In den Rückgabewerten müssen die aktuell gültigen Metainformationen für Schnittstelle I_Directory_Administration zurückgegeben werden. Insbesondere muss

A_18448 - VZD, I_Directory_Administration, add_Directory_Entry

Der VZD MUSS Operation „add_Directory_Entry” gemäß Tabelle Tab_VZD „add_Directory_Entry” umsetzen.

Tabelle 29: Tab_VZD „add_Directory_Entry”

A_20271-02 - VZD, I_Directory_Administration, add_Directory_Entry, holder setzen

Der VZD MUSS bei Operation „add_Directory_Entry” den Eigentümer des erzeugten Verzeichniseintrags im Attribut "holder" entsprechend folgenden Vorgaben setzen: 

•  Ist im add_Directory_Entry Request das Attribut "holder" nicht vorhanden oder enthält keine Werte:
• • Wird vom VZD in dieses Attribut kein Wert (leeres Attribut) eingetragen.
• Ist im add_Directory_Entry Request das Attribut "holder" vorhanden und mit Inhalten gefüllt
• 1. Ist ein Wert aus dem Request Attribut "holder" nicht gültig, MUSS der VZD die Operation mit HTTP-Status-Code 422 abweisen und die weitere Verarbeitung von diesem Request abbrechen.
  2. Sind alle Werte aus dem Request Attribut "holder" gültig, MUSS der VZD die Werte aus dem Request entnehmen und sie in das "holder" Attribut des Verzeichniseintrags übernehmen.

A_21791-01 - VZD, Prüfung auf Typ der Zertifikate

Der VZD MUSS beim Hinzufügen von Zertifikaten mit den Operationen „add_Directory_Entry” und "add_Directory_Entry_Certificate" den Typ der Zertifikate prüfen. Der VZD MUSS alle Operationen mit Zertifikaten ablehnen, die nicht vom Zertifikatstyp C.HCI.ENC oder C.HP.ENC (siehe [gemSpec_OID#Tab_PKI_405-01] sind oder nicht keyUsage = (!digitalSignature && keyEncipherment && dataEncipherment) (siehe [gemSpec_PKI]} GS-A_5532-01) gesetzt ist. Im Falle von unzulässigen Zertifikaten MUSS der VZD mit HTTP-Statuscode 422 (attributeName="userCertificate", attributeError="erläuternder Fehlertext") antworten und darf die gesamte Operation nicht ausführen. [<=]

A_21790-02 - VZD, Prüfung auf Gültigkeit der Zertifikate in der korrekten PKI-Umgebung

Der VZD MUSS beim Hinzufügen von Zertifikaten in der PKI-Umgebung PU mit den Operationen „add_Directory_Entry” und "add_Directory_Entry_Certificate" die Gültigkeit der Zertifikate für diese PKI-Umgebung (PU) prüfen (TUC_PKI_018 mit erfolgreichem Status der Prüfung mit Prüfparametern Offline-Modus=nein; Prüfmodus=OCSP; TOLERATE_OCSP_FAILURE=false ). Die Gültigkeit wird anhand der CA und Prüfung gegen PU-TSL durchgeführt. In der PKI-Umgebung PU dürfen nur die Zertifikate akzeptiert werden, die in dieser Umgebung gültig sind. Gültige Zertifikate aus anderen Umgebungen müssen abgelehnt werden. [<=]

A_21824 - VZD, I_Directory_Administration, stateOrProvinceName Prüfung

Der VZD MUSS vor Ausführung der Operationen „add_Directory_Entry” und "modify_Directory_Entry" den Inhalt von Parameter stateOrProvinceName des Operation Requests gegen die gültigen Werte entsprechend [gemILF_Pflege_VZD#Tabelle TAB_VZD_Wertebereiche_der_Attribute] prüfen, wenn es sich um eine deutsche Adresse handelt (countryCode = DE). Im Falle von ungültigen Werten MUSS der VZD mit HTTP-Statuscode 422 (attributeName="stateOrProvinceName" , attributeError="erläuternder Fehlertext") antworten und darf die Operation nicht ausführen. [<=]

A_18449-03 - VZD, I_Directory_Administration, read_Directory_Entry

Der VZD MUSS Operation „read_Directory_Entry” gemäß Tabelle Tab_VZD „read_Directory_Entry” umsetzen.

Tabelle 30: Tab_VZD „read_Directory_Entry”

A_18450-04 - VZD, I_Directory_Administration, modify_Directory_Entry

Der VZD MUSS Operation „modify_Directory_Entry” gemäß Tabelle Tab_VZD „modify_Directory_Entry” umsetzen.

Tabelle 31: Tab_VZD „modify_Directory_Entry”

A_20272-03 - VZD, I_Directory_Administration, modify_Directory_Entry, Zugriffsrechte

Der VZD MUSS bei Operation „modify_Directory_Entry” für den - über Parameter uid adressierten - Verzeichniseintrag das Attribut "holder" im gespeicherten Verzeichniseintrag und die aktuellen Parameter ("holder" und ACCESS_TOKEN claim scope) der Operation „modify_Directory_Entry” prüfen:

• Wurde im Request Parameters "holder" ein Wert angegeben, der keinen aktuell gültigen Wert für Schnittstelle I_Directory_Administration entspricht, MUSS der VZD die Operation mit HTTP-Status-Code 422 abweisen.
• Wurde im Request Parameters "holder" ein leerer Wert angegeben, MUSS der VZD das Attribut "holder" des Verzeichniseintrags auf einen leeren Wert setzen.

• Ist im Attribut "holder" im gespeicherten Verzeichniseintrags mindestens ein Wert vorhanden
  

• • MUSS der VZD die Operation auszuführen und die übergebenen Werte - nach Prüfung ihrer Gültigkeit - in den Verzeichniseintrag übernehmen wenn der Wert von dem ACCESS_TOKEN claim scope einem Wert des Attributs "holder" des gespeicherten Verzeichniseintrags entspricht. Ist dies nicht der Fall, MUSS der VZD die Operation mit HTTP-Status-Code 401 abweisen.
• Ist im Attribut "holder" im gespeicherten Verzeichniseintrags kein Wert vorhanden und
• • in der Operation „modify_Directory_Entry” wurden Werte für dieses "holder" Attribut übergeben, MUSS der VZD die Operation ausführen und diese Werte - nach Prüfung ihrer Gültigkeit - in den Verzeichniseintrag übernehmen.
  • in der Operation „modify_Directory_Entry” wurde kein Wert für dieses "holder" Attribut übergeben, MUSS der VZD die Operation ausführen und das Attribut "holder" des Verzeichniseintrags unverändert lassen.

A_21823 - VZD, I_Directory_Administration, modify_Directory_Entry, Limit maxKOMLEadr

Der VZD MUSS bei Operation „modify_Directory_Entry” nach erfolgreicher Aktualisierung des VZD-Datensatzes die Anzahl der hinterlegten Mail-Adressen in den KOM-LE Fachdaten mit dem Wert von Attribut maxKOMLEadr vergleichen. Die Anzahl der hinterlegten mail Adressen in den KOM-LE Fachdaten, die den Wert von Attribut maxKOMLEadr übersteigen, MUSS der VZD im Responde der Operation im Header X-maxKOMLEadr-Limit zurückgeben.
[<=]

A_23180 - VZD, I_Directory_Administration, stateSwitch_Directory_Entry

Der VZD MUSS Operation „stateSwitch_Directory_Entry” gemäß Tabelle Tab_VZD „stateSwitch_Directory_Entry” umsetzen.

Tabelle 32: Tab_VZD „stateSwitch_Directory_Entry”

A_18451 - VZD, I_Directory_Administration, delete_Directory_Entry

Der VZD MUSS Operation „delete_Directory_Entry” gemäß Tabelle Tab_VZD „delete_Directory_Entry” umsetzen.

Tabelle 33: Tab_VZD „delete_Directory_Entry”

A_20273-01 - VZD, I_Directory_Administration, delete_Directory_Entry, Zugriffsrechte

Der VZD MUSS bei Operation „delete_Directory_Entry” für den - über Parameter uid adressierten - Verzeichniseintrag das Attribut "holder" im gespeicherten Verzeichniseintrag gegen die aktuellen Parameter der Operation „delete_Directory_Entry” prüfen:

• Enthalten die Werte des Attributs "holder" im gespeicherten Verzeichniseintrag den Wert von dem ACCESS_TOKEN claim scope, MUSS der VZD die Operation ausführen.
• Enthält das Attributs "holder" im gespeicherten Verzeichniseintrag keine Werte, MUSS der VZD die Operation ausführen.
• Enthalten die Werte des Attributs "holder" im gespeicherten Verzeichniseintrag nicht den Wert von dem ACCESS_TOKEN claim scope, MUSS der VZD die Operation mit HTTP-Status-Code 401 abweisen.

A_23181 - VZD, I_Directory_Administration, readLog

Der VZD MUSS Operation „readLog” gemäß Tabelle Tab_VZD „readLog” umsetzen.

Tabelle 34: Tab_VZD „readLog”

A_18452-01 - VZD, I_Directory_Administration, add_Directory_Entry_Certificate

Der VZD MUSS Operation „add_Directory_Entry_Certificate” gemäß Tabelle Tab_VZD „add_Directory_Entry_Certificate” umsetzen.

Tabelle 35: Tab_VZD „add_Directory_Entry_Certificate”

A_18453-01 - VZD, I_Directory_Administration, read_Directory_Certificates

Der VZD MUSS Operation „read_Directory_Certificates” gemäß Tabelle Tab_VZD „read_Directory_Certificates” umsetzen.

Tabelle 36: Tab_VZD „read_Directory_Certificates”

A_18455 - VZD, I_Directory_Administration, delete_Directory_Entry_Certificate

Der VZD MUSS Operation „delete_Directory_Entry_Certificate” gemäß Tabelle Tab_VZD „delete_Directory_Entry_Certificate” umsetzen.

Tabelle 37: Tab_VZD „delete_Directory_Entry_Certificate”

A_21230-03 - VZD, I_Directory_Administration, read_Directory_Entry_for_Sync

Der VZD MUSS Operation „read_Directory_Entry_for_Sync” gemäß Tabelle Tab_VZD „read_Directory_Entry_for_Sync” umsetzen.

Tabelle 38: Tab_VZD „read_Directory_Entry_for_Sync”

A_20402-02 - VZD, I_Directory_Administration, read_Directory_Entry_for_Sync, Paging, Berechtigung

Der VZD MUSS für den Paging Mechanismus von Operation „read_Directory_Entry_for_Sync” sicherstellen:

• Der "holder" Suchparameter muss den gleichen Wert enthalten wie der ACCESS_TOKEN claim scope.
• Die pagingSize darf die Maximalgröße entsprechend TIP1-A_5552 nicht überschreiten.
• Die Suchparameter dürfen sich während eines Pagings (mit mehreren Request/Response Sequenzen) nicht ändern (nur das "cookie" ändert sich). 

A_24058 - VZD, I_Directory_Administration, providedBy

Der VZD MUSS für die Administration von Attribut "providedBy" gewährleisten:

• Es wird nur eine Hierarchieebene unterstützt. Das Attribut "providedBy" im referenzierten LDAP Datensatz muss deshalb leer sein. In allen anderen Fälle MUSS der VZD mit einem Fehler antworten.
• Der VZD MUSS bei Löschung eines LDAP VZD Eintrags prüfen, ob dieser Eintrag über Attribut "providedBy" von einem anderen Datensatz referenziert wird. Ist dies der Fall, MUSS der VZD die Löschoperation mit einem Fehler ablehnen.
• Das Attribut "providedBy" darf nur eine TelematikID enthalten.
• Wenn Attribut providedBy gesetzt wurde, kann es nur zurückgesetzt (Inhalt auf leer gesetzt) werden. Eine Änderung auf einen anderen Wert wird nicht unterstützt.
• Der VZD MUSS vor dem Setzen von Attribut "providedBy" prüfen, ob der Client auch für den referenzierten LDAP Datensatz als Holder eingetragen ist. Ist dies nicht der Fall, MUSS der VZD die Operation mit einem Fehler ablehnen.
  

A_24059 - VZD, I_Directory_Administration, Synchronisationsregeln für verlinkte LDAP Datensätze

Der VZD MUSS für verlinkte LDAP Datensätze - mit einer TelematikID in Attribut "providedBy" - bei der Synchronisation der LDAP Daten in den FHIR VZD - abweichend von den normalen Synchronisationsregeln - das Mapping der Attribute entsprechend Tab_VZD_Datenmapping_linked durchführen.

Tabelle 39: Tab_VZD_Datenmapping_linked

TIP1-A_5607-11 - VZD, logisches Datenmodell

Der VZD MUSS das logische Datenmodell nach Abb_VZD_logisches_Datenmodell und Tab_VZD_Datenbeschreibung implementieren. Es wird keine Vorgabe an die technische Ausprägung des Datenmodells gemacht.
Der VZD MUSS sicherstellen, dass ein Eintrag nur Zertifikate aus dem Vertrauensraum der TI mit gleicher Telematik-ID enthält.

Abbildung 2: Abb_VZD_logisches_Datenmodell

Tabelle 40: Tab_VZD_Datenbeschreibung