cdaefa Diskussion:EFA Security Informationsmodell

Kommentare

ID	Author	Status	Section	Vote	Existing	Proposed	Comment	Comment Editor	Discussion
110	mr	included	Eecim.02.01 : context		Zugruffsberechtigungen	Zugriffsberechtigungen
111	mr	included	Eecim.02.01 : context		EWFA	EFA
112	fo	rejected	Eecim.02.02 : subjectIdentity				Die Inkonsistenz zum Cookbook muss ausgeräumt werden, da ansonsten der Profilieruingsmechanismus nicht greift. Die einfachste Variante dürfte daher sein, diesen Mechanismus im Cookbook als optional aber empfohlen zu beschreiben.	Im Cookbook als optional definieren
113	ti	rejected	Eecim.02.02 : subjectIdentity				"Sofern in der EFA-Einwilligung eines Patienten Organisationen bzw. Organisationseinheiten als EFA-Teilnehmer benannt sind, muss der subjectIdentity-Nachweis weiter Informationen enthalten" Ich würde eine explizite Pflicht zur Organisations-ID vorziehen. Die hier zitierte Regel hiesse das der Identity Provider wissen muss wie die EFA Einwilligung strukturiert ist, d.h. ob darin nur Individuen oder auch Organisationen berechtigt werden (Sofern ... muss ...). Es muss ja auch nicht unbedingt eine OID sein. (ti, 29.05.2013)	"Wenn der in der Einwilligung benannte berechtigte Teilnehmer eine Organisation(seinheit) ist, muss in der subjectIdentity ein eindeutiger Identifier der Organisation enthalten sein, der der Aufrufer angehört."	Berechtigung der Organisation wurde als einziger Mechanismus erlaubt und muss in der Spezifikation auch so beschrieben werden
114	ti	included	Eecim.02.02 : subjectIdentity				Zur Assertion der angefragten Patienten ID: Ich kann die Argumente zu epSOS und SSO nachvollziehen. Diese wären durch eine von der Identity Assertion getrennte Assertion der relevanten Patienten ID addressierbar. Zum Thema Effizienzgewinn: Wenn ich bei einer reinkommenden Query durch die Patienten ID alle relevanten Policies abfrage, kann ich einen signifikanten Teil der Anfragen ohne Aufbauen des Request Context beantworten. Der Request Context würde ja im EFA Fall (wo die gesamte Akte auf einmal abgefragt wird) eine signifikante Größe haben. Alle Anfragen bei denen der LE kein Teilnehmer ist, benötigen keine Abfrage der kompletten Metadaten, sondern können alleine anhand der Policies, der Action (z.B. RegistryStoredQuery) und der Subject Informationen negativ beantwortet werden. Bevor Dokumente herausgegeben werden, wird natürlich trotzdem die dort referenzierte Patienten ID mit den Policies verglichen, die aufgrund der Patienten ID in der Assertion herangezogen werden. Wenn die Patienten ID in den Policies (die aus der Assertion stammt) anders ist als die Patienten ID in den Dokumenten Metadaten, matcht die XACML Rule nicht und der Zugriff wird nicht gestattet. Solange es wie bei der EFA keine expliziten Deny Regeln (z.B. pat.-spezifisches Blacklisting von bestimmten Ärzten) gibt, besteht hier auch kein Sicherheitsrisiko. TL;DR: Die Pat ID in der Assertion ist als "Hint" aufzufassen, der eine effizientere Verarbeitung gerade bei nicht authorisierten Benutzern führt. (ti, 29.05.2013)	Alert-Box beschreibt ausführlich die Gründe für die Trennung von Patient-ID und Assertion.	Cookbook: Identity Assertion mit Verweis auf Patienten ID soll als optional deklariert werden. Profil (hier: EFA) kann dann den Aufbau der Identity Assertion "überschreiben" oder klare Empfehlungen geben.
115	iw	included	Eecim.02.04 : accessToken		Die Struktur des Tokens ist in der EFA-1.2-Spezifikation eCR Offline Token - Service Architecture definiert.		Leider ist kein Verweis auf diese Spezifikation zu finden. Es wäre schön, wenn dies ergänzt würde. (15.08.2014)	Der Verweis wurde ergänzt. (bk, 12.09.2014)

Authors

Kürzel	Name	Organisation	E-Mail
fh	Frank Oemig	Agfa Healthcare
ti	Tarik Idris	InterComponentWare AG
mr	Michael Rübener	X-tension
sh	Salima Houta	Fraunhofer ISST
jc	Jörg Caumanns	Fraunhofer FOKUS
bk	Ben Kraufmann	Fraunhofer FOKUS
iw	Ingo Wolf	gematik
mk	Marcel Klötgen	CompuGroup Medical