Drei Architekturverschiebungen, die Integratoren unterscheiden sollten
- Hardwareunabhängiger TI-Zugang: Das TI-Gateway gehört zur externen Zugangs- und Betreiberarchitektur. MEMM ersetzt diese Zugangsschicht nicht.
- Digitale Identitäten: Der aktuelle versionsgebundene Entwicklungsstand enthält eine abgegrenzte Identity-Evidence-Adaptergrenze für EUDI Wallet, Health ID und eID-LE.
- Zero Trust: Identität, Attribute, Policy und Ausführung werden als getrennte Kontrollfragen behandelt. ZETA bleibt dabei ein externer TI-2.0-Kontext und wird nicht als MEMM-Implementierung behauptet.
Was die aktuelle Identity-Grenze konkret beschreibt
Externe Identitätsnachweise werden an einer versionierten Profilgrenze in kanonische Identity-Evidence-, Attribut- und Issuer-Trust-Konzepte überführt. Der Trust-Kontext bleibt dabei host- und projektspezifisch gebunden; ein eingehender Nachweis darf seinen eigenen Vertrauensanker nicht selbst festlegen.
Eine erfolgreiche Identitätsprüfung ist ausdrücklich nicht gleichbedeutend mit fachlicher Anwendungsautorisierung. Die Übergabe an eine Autorisierungsentscheidung erfolgt erst an einer getrennten, benannten Kontrollgrenze.
Wo MEMM im TI-2.0-Gesamtbild liegt
MEMM positioniert sich auf der Anwendungs- und Integrationsseite: lokale Headless-Grenzen, versionierte API-/FFI-Verträge, Identity-/Policy-Trennung, Daten-/Profilgrenzen und nachvollziehbare Runtime-Zustände. Externe TI-Zugangs-, Identitäts- und Governance-Dienste behalten ihre eigene Verantwortung und ihren eigenen Lebenszyklus.
Welche TI-2.0-Funktionen daraus nicht abgeleitet werden
- MEMM übernimmt weder die Rolle eines TI-Gateways noch die eines Konnektors.
- Es wird weder eine Integration mit ZETA Client oder ZETA Guard noch eine ZETA-bezogene Konformitätsaussage behauptet.
- Keine Behauptung allgemeiner OIDC-/Federation-Unterstützung.
- Keine Ableitung einer PoPP-, VSDM-2.0-, ePA- oder E-Rezept-Implementierung aus den beschriebenen Identity- und Headless-Grenzen.