diff --git a/docs/Client/Client.adoc b/docs/Client/Client.adoc index db6d3b61..55445ed4 100644 --- a/docs/Client/Client.adoc +++ b/docs/Client/Client.adoc @@ -51,7 +51,7 @@ CAUTION: Der Playground bildet immer die aktuellste Version der Matrix-Spezifika Im Rahmen der Verwendung des Matrix-Protokolls im deutschen Gesundheitswesen ist es notwendig, dies um zusätzliche Vorgaben zu erweitern. Hierzu trifft die gematik die folgenden weiteren Festlegungen zum Umgang mit dem Matrix-Protokoll. ====== CreateRoom -Beim Anlegen eines Raumes über den `/_matrix/client/v3/createRoom` Endpunkt (siehe: link:https://spec.matrix.org/v1.3/client-server-api/#post_matrixclientv3createroom[createRoom]) über die [Client-Server-API] ist darauf zu achten, dass im `invite`-Feld maximal eine Matrix-ID (`MXID`) eines einzuladenden Akteurs angegeben werden darf. Die Vorgabe muss eingehalten werden, damit diese bei der link:../../docs/anwendungsfaelle/MS-stufen-berechtigungspruefung.adoc#stufe-1-pr%C3%BCfung-der-ti-f%C3%B6derationszugeh%C3%B6rigkeit[Proxy Berechtigungsprüfung] validiert werden kann. +Beim Anlegen eines Raumes über den `/_matrix/client/v3/createRoom` Endpunkt (siehe: link:https://spec.matrix.org/v1.3/client-server-api/#post_matrixclientv3createroom[createRoom]) über die [Client-Server-API] ist darauf zu achten, dass im `invite`-Feld maximal eine Matrix-ID (`MXID`) eines einzuladenden Akteurs angegeben werden darf. Die Vorgabe muss eingehalten werden, damit diese bei der Proxy Berechtigungsprüfung validiert werden kann. ====== Custom Room Types Das Matrix-Protokoll erlaubt während der Erstellung eines Chatraumes einen eigene Raumtyp (_Custom Room Type_) für diesen mit Hilfe einer Typinitialisierung im `/createRoom`-Endpunkt zu definieren, um spezielle Raumeigenschaften (_Room State Events_) für diesen _Custom Room Type_ zu verwenden. Die gematik definiert für föderierte und fallbezogene Kommunikation die folgenden Raumtypen. @@ -83,7 +83,7 @@ TIP: Weitere Informationen zu den _Custom State Events_ können in *[gemSpec_Ti- NOTE: In der veröffentlichten und zulassungsrelevanten Spezifikationsversion v1.1.1 wird die produktive Verwendung der _Custom State Events_ aktuell nicht gefordert, da die notwendigen Vorbedingungen für den produktiven Einsatz seitens des Matrix-Protokolls noch nicht vollständig erfüllt sind. ===== I_TiMessengerContactManagement -Über die vom *Messenger-Proxy* bereitgestellte Schnittstelle `I_TiMessengerContactManagement` wird die für einen Akteur im Proxy vorgehaltene Freigabeliste administriert. Die Freigabeliste wird in link:/docs/anwendungsfaelle/COM-AF10061-einladung-ausserhalb.adoc[AF10061 - Einladung von Akteuren außerhalb einer Organisation] benötigt, wenn zwei Akteure ihre Kontaktdaten mittels QR-Scan austauschen möchten. Weitere Informationen zu der Schittstelle sind link:../../docs/Fachdienst/MessengerService.adoc#i_timessengercontactmanagement[hier] zu finden. +Über die vom *Messenger-Proxy* bereitgestellte Schnittstelle `I_TiMessengerContactManagement` wird die für einen Akteur im Proxy vorgehaltene Freigabeliste administriert. Die Freigabeliste wird bei der Einladung von Akteuren außerhalb einer Organisation benötigt, wenn zwei Akteure ihre Kontaktdaten mittels QR-Scan austauschen möchten. Weitere Informationen zu der Schittstelle sind link:../../docs/Fachdienst/MessengerService.adoc#i_timessengercontactmanagement[hier] zu finden. ==== VZD-FHIR-Directory Modul Über das _VZD-FHIR-Directory Modul_ wird die Suche und die Pflege von Einträgen im *FHIR-Directory* ermöglicht. Hier werden die folgenden Endpunkte der Teilkomponenten *Auth-Services* und *FHIR-Proxy* des *VZD-FHIR-Directory* vom _VZD-FHIR-Directory Modul_ des *TI-Messenger-Clients* angesprochen: @@ -104,7 +104,7 @@ Der *Auth-Service* des *VZD-FHIR-Directory* bietet die zwei Endpunkte an, die di Für den Zugriff auf die Suchfunktionalität von FHIR-Ressourcen (`/search`-Endpunkt) authentisiert sich der *TI-Messenger-Client* gegenüber dem *VZD-FHIR-Directory* mit einem 3rd-Party-Token (`Matrix-OpenID Token`), das er von seinem *Matrix-Homeserver* anfordern kann (siehe link:https://spec.matrix.org/v1.3/client-server-api/#post_matrixclientv3useruseridopenidrequest_token[Matrix OpenID Token]). Dieses 3rd-Party-Token benötigt der *TI-Messenger-Client*, um es beim `/tim-authenticate`-Endpunkt des *VZD-FHIR-Directory* gegen ein `search-accesstoken` einzutauschen. Bei Aufruf des Endpunktes `/tim-authenticate` ist es erforderlich, das 3rd-Party-Token (`Matrix-OpenID-Token`) im Header sowie die URL des *Matrix-Homeservers* im Parameter `MXID` zu übergeben. Der Aufruf des `/tim-authenticate`-Endpunktes ist link:https://github.com/gematik/api-vzd/blob/gemILF_VZD_FHIR_Directory/1.0.0/docs/FHIR_VZD_HOWTO_Authenticate.adoc#21-authenticate-for-the-search-endpoint[hier] beschrieben. ====== /owner-authenticate -Für die Pflege von FHIR-Ressourcen (`/owner`-Endpunkt) authentisiert sich der *TI-Messenger-Client* gegenüber dem *VZD-FHIR-Directory* unter Verwendung einer Smartcard (HBA), um ein `owner-accesstoken` vom *Auth-Service* zu erhalten. Für die Authentisierung mittels Smartcard ist der von der gematik bereitgestellte link:/docs/IDP/idp.adoc[zentrale IDP-Dienst] zu verwenden. Details sind dem Anwendungsfall link:/docs/anwendungsfaelle/VZD-AF10058-practitioner-hinzufuegen.adoc[AF10058 - Akteur (User-HBA) im Verzeichnisdienst hinzufügen] zu entnehmen. Nach erfolgreicher Authensierung erhält der *TI-Messenger-Client* vom *Auth-Service* ein `owner-accesstoken`. Der Aufruf des `/owner-authenticate`-Endpunktes ist link:https://github.com/gematik/api-vzd/blob/gemILF_VZD_FHIR_Directory/1.0.0/docs/FHIR_VZD_HOWTO_Authenticate.adoc#24-authenticate-for-the-owner-endpoint-as-an-user[hier] beschrieben. +Für die Pflege von FHIR-Ressourcen (`/owner`-Endpunkt) authentisiert sich der *TI-Messenger-Client* gegenüber dem *VZD-FHIR-Directory* unter Verwendung einer Smartcard (HBA), um ein `owner-accesstoken` vom *Auth-Service* zu erhalten. Für die Authentisierung mittels Smartcard ist der von der gematik bereitgestellte link:/docs/IDP/idp.adoc[zentrale IDP-Dienst] zu verwenden. TIP: Für die Interaktion mit den Smartcards und dem *zentralen IDP-Dienst* ist der link:https://fachportal.gematik.de/hersteller-anbieter/komponenten-dienste/authenticator[gematik authenticator] vorgesehen. Es können auch eigene Authenticator-Lösungen verwendet werden. @@ -120,7 +120,7 @@ Der *FHIR-Proxy* bietet über die Schnittstelle `FHIRDirectorySearchAPI` den End Der *FHIR-Proxy* bietet über die Schnittstelle `FHIRDirectoryOwnerAPI` den Endpunkt `/owner` an, um FHIR-Ressourcen zu suchen und eigene Einträge zu pflegen. Um diesen Endpunkt aufrufen zu können, wird ein `owner-accesstoken` im Authorization Header benötigt. Eine beispielhafte Verwendung der Schnittstelle zur Pflege der FHIR-Ressourcen ist in link:https://github.com/gematik/api-vzd/blob/gemILF_VZD_FHIR_Directory/1.0.0/docs/FHIR_VZD_HOWTO_Owner.adoc[owner API examples] beschrieben. ==== Auth Modul -Über das _Auth Modul_ wird die Kommunikation mit Smartcards (HBA) realisiert, um diese zur Authentisierung am `/owner-authenticate`-Endpunkt zu ermöglichen. Dies wird als Grundlage für den Anwendungsfall link:/docs/anwendungsfaelle/VZD-AF10058-practitioner-hinzufuegen.adoc[AF_10058 Akteur(User-HBA) im Verzeichnisdienst hinzufügen] benötigt. Im Folgenden wird der Prozess kurz skizziert, nachdem beim Aufruf des `/owner-authenticate`-Endpunktes das _Auth Modul_ einen `Redirect` zum `Authorization Endpoint` des *IDP-Dienstes* vom *Auth-Service* erhalten hat. +Über das _Auth Modul_ wird die Kommunikation mit Smartcards (HBA) realisiert, um diese zur Authentisierung am `/owner-authenticate`-Endpunkt zu ermöglichen. Im Folgenden wird der Prozess kurz skizziert, nachdem beim Aufruf des `/owner-authenticate`-Endpunktes das _Auth Modul_ einen `Redirect` zum `Authorization Endpoint` des *IDP-Dienstes* vom *Auth-Service* erhalten hat. ===== Authorization Endpoint zentraler IDP-Dienst Nach Erhalt des `Redirects` ruft das _Auth Modul_ des *TI-Messenger-Clients* den `{Authorization Endpoint}` am *zentralen IDP-Dienst* auf, um das Challenge-Response-Verfahren durchzuführen und abschließend den `AuthorizationCode` sowie den `Redirect` zum `/signin-gematik-idp-dienst`-Endpunkt zu erhalten. @@ -151,7 +151,7 @@ Der Aufbau der `Matrix-URI` muss gemäß link:https://spec.matrix.org/v1.3/appen TIP: Bei dem gezeigten vCard-Object handelt es sich um die geforderte Mindestbefüllung, die Verwendung weiterer Felder ist zulässig. -Der *TI-Messenger-Client* muss den eingescannten 2D-Code gemäß [ISO/IEC 18004:2006] decodieren und mindestens den vollständigen Namen sowie die `MXID` aus den Parameter `N` und `IMPP` dem Akteur anzeigen, damit dieser die Aufnahme in die Freigabeliste bestätigen oder ablehnen kann (siehe link:/docs/anwendungsfaelle/COM-AF10061-einladung-ausserhalb.adoc[AF_10061 - Einladung von Akteuren außerhalb einer Organisation]). +Der *TI-Messenger-Client* muss den eingescannten 2D-Code gemäß [ISO/IEC 18004:2006] decodieren und mindestens den vollständigen Namen sowie die `MXID` aus den Parameter `N` und `IMPP` dem Akteur anzeigen, damit dieser die Aufnahme in die Freigabeliste bestätigen oder ablehnen kann. ==== Editierbarkeit von Displaynamen Der *TI-Messenger-Client* muss bei der initialen Vergabe des Displayname die folgende Bildungsregel durchsetzen: `[Name], [Vorname]`. Der *TI-Messenger-Client* darf dem Akteur nach der initialen Vergabe des Displaynamen nicht die Möglichkeit anbieten, diesen zu ändern. Hierfür darf der *TI-Messenger-Client* nicht die REST-Schnittstelle `/_matrix/client/v3/profile/{userId}/displayname` der [Client-Server API] aufrufen. @@ -172,7 +172,7 @@ Mit dem *Org-Admin-Client* haben Administratoren einer Organisation die Möglich * Einrichtung von Funktionsaccounts. ==== Organisationsressourcen im VZD-FHIR-Directory bearbeiten -Der Administrator einer Organisation (in der Rolle "Org-Admin") verwaltet mittels des *Org-Admin-Clients* die FHIR-Ressourcen für seine Organisation im *VZD-FHIR-Directory* (siehe link:/docs/anwendungsfaelle/VZD-AF10059-organisation-hinzufuegen.adoc[AF_10059 - Organisationsressourcen im Verzeichnisdienst hinzufügen]). +Der Administrator einer Organisation (in der Rolle "Org-Admin") verwaltet mittels des *Org-Admin-Clients* die FHIR-Ressourcen für seine Organisation im *VZD-FHIR-Directory*. *Authentisierung* diff --git a/docs/Fachdienst/MessengerService.adoc b/docs/Fachdienst/MessengerService.adoc index 3cd1cb35..ed6e9e01 100644 --- a/docs/Fachdienst/MessengerService.adoc +++ b/docs/Fachdienst/MessengerService.adoc @@ -41,15 +41,15 @@ TIP: Mit der zukünftigten Unterstützung von link:https://areweoidcyet.com[OIDC ==== I_TiMessengerContactManagement Der *Messenger-Proxy* muss die Schnittstelle `I_TiMessengerContactManagement` als REST-Webservice über HTTPS gemäß link:/src/openapi/TiMessengerContactManagement.yaml[TiMessengerContactManagement.yaml] umsetzen, um den *TI-Messenger-Clients* die Verwaltung einer persönlichen Freigabeliste zu ermöglichen. -Die Schnittstelle findet u.a. Verwendung in link:/docs/anwendungsfaelle/COM-AF10061-einladung-ausserhalb.adoc[AF_10061 - Einladung von Akteuren außerhalb einer Organisation]. +Die Schnittstelle findet u.a. Verwendung bei der Einladung von Akteuren außerhalb einer Organisation. === Berechtigungsprüfung -Die Berechtigungsprüfung findet bei der Client-Server Kommunikation sowie bei der Server-Server Kommunikation statt (siehe link:/docs/anwendungsfaelle/MS-stufen-berechtigungspruefung.adoc[Stufen der Berechtigungsprüfung]). +Die Berechtigungsprüfung findet bei der Client-Server Kommunikation sowie bei der Server-Server Kommunikation statt. === Betriebliche Aspekte ==== Abruf und Signaturprüfung der Föderationsliste Eine aktuelle Version der Föderationsliste wird vom *Messenger-Proxy* über die Schnittstelle `I_internVerification` abgerufen. Der Abruf erfolgt entweder zyklisch über ein vom Anbieter definiertes Intervall oder im Rahmen der Föderationsprüfung, wenn eine Domain in der aktuell vorliegenden Liste nicht enthalten ist. -Der *Messenger-Proxy* muss sicherstellen, dass die vom *Registrierungs-Dienst* bereitgestellte Föderationsliste valide ist. Hierzu muss der *Messenger-Proxy* die Signatur der Föderationsliste unter Verwendung des mitgelieferten Signaturzertifikates (`x5c`-Header) überprüfen (siehe link:/docs/anwendungsfaelle/MS-aktualisierung-foederationsliste.adoc[Aktualisierung der Föderationsliste]). +Der *Messenger-Proxy* muss sicherstellen, dass die vom *Registrierungs-Dienst* bereitgestellte Föderationsliste valide ist. Hierzu muss der *Messenger-Proxy* die Signatur der Föderationsliste unter Verwendung des mitgelieferten Signaturzertifikates (`x5c`-Header) überprüfen. ==== .well-known & userinfo Für bestimmte Funktionalitäten ist es notwendig, dass Anfragen nicht durch die Berechtigungsprüfung des *Messenger-Proxys* abgelehnt werden. So muss eine Anfrage des *VZD-FHIR-Directory* an die link:https://spec.matrix.org/v1.3/server-server-api/#getwell-knownmatrixserver[.well-known] Datei erlaubt sein, um einen eigenen Port für Anfragen des *VZD-FHIR-Directoy* zu hinterlegen, um später über diesen Port den `/_matrix/federation/v1/openid/userinfo`-Endpunkt aufzurufen. Hierzu muss der *Messenger-Proxy* ebenfalls den Zugriff erlauben, damit das *VZD-FHIR-Directory* einen `Matrix-OpenID-Token` prüfen lassen kann. diff --git a/docs/Fachdienst/Registrierungsdienst.adoc b/docs/Fachdienst/Registrierungsdienst.adoc index c1cc18e5..9b8ae213 100644 --- a/docs/Fachdienst/Registrierungsdienst.adoc +++ b/docs/Fachdienst/Registrierungsdienst.adoc @@ -28,8 +28,8 @@ image::generated/TI-M_Basis/Schnittstellen_am_Registrierungs-Dienst.svg[align="c == Schnittstelle: I_Registration Die abstrakte Schnittstelle `I_Registration` muss die folgenden Funktionalitäten anbieten: -* Die Authentisierung einer Organisation am *TI-Messenger-Dienst* (siehe link:{docsdir}/anwendungsfaelle/MS-AF10103-authentisieren-organisation.adoc[AF_10103]) und -* Die Möglichkeit der Bereitstellung eines *Messenger-Services* für eine Organisation (siehe link:{docsdir}/anwendungsfaelle/MS-AF10060-bereitstellung-messenger-service.adoc[AF_10060]) +* Die Authentisierung einer Organisation am *TI-Messenger-Dienst* +* Die Möglichkeit der Bereitstellung eines *Messenger-Services* für eine Organisation CAUTION: Für die initiale Registrierung einer Organisation am *TI-Messenger-Fachdienst* ist die Verwendung der SMC-B notwendig und somit die Verwendung von einem Konnektor und Kartenterminal Voraussetzung. @@ -39,7 +39,7 @@ Im folgenden werden die umzusetzenden Funktionalitäten der Schnittstelle beschr Die von der abstrakten Schnittstelle `I_Registration` angebotene Funktionalität soll als Webschnittstelle bereitgestellt werden, die von einem Akteur über einen Webclient (*Frontend des Registrierungs-Dienstes*) genutzt wird. Diese muss für alle Akteure im Internet verfügbar sein. === Authentisieren einer Organisation -Die abstrakte Schnittstelle `I_Registration` muss es einer Organisation ermöglichen sich mittels der SMC-B der Organisation zu authentisieren. Der *Registrierungs-Dienst* kann hierfür einen Prozess mittels OpenID-Connect oder KIM anbieten. In beiden Varianten muss der *Registrierung-Dienst* die `TelematikID` und auch die `ProfessionOID` der Organisation validieren & speichern. Nach erfolgreicher Authentifizierung durch den *Registrierungs-Dienst* wird ein Administratorkonto für die Organisation bereitgestellt. Weitere Details finden Sie unter link:{docsdir}/anwendungsfaelle/MS-AF10103-authentisieren-organisation.adoc[AF_10103]. +Die abstrakte Schnittstelle `I_Registration` muss es einer Organisation ermöglichen sich mittels der SMC-B der Organisation zu authentisieren. Der *Registrierungs-Dienst* kann hierfür einen Prozess mittels OpenID-Connect oder KIM anbieten. In beiden Varianten muss der *Registrierung-Dienst* die `TelematikID` und auch die `ProfessionOID` der Organisation validieren & speichern. Nach erfolgreicher Authentifizierung durch den *Registrierungs-Dienst* wird ein Administratorkonto für die Organisation bereitgestellt. === Bereitstellung eines Messenger-Service Nach dem Authentifizierungsvorgang muss das bereitgestellte Admin-Konto verwendet werden, um *Messenger-Services* für die Organisation zu erstellen. Um einen neuen *Messenger-Service* zu erstellen, muss ein *Registrierungs-Dienst*: @@ -94,7 +94,7 @@ Bei der Schnittstelle `I_internVerification` handelt es sich um eine abstrakte S Die Schnittstelle muss die folgenden Funktionalitäten bereitstellen: * Bereitstellung und Aktualisierung der Föderationsliste und -* Berechtigungsprüfung - Stufe 3 gemäß link:../anwendungsfaelle/MS-stufen-berechtigungspruefung.adoc[Berechtigungskonzept] +* Berechtigungsprüfung - Stufe 3 TIP: Die geforderten Funktionalitäten dürfen auch über seperate Schnittstellen zur Verfügung gestellt werden. @@ -103,8 +103,6 @@ Die umzusetzenden Funktionalitäten werden im folgenden beschrieben. === Bereitstellung und Aktualisierung der Föderationsliste. Um die Zugehörigkeit zur TI-Messenger-Föderation zu verifizieren, muss der *Registrierungs-Dienst* den *Messenger-Proxies* über die abstrakte Schnittstelle `I_internVerification` eine aktuelle Föderationsliste zur Verfügung stellen. Dazu muss der *Registrierungs-Dienst* die Operation `/tim-provider-services/getFederationList` am *FHIR-Proxy* des *VZD-FHIR-Directory* aufrufen, um eine aktuelle Föderationsliste zu erhalten. Diese Schnittstelle ist am *VZD-FHIR-Directory* durch einen `ACCESS_TOKEN` geschützt (https://github.com/gematik/api-vzd/blob/gemILF_VZD_FHIR_Directory/1.0.1/docs/FHIR_VZD_HOWTO_Authenticate.adoc#22-authenticate-for-the-provider-api[provider-accesstoken]). Nach Erhalt des `provider-accesstokens` muss dieses im Authorization Header genutzt werden, um über die Operation https://github.com/gematik/api-vzd/blob/gemILF_VZD_FHIR_Directory/1.0.1/docs/FHIR_VZD_HOWTO_Provider.adoc#22-query-federationlist[getFederationList] eine aktuelle Föderationsliste abzufragen. -TIP: Der Ablauf des Anwendungfalls zur Aktualisierung und Bereitstellung kann im Detail link:../anwendungsfaelle/MS-aktualisierung-foederationsliste.adoc[hier] nachvollzogen werden. - Die aktuelle Struktur der Föderationsliste ist https://github.com/gematik/api-vzd/blob/gemILF_VZD_FHIR_Directory/1.0.1/src/schema/FederationList.json[hier] hinterlegt. Im folgenden ist ein Beispiel für den Aufbau der Föderationsliste gezeigt: diff --git a/docs/IDP/idp.adoc b/docs/IDP/idp.adoc index 20abfcee..3a6d14e0 100644 --- a/docs/IDP/idp.adoc +++ b/docs/IDP/idp.adoc @@ -22,12 +22,7 @@ toc::[] == Überblick Der zentrale *IDP-Dienst* der gematik (*[gemSpec_IDP_Dienst]*) ermöglicht die sichere Identifikation der Akteure anhand der ihnen bereitgestellten Identifikationsmittel einer Smartcard (SMC-B / HBA). Hierfür fasst der *IDP-Dienst*, die im AUT-Zertifikat befindlichen Attribute in signierten JSON Web Token (`ID_TOKEN`) zusammen und stellt diese der anfragenden *Relying Party* aus. Im Kontext des *TI-Messenger-Dienstes* übernimmt der *Registrierungs-Dienst* eines *TI-Messenger-Fachdienstes* sowie der *Auth-Service* des *VZD-FHIR-Directory* die Rolle der *Relying Party*, welche einen `ID_TOKEN` beim *IDP-Dienst* anfragt. -Der zentrale *IDP-Dienst* der gematik wird im Rahmen des *TI-Messenger-Dienstes* in den folgenden Anwendungsfällen benötigt: - -* link:https://github.com/gematik/api-ti-messenger/blob/feature/C_11306/docs/anwendungsfaelle/MS-AF10103-authentisieren-organisation.adoc[AF_10103 - Authentisieren einer Organisation am TI-Messenger-Dienst] -* link:https://github.com/gematik/api-ti-messenger/blob/feature/C_11306/docs/anwendungsfaelle/VZD-AF10058-practitioner-hinzufuegen.adoc[AF_10058 - Akteur (User-HBA) im Verzeichnisdienst hinzufügen] - -In den folgenden Kapiteln werden die notwendigen Maßnahmen / Abläufe beschrieben, um die in den Anwendungsfällen geforderte Authentifizierung via OpenID Connect durchführen zu können. +In den folgenden Kapiteln werden die notwendigen Maßnahmen / Abläufe beschrieben, um die in der Spezifikation geforderte Authentifizierung via OpenID Connect durchführen zu können. == Registrierung der Relying Party am IDP-Dienst Im Rahmen des *TI-Messenger-Dienstes* ist es notwendig, dass der *TI-Messenger-Anbieter* einer *Relying Party* (*Registrierungs-Dienst*) diesen beim zentralen *IDP-Dienst* der gematik registriert, um von diesem `ID_TOKEN` ausgestellt zu bekommen. Die Registrierung der *Relying Party* erfolgt hierbei als organisatorischer Prozess (siehe bitte https://gematikde.sharepoint.com/:w:/s/PTNeo/EczX7AFGfBdNrCYghzGsHz4BbSoYhV63QMmDCdz7x9zLpg?e=7wG3c[Welcome Package] 5. Schritt). @@ -321,7 +316,7 @@ TIP: Der Token-Endpunkt DARF `ID_TOKEN` mit einer Gültigkeitsdauer von mehr als Im ersten Schritt entschlüsselt die *Relying Party* das `ID_TOKEN` mit seinem selbst erzeugten 256-Bit AES-Schlüssel (`Token-Key`). Anschließend erfolgt die Signaturprüfung mit dem `PuK_IDP_SIG` des *IDP-Dienstes*. == Authorization Code Flow -In dem folgenden Sequenzdiagramm ist beispielhaft der Ablauf des Authorization Code Flow für den Anwendungsfall link:https://github.com/gematik/api-ti-messenger/blob/feature/C_11306/docs/anwendungsfaelle/MS-AF10103-authentisieren-organisation.adoc[AF_10103 - Authentisieren einer Organisation am TI-Messenger-Dienst] dargestellt. Im Kontext des *TI-Messenger-Dienstes* ist der *Registrierungs-Diens* die *Relying Party*. Als *Authenticator* wird der von der gematik bereitgestellte *Authenticator* verwendet. +In dem folgenden Sequenzdiagramm ist beispielhaft der Ablauf des Authorization Code Flow für den Anwendungsfall dargestellt. Im Kontext des *TI-Messenger-Dienstes* ist der *Registrierungs-Diens* die *Relying Party*. Als *Authenticator* wird der von der gematik bereitgestellte *Authenticator* verwendet. CAUTION: Der von der gematik bereitgestellte Authenticator wird nicht in Verbindung mit einer Web-Anwendung empfohlen, da vom Authenticator ein neuer Browser Tab geöffnet wird. Entsprechend der Fachanwendung wird im Browser eine HTML-Seite oder ein Json-Objekt(VZD-FHIR Response) angezeigt. diff --git a/docs/Test/Test.adoc b/docs/Test/Test.adoc index 8bcf4684..625abf2f 100644 --- a/docs/Test/Test.adoc +++ b/docs/Test/Test.adoc @@ -100,7 +100,7 @@ image:generated/Other/Test/testumgebung-Hersteller.svg[align="left",width="100%" == Zulassung === Zulassungstests durch die gematik -Die gematik testet im Rahmen der Zulassungsverfahren auf Basis von Anwendungsfällen. Dabei wird sich auf die link:{docsdir}anwendungsfaelle/TI-Messenger-Anwendungsfaelle.adoc [Anwendungsfälle] bezogen. Hierbei wird versucht, möglichst viele Funktionsbereiche der Komponenten des TI-Messenger-Dienstes (TI-M Dienst) einzubeziehen. +Die gematik testet im Rahmen der Zulassungsverfahren auf Basis von Anwendungsfällen. Hierbei wird versucht, möglichst viele Funktionsbereiche der Komponenten des TI-Messenger-Dienstes (TI-M Dienst) einzubeziehen. ==== Tests gegen die Referenzimplementierung Die Tests werden zunächst gegen die Referenzimplementierung der gematik durchgeführt. In diesem Schritt wird die Funktionalität des Zulassungsobjektes "TI-Messenger-Dienst" geprüft. diff --git a/docs/anwendungsfaelle/TI-Messenger-Anwendungsfaelle.adoc b/docs/anwendungsfaelle/TI-Messenger-Anwendungsfaelle.adoc deleted file mode 100644 index 014a1ab4..00000000 --- a/docs/anwendungsfaelle/TI-Messenger-Anwendungsfaelle.adoc +++ /dev/null @@ -1,26 +0,0 @@ -ifdef::env-github[] -:tip-caption: :bulb: -:note-caption: :information_source: -:important-caption: :heavy_exclamation_mark: -:caution-caption: :fire: -:warning-caption: :warning: -endif::[] - -:imagesdir: ../../images -:toc: macro -:toclevels: 3 -:toc-title: Inhaltsverzeichnis -:numbered: - -image:meta/gematik_logo.svg[width=70%] - -toc::[] - -= Anwendungsfälle -Die folgende Seite gibt einen Überblick über die Anwendungsfälle des *TI-Messengers* aus den Spezifikationen für die Produkte *TI-M ePA*, *TI-M Pro* und *TI-M Connect*. - -== Anwendungsfälle TI-M ePA - -== Anwendungsfälle TI-M Pro - -== Anwendungsfälle TI-M Connect