cdaefa Diskussion:EFA Identity Assertion SAML2 Binding

Kommentierung

Author	Status	Section	Existing	Proposed	Comment	Comment Editor	Discussion
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.
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.
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.
ti	postponed	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.
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
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.
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)
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.