IG Diskussion:EFA Spezifikation v2.0

{Auun.01.02}

Unter Fallaktenmanager wird zuerst davon gesprochen, dass der Fallaktenmanager Berechtigungen auf eine Fallakte hat. Im gleichen Abschnitt wird über "verwaiste" Fallakten gesprochen, die keine aktuell gültige Berechtigung mehr ausweisen. Diese verwaisten Fallakten sollen automatisch dem zuständigen Fallaktenmanager "zugeordnet werden". Nach meinem Verständnis ist dies als eine Fallback Regelung für fehlerhaft geführte Fallakten zu verstehen. Es wird aber nur der Fall adressiert, in dem die Berechtigungen der EFA-Teilnehmer fehlen oder abgelaufen sind, ohne dass die Fallakte gelöscht/archiviert wurde, wobei die Berechtigung des Fallaktenmanagers (vor allem wer der zuständige Fallaktenmanager ist) vorhanden ist. Ich würde mir eine Klarstellung wünschen, die es dem Aktenbetreiber ermöglicht einen "Default-Fallaktenmanager" zu definieren, dem über einen ordentlich dokumentierten Prozess die Berechtigung auf eine verwaiste Fallakte erteilt werden kann, wenn der ordentliche Fallaktenmanager nicht zweifelsfrei festgestellt werden kann. (ti, 28.05.2013)

{Pziee.02.01}

Der letzte Satz zur Granularität der Authentisierung verwirrt mich etwas. Ich bin davon ausgegangen dass auch bei Vergabe der Zugriffsrechte auf Organisationsgranularität der individuelle Benutzer in der Assertion mitgeliefert wird (auch wenn er nicht zentral geführt wird und somit nicht weiter verifiziert werden kann). Dies ermöglicht eine weitaus bessere Auditierung, da immer ein individueller Benutzerkontext vorhanden ist. Eine Klarstellung ob Informationen zum Benutzer für Auditzwecke trotzdem benötigt werden, wäre hier sinnvoll (auch wenn dies im späteren Text hoffentlich geklärt wird). (ti, 28.05.2013)

{Pziee.02.02}

Das in 4. als default vorgegebene Policy Push verfahren widerspricht dem im Cookbook verwendetem Verfahren, bei dem der Authorization Decision Provider als PDP die relevanten Policies vom Policy Repository (hier Policy Provider) abfragt. Die Entscheidung basierte auf dem Ziel die Implementierung von Clients zu vereinfachen und einen besseren Schutz der ggf. schützenswerten Policies zu ermöglichen (da beim Cookbook nur der PDP Policies abrufen muss und somit weniger Angriffsfläche besteht). Der Schutz der Policies ist im EFA Kontext wahrscheinlich weniger dringend als im PEPA Kontext (v.a. wegen Blacklisting und krankheitsspezifischen Restriktionen), aber die geringere Implementationslast für Clients sollte auch ein Anliegen des EFA Vereins sein. Die Vorteile des hier gewählten Ansatzes gegenüber dem Cookbook erchliessen sich mir hier noch nicht. (ti, 28.05.2013)

{Pziee.02.04}

Was für Auswirkungen hat die Aussage: "In der Summe bedeutet dies, dass sich ein Provider niemals auf eine Zugriffskontrollentscheidung oder Auswertung einer Einwilligung verlassen darf, die er nicht selbst verantwortet und durchgeführt hat." Ein Provider muss sich ja schon auf die Aussagen von "vertrauenswürdigen" Systemen verlassen: Der Identity Provider kann vom EFA-Teilnehmer betrieben werden. Nicht elektronisch signierte Patientenzustimmungsdokumente die von einem EFA-Teilnehmer kommen werden auch als verlässlich akzeptiert. Ich würde hier einfach berücksichtigen, dass der EFA Provider mit seinen Teilnehmern vertraglich klärt, welches Verhalten von "vertrauenswürdigen" Systemen gefordert ist und wer die Verantwortung bei Abweichungen trägt (bzw. was die Folge von Abweichungen sind). (ti, 28.05.2013)

Namenskürzel

ti

Tarik Idris, InterComponentWare AG
tarik.idris@icw.de