Search Authentication Spec Diskrepanz

[christian-frei]

In der neuesten search spec wird folgender GET Request beschrieben.

REQUEST

GET https://fhir-directory-test.vzd.ti-dienste.de/tim-authenticate?mxId=matrix.dev.service-ti.de

HEADER

{
  "User-Agent": "Faraday v2.6.0",
  "Content-Type": "application/json",
  "X-Matrix-OpenID-Token": "matrix-openid-token",
  "X-Matrix-Server-Name": "matrix.dev.service-ti.de"
}

RESPONSE

  {
    "jwt": "tim-authenticate-token",
    "token_type": "bearer",
    "expires_in": 86400
  }

• in der VZD spec "gemSpec_VZD_FHIR_Directory_V1.1.0.pdf" ist das etwas anders beschrieben.

GET /tim-authenticate... (Auth Header mit Matrix-OpenID-Token)

RESPONSE

  {
    "access_token": "search-accesstoken",
    "expires_in": 86400,
    "token_type": "bearer"
  }

• Der query parameter "mxId=" wird dort nicht erwähnt.
  Ich verstehe ihn auch nicht, schliesslich ist ja die userId im subject des Matrix-OpenID-Token enthalten.

• Weiter ist im Usecase Diagram ersichtlich, dass VZD den matrix endpoint GET /openid/userinfo/ aufruft, davon steht nichts in der search spec

• Aus der VZD spec "gemSpec_VZD_FHIR_Directory_V1.1.0.pdf" ist folgende Struktur des SearchTokens ersichtlich, ist die korrekt? Wenn ja, könnten sie die ja in die search spec aufnehmen, zum einfacheren und vollständigen Verständnis (v.a. wenn man seinen eigenen VZD mock baut)

  {
    "iss": "https://fhir-directory.vzd.ti-dienste.de/tim-authenticate",
    "aud": [ "https://fhir-directory.vzd.ti-dienste.de/search"], 
    "iat": 1630306800,
    "exp": 1630393200
  }

[ichderjens]

Hallo,

wir möchten Sie bitten sich an dieser Stelle die Dokumentation im Branch anzusehen, in dem wir die TIM 1.1.1 Anpassungen im Moment ausarbeiten.
https://github.com/gematik/api-ti-messenger/blob/feature/C_11306/docs/changes/TI-Messenger_v1.1_changes_deu.adoc#cr_001-korrektur-der-parameter-am-fhir-directory-tim-authenticate-endpoint

Sollten nach dem Lesen sich bei Ihnen weiterhin Fragen ergeben, kommen Sie gern erneut auf uns zu.

[christian-frei]

Danke für den Link. Ich studiere es und werde allenfalls neue Fragen dazu posten.

Auf meine bisherigen Fragem gibt die neue Spec allerdings keine Antwort:

• Warum wird im GET https://fhir-directory-test.vzd.ti-dienste.de/tim-authenticate?mxId=matrix.dev.service-ti.de Request eine mxId mitgegeben? Schliesslich ist ja die userId im subject des Matrix-OpenID-Token enthalten. Ausserdem der value in ihrem Bespiel keine mxid, sondern ein domain-name.

• Weiter ist im Usecase Diagram ersichtlich, dass VZD den matrix endpoint GET /openid/userinfo/ aufruft, davon steht nichts in der search spec

• Aus der VZD spec "gemSpec_VZD_FHIR_Directory_V1.1.0.pdf" ist folgende Struktur des SearchTokens ersichtlich, ist die korrekt? Wenn ja, könnten sie die ja in die search spec aufnehmen, zum einfacheren und vollständigen Verständnis (v.a. wenn man seinen eigenen VZD mock baut)

Können Sie mir die bitte beantworten?

Die neuen Fragen:

• im Kapitel Search parameters schreiben sie alle parameter lower-case, z.B. practitioner.active=true
  In der HL7 Practitioner spec werden jedoch alle Anfangsbuchstaben gross geschrieben, z.B. Practitioner.active
• Unter FHIR VZD Search - HealtcareService by telematikID geben sie die telematik id so mit &organization.identifier=1-2arvtst-ap000052
  In der HL7 Token spec wird jedoch folgende Syntax beschrieben [parameter]=[system]|[code].
  Also sollte der queryParam eigentlich so aussehen &Organization.identifier=https://gematik.de/fhir/sid/telematik-id|9-2.58.00000040

[ichderjens]

Hallo,

• Wir sind uns der Verwirrung mit der MXID bewusst und eine Anpassung des Parameters ist auch bereits im Backlog. Der Parameter ist dazu gedacht, dass Sie hier den Homeserver übergeben, der den Matrix-OpenID Token ausgestellt hat. Den Token übergeben Sie über das Header Feld "X-Matrix-OpenID-Token".
• Ja das VZD ruf den entsprechenden Endpunkt am Homeserver auf, um den Token auf Gültigkeit prüfen zu können.
• Header: {
  "typ": "JWT",
  "alg": "ES256"
  }
  {
  "iss": "https://{servername}/tim-authenticate",
  "aud": "https://{servername}/search",
  "sub": "{matrixid des User von dem der OpenID Token war}",
  "iat": 1677677901,
  "exp": 1677764301
  }
• Die Parameter sind in lowercase anzugeben. In ihrem Beispiel mit dem active bezieht sich die Anfrage nicht auf die Practitioner Ressource, sondern der Einstiegspunkt ist die PractitionerRole und dann deren Feld für die Practitioner Referenz und dessen Feld active
• Zu diesem Thema forschen wir gern nach welche Art der Suchanfragen der HAPI Server unterstützt.

[spilikin]

Laut FHIR Spezifikation kann man sowohl mit als auch ohne CodeSystem suchen:
https://build.fhir.org/search.html#token

• [parameter]=[code]: the value of [code] matches a Coding.code or Identifier.value irrespective of the value of the system property
• [parameter]=[system]|[code]: the value of [code] matches a Coding.code or Identifier.value, and the value of [system] matches the system property of the Identifier or Coding

Suche ohne CodeSystem funktioniert zwar für unseren Use-Case, weil alle bisherigen Identifier nicht kollidieren. Natürlich ist es deutlich präziser und zuverlässiger mit dem CodeSystem zu suchen (s. unten). Funktioniert tut beides.

/search/HealthcareService?organization.active=true&_count=1&_include=HealthcareService:organization&organization.identifier=https://gematik.de/fhir/sid/telematik-id%7C1-SMC-B-Testkarte-883110000096089

[Johennes]

Da es hier keine Rückmeldung mehr gab, gehe ich davon aus, dass die Unklarheit behoben ist.