cdaefa Diskussion:EFA Identity Assertion SAML2 Binding

Change Requests

ID	Requester	Status	Section	Change Request	Recommendation Editor	Discussion
12	-	rejected	ItyAn.01.02 : HCP Identity Attributes	Kodierung von Rollen: Auf konzeptioneller Ebene sind die Akteure und Rollen genannt: Fallaktenmanager EFA-Provider EFA-Teilnehmer (Verwaltungspersonal, Datenschutzauditor, Audittool, Arzt bzw. med.Fachpersonal) Auf Implementierungsebene sind dann die HCP Identity Attributes nach ASTM E1986-98 (2005) definiert. In der Annahme, dass sich alle Akteure am EFA-Peer authentisieren müssen und eine SubjectIentityAssertion vorweisen müssen, wäre es sinnvoll, ein Mapping der genannten Rollen auf die entsprechenden Identity Attributes klar zu definieren (zusätzlich zu einem Beispiel für Ärzte, das bereits vorhanden ist)	jc: Manchmal besser erst denken... (bezogen auf den Vorschlag unten) Die EFA-Rolle kann garnicht in der HCP-Identity Assertion enthalten sein, da diese Rolle aus dem Consent abgeleitet wird. Derr Consent liegt potenziell bei dem die HCP-Assertion ausstellenden Identity Provider garnicht vor - bzw. dieser hat kein Zugriffsrecht auf den Consent. Daher kann die EFA-Rolle erst im Rahmen der Policy Decision abgefragt und ausgewertet werden. jc: Idealerweise sollte hier das bestehende EFA-Codesystem "HCP Roles" referenziert werden. Ggf. kann man ja auch die Angabe der EFA-Rolle verpflichetend machen und die ASTM-Rolle optional.

Kommentare

ID	Author	Status	Section	Vote	Existing	Proposed	Comment	Comment Editor	Discussion
236	ti	included	ItyAn.01 : SAML 2.0 Profile for ECR Identity Assertions				Die Subject Confirmation Method sollten wir noch wie besprochen diskutieren. (ti, 07.06.2013)	HoK stellt keine Hürde für UsernamePassword dar, da symmetrischer Schlüssel generiert werden kann. (Sym. HoK vs. Asym HoK). Bearer ist jetzt auch zulässig. Hierfür muss gelten: Die Nachrichten werden über einen gegenseitig authentifizierten TLS-Kanal ausgetauscht.
237	ti	included	ItyAn.01 : SAML 2.0 Profile for ECR Identity Assertions				Wenn als AuthnContextClassRef nur urn:oasis:names:tc:SAML:2.0:ac:classes:X509 verwendet werden darf, heisst dass dann das kein Benutzer über Benutzername+Passwort identifiziert werden darf? In {Eecim.02.02} unter "Art der Authentifizierung" deutet die Formulierung ja eher auf eine Entscheidung des EFA Providers hin, welche Authentifizierungsmethoden er bei IdPs erwartet. (ti, 07.06.2013)	Es sind jetzt grundsätzlich alle Verfahren zulässig, können vom PEP aber abgelehnt werden.	Empfehlung: X509 basiertes Authentifizierungsverfahren SHOULD, andere Authentifizierungsverfahren MAY.
238	ti	rejected	ItyAn.01 : SAML 2.0 Profile for ECR Identity Assertions				Um unnötige Mapping-Schritte zu vermeiden, sollte die NameID soweit eingeschränkt werden, dass sie ohne weiteres in die XACML engine gegeben und mit der policy verglichen werden kann. Selbst die Deutschland-spezifischen Einschränkungen in {ItyAn.01.05} sind hier noch zu flexibel. Ich würde hier jeweils eine einzige Definition für Niedergelassene und Ärzte in Einrichtungen vorschlagen. Zumindest sollte dem Leser klar gemacht werden dass die NameID mit den Policies abgeglichen wird und somit der Ersteller der Policies den gleichen Identifikator verwendet. Wenn dies nicht der Fall ist, könnte es passieren dass der IdP die ID des HBA AUT Zertifikats verwendet, die Policy aber auf eine bestimmte Lebenslange Arztnummer der KV des gleichen Arztes abgleicht. (ti, 07.06.2013)	EFA Provider legt @Format fest. Die NameID muss dann einheitlich bedient werden, um eindeutige Identifizierung von Benutzern gewährleisten zu können. Die Abhängigkeit zwischen SAML-NameID und XACML-Subject-MatchID ist im Policy Assignment SAML-Binding beschrieben.
239	ti	commented	ItyAn.01.02 : HCP Identity Attributes				HP Identifier: XSPA definiert hier "urn:oasis:names:tc:xacml:1.0:subject:subject-id" als Attributsnamen, während XUA "urn:oasis:names:tc:xspa:1.0:subject:subject-id" verwendet, was doppelt falsch ist: weder ist es wirklich eine ID, noch ist es von XSPA mit dieser URN versehen worden. Beide Alternativen haben den Nachteil, dass sie die Referenzierung auf die primäre ID des Benutzers in einer XACML policy unnötig erwschweren. Da die primäre ID des Benutzers in SAML nicht als AttributeStatement mit name und type sondern als NameID Element übertragen wird, gibt es keinen "natürlichen" Attributsnamen um in einer Policy einen bestimmten Benutzer zu authorisieren. Die logischste URN dafür wäre eigentlich "urn:oasis:names:tc:xacml:2.0:subject:subject-id" (ob 1.0 oder 2.0 ist dabei nicht entscheidend). Daher würde ich mich gegen die von XSPA (und z.T. von XUA) gewählte Umdefinition des Klarnamens zur "subject-id" aussprechen. Der Klarname kann auch viel besser mit Rückgriff auf den LDAP Standard definiert werden. Im XACML Core wird dies auf Seite 129 (ab Zeile 5027) als Pflicht (zumindest für den XACML Request Context) für in LDAP schon existierende Attribute definiert: "Where a suitable attribute is already defined in LDAP [LDAP-1, LDAP-2], the XACML identifier SHALL be formed by adding the attribute name to the URI of the LDAP specification. For example, the attribute name for the userPassword defined in the RFC 2256 SHALL be: http://www.ietf.org/rfc/rfc2256.txt#userPassword". Daher mein Vorschlag: "urn:oasis:names:tc:xacml:2.0:subject:subject-id" in XACML policies bezeichnet den primären Identifier des Benutzers, "http://www.ietf.org/rfc/rfc2256.txt#cn" im SAML AttributeStatement und im XACML Request Context bezeichnet den Klarnamen des Benutzers. (ti, 07.06.2013)	Im Zuge von der Peer2Peer-Ausarbeitung werden die HCP Identity Attribute um ein weiteres SAML-AttributeStatement erweitert, welches auf dem SAML V2.0 X.500/LDAP Attribute Profile basieren wird.
240	ti	included	ItyAn.01.02 : HCP Identity Attributes				Purpose of Use: 1. Für PoU würde ich auch auf einen strukturierten Typ setzen, wie auch in XUA definiert. Also "urn:hl7-org:v3#CE" oder "urn:hl7-org:v3#CV". 2. Im Cookbook haben wir das Attribut nicht mandatory gesetzt, sondern stattdessen Treatment bzw. den ungefähr equivalenten Wert 1 aus ISO 14265 als Default Wert annehmen muss. Dies erlaubt eine explizite Nennung bei Ausnahmen (v.a. Notfallzugriff) ohne dem Client zuviel abzuverlangen. (ti, 07.06.2013)	optional, siehe Cookbook
241	ti	included	ItyAn.01.02 : HCP Identity Attributes				Healthcare Professional Organisation und Healthcare Professional Organisation ID: Ich würde zumindest die Organisation ID immer zwingend übertragen. Aus Sicht der Authorisierung von Einrichtungen erscheint mir die organisatorische Zugehörigkeit als das kritischere Unterscheidungsmerkmal. Ich vermute mal Point of Care ist mandatory und als Grundlage für die Policies gedacht, um den Fall des Belegarzt abzudecken, dessen Daten nicht im KH System landen sollen, mit dem er manchmal auf Fallakten zugreift. Dieser Fall sollte adressiert werden, aber locality scheint mir nicht die optimale Lösung zu sein. Erstens ist es ein Environment Aspekt und nicht Teil des Subjects. Zweitens ist es im Gegensatz zur Organisation ID nicht in IHE XUA definiert. Wenn locality eingesetzt wird, würde ich ausserdem die Definition von XSPA vorziehen: "Unique identifier of the servicing organization". Zusätzlich würde ich auch den Type einschränken: "URN encoded OID of the Healthcare Professional Organisation" (wie bei Org-ID). (ti, 07.06.2013)	Organisation ID soll verpflichtend übermittelt werden. Point Of Care soll nicht verpflichtend sein.
242	ti	postponed	ItyAn.01.02 : HCP Identity Attributes				Structural Role of the HCP: 1. XUA erweitert erlaubt ausser ASTM E1986 auch SNOMED CT und ISO 21298 - hatten wir uns nicht in der 7er Gruppe vorläufig eher für SNOMED ausgesprochen? 2. Wenn die Rolle auf die hier beschriebenen eingeschränkt wird, wie wird dann z.B. der Fallaktenmanager abgebildet? 3. Ich würde für die Rolle einen strukturierteren Datentyp wählen. XUA sieht "urn:hl7-org:v3#CE" vor, ich hätte eher CV gewählt. Aus Sicht des Cookbooks ist es durchaus wichtig unterschiedliche Codesysteme unterstützen zu können, gerade auch um die unterschiedlichen Aktentypen abbilden zu können. (ti, 07.06.2013)	Hinweis auf Verschiebung ins Cookbook wurde in Einstiegsseite eingefügt. (bk)	Die gültigen Werte für dieses Attribut sollten im Cookbook festgelegt werden. (ti)
243	ti	included	ItyAn.01.03 : German Extensions				Für Clinical Speciality bietet sich der epsos Name an: "urn:epsos:names:wp3.4:subject:clinical-speciality". (ti, 07.06.2013)	Sobald die TI ausgerollt ist, kann dieses Attribut verwendet werden. Für das Policy-Enforcement ist es zur Zeit nicht relevant. Daher wird an dieser Stelle keine Alternative zum TI-Attribut vorgeschlagen. Hinweis wurde eingefügt.

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