cdaefa Diskussion:EFA Policy Assertion SAML2 Binding: Unterschied zwischen den Versionen

Aus Hl7wiki
Wechseln zu: Navigation, Suche
(Die Seite wurde neu angelegt: „== Eocyo.01.01 == ;Comment :Ich kann dieser Unterscheidung im Kontext eines EFA authorization statement nicht ganz folgen. Eine solche Dreiteilung…“)
 
K (Aktuelle Fassung der Kommentar-Tabelle eingefügt.)
Zeile 1: Zeile 1:
−
== Eocyo.01.01 ==
+
= Kommentierung =
−
           
+
{|class="wikitable" style="text-align: left; cellpadding: 10;"
−
;Comment
+
!Author
−
:Ich kann dieser Unterscheidung im Kontext eines EFA authorization statement nicht ganz folgen. Eine solche Dreiteilung leuchtet mir für die Patientenzustimmung ein, in dem Fall ist mir aber der Nutzen als Assertion nicht klar. (ti, 07.06.2013)
+
!Status
−
;Author
+
!Section
−
:ti
+
!Existing
−
== Eocyo.01.02 ==
+
!Proposed
−
           
+
!Comment
−
;Comment
+
!Comment Editor
−
:@PolicySetId: BPPC sieht OIDs als Policy Identifier vor. XACML schreibt nur vor das es eine URI sein muss. Ich würde als Kompromiss auch die Verwendung von URN prefixed OIDs erlauben. (ti, 07.06.2013)
+
!Discussion
−
;Author
+
|- style="vertical-align:top;"
−
:ti
+
|style="background-color: white;"|ti
−
== Eocyo.01.02 ==
+
|style="background-color: #89C35C;"|included
−
           
+
|style="background-color: white;"|Eocyo.01.01 : PolicySet Profile
−
;Comment
+
|style="background-color: white;"|
−
:@PolicyCombiningAlgId: Ich halte es für riskant sich auf die Reihenfolge der Policies zu verlassen, v.a. da diese ggf. on-the-fly vom Policy Provider zusammengebaut werden. Hier wäre deny-override (in Kombination mit einem deny-biased PEP) sinnvoller. (ti, 07.06.2013)
+
|style="background-color: white;"|
−
;Author
+
|style="background-color: white;"|Ich kann dieser Unterscheidung im Kontext eines EFA authorization statement nicht ganz folgen. Eine solche Dreiteilung leuchtet mir für die Patientenzustimmung ein, in dem Fall ist mir aber der Nutzen als Assertion nicht klar. (ti, 07.06.2013)
−
:ti
+
|style="background-color: white;"|Punkt "BPPC" wurde entfernt. Punkt "Policy References" bleibt bestehen.
−
== Eocyo.01.02 ==
+
|style="background-color: white;"|BBPC ausschließen, lediglich Punkt 3 ist zulässig, Policy Provider liefert Satz aller gültigen Regeln
−
           
+
|- style="vertical-align:top;"
−
;Comment
+
|style="background-color: white;"|ti
−
:SubjectAttributeDesignator@AttributeId: In der SAML Assertion wurde "urn:oasis:names:tc:xacml:1.0:subject:subject-id" als Klarname definiert. D.h. hier müsste beim Aufbau des Kontext das vorhandene Attribut ...:subject-id rausgeschmissen werden und eine Umwandlung von NameID auf ...:subject-id stattfinden (siehe auch {ItyAn.01.02}). (ti, 07.06.2013)
+
|style="background-color: #89C35C;"|included
−
;Author
+
|style="background-color: white;"|Eocyo.01.02 : Policy Assignment
−
:ti
+
|style="background-color: white;"|
−
== Eocyo.01.02 ==
+
|style="background-color: white;"|
−
           
+
|style="background-color: white;"|SubjectAttributeDesignator@AttributeId: In der SAML Assertion wurde "urn:oasis:names:tc:xacml:1.0:subject:subject-id" als Klarname definiert. D.h. hier müsste beim Aufbau des Kontext das vorhandene Attribut ...:subject-id rausgeschmissen werden und eine Umwandlung von NameID auf ...:subject-id stattfinden (siehe auch {ItyAn.01.02}). (ti, 07.06.2013)
−
;Comment
+
|style="background-color: white;"|Subject-ID entstammt der NameID der Assertion. Daher ist kein expliziter Hinweis notwendig. Weitere Attribute-Ids wurde hinzugefügt
−
:SubjectAttributeDesignator@DataType: Ich würde hier wie auch schon bei der SAML NameID eine klare Festlegung befürworten. Ansonsten werden v.a. cross-community Szenarien sehr schwierig. (ti, 07.06.2013)
+
|style="background-color: white;"|statt nur subject-id auch andere designators zulassen (ti)
−
;Author
+
|- style="vertical-align:top;"
−
:ti
+
|style="background-color: white;"|ti
−
== Eocyo.01.02 ==
+
|style="background-color: #89C35C;"|included
−
           
+
|style="background-color: white;"|Eocyo.01.02 : Policy Assignment
−
;Comment
+
|style="background-color: white;"|
−
:ResourceAttributeDesignator@AttributeId: Woher weiss der Policy Provider auf welche Ressourcen ID der Benutzer zugreifen darf? Was ist die Ressourcen ID in diesem Kontext? (ti, 07.06.2013)
+
|style="background-color: white;"|
−
;Author
+
|style="background-color: white;"|SubjectAttributeDesignator@DataType: Ich würde hier wie auch schon bei der SAML NameID eine klare Festlegung befürworten. Ansonsten werden v.a. cross-community Szenarien sehr schwierig. (ti, 07.06.2013)
−
:ti
+
|style="background-color: white;"|SubjectMatchId gibt Funktionen vor, mit welchen der Datentyp korrespondieren muss.
−
== Eocyo.01.03 ==
+
|style="background-color: white;"|siehe Diskussion @PolicyCombiningAlgorithm
−
           
+
|- style="vertical-align:top;"
−
;Comment
+
|style="background-color: white;"|ti
−
:Die zu verwendenden Basis-PolicySets sind eigentlich durch die Rollenbeschreibungen und das Rechtemodell der EFA voll definiert. Wäre es somit hier nicht sinnvoller diese Regeln (ggf. nicht normativ) mitzuliefern? (ti, 07.06.2013)
+
|style="background-color: #89C35C;"|included
−
;Author
+
|style="background-color: white;"|Eocyo.01.02 : Policy Assignment
−
:ti
+
|style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|@PolicySetId: BPPC sieht OIDs als Policy Identifier vor. XACML schreibt nur vor das es eine URI sein muss. Ich würde als Kompromiss auch die Verwendung von URN prefixed OIDs erlauben. (ti, 07.06.2013)
 +
|style="background-color: white;"|Fomulierung wurde angepasst. (bk)
 +
|style="background-color: white;"|OIDs müssen erlaubt sein, XACML lässt das zu, weder für OID noch für UUID kein URN-Encoding nutzen
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|ti
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Eocyo.01.02 : Policy Assignment
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|@PolicyCombiningAlgId: Ich halte es für riskant sich auf die Reihenfolge der Policies zu verlassen, v.a. da diese ggf. on-the-fly vom Policy Provider zusammengebaut werden. Hier wäre deny-override (in Kombination mit einem deny-biased PEP) sinnvoller. (ti, 07.06.2013)
 +
|style="background-color: white;"|Fomulierung wurde angepasst. (bk)
 +
|style="background-color: white;"|PEP sollte deny-biased konfiguriert sein. Statt fallback-deny am Ende des Sets muss mindestens eine gegebene Regel gültig sein, sonst führt NOT-APPLICABLE zu deny (ti)
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|ti
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Eocyo.01.02 : Policy Assignment
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|ResourceAttributeDesignator@AttributeId: Woher weiss der Policy Provider auf welche Ressourcen ID der Benutzer zugreifen darf? Was ist die Ressourcen ID in diesem Kontext? (ti, 07.06.2013)
 +
|style="background-color: white;"|AttributeId für RessourceDesignator ist immer XDSFolder.codeList.
 +
|style="background-color: white;"|EFA-IHE-spezifische Attribute-Designator-ID verwenden (Vorschlag: urn:ihe:iti:xds-b:2007:folder:code) (ti)
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|ti
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Eocyo.01.03 : Policy Attachment
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|Die zu verwendenden Basis-PolicySets sind eigentlich durch die Rollenbeschreibungen und das Rechtemodell der EFA voll definiert. Wäre es somit hier nicht sinnvoller diese Regeln (ggf. nicht normativ) mitzuliefern? (ti, 07.06.2013)
 +
|style="background-color: white;"|XACML actions wurden für PolicyAttachment definiert.
 +
|style="background-color: white;"|Policies werden vorgegeben, welche den Lebenszyklus der Akte widerspiegeln (rk)
 +
|}

Version vom 24. Januar 2014, 15:57 Uhr

Kommentierung

Author Status Section Existing Proposed Comment Comment Editor Discussion
ti included Eocyo.01.01 : PolicySet Profile Ich kann dieser Unterscheidung im Kontext eines EFA authorization statement nicht ganz folgen. Eine solche Dreiteilung leuchtet mir für die Patientenzustimmung ein, in dem Fall ist mir aber der Nutzen als Assertion nicht klar. (ti, 07.06.2013) Punkt "BPPC" wurde entfernt. Punkt "Policy References" bleibt bestehen. BBPC ausschließen, lediglich Punkt 3 ist zulässig, Policy Provider liefert Satz aller gültigen Regeln
ti included Eocyo.01.02 : Policy Assignment SubjectAttributeDesignator@AttributeId: In der SAML Assertion wurde "urn:oasis:names:tc:xacml:1.0:subject:subject-id" als Klarname definiert. D.h. hier müsste beim Aufbau des Kontext das vorhandene Attribut ...:subject-id rausgeschmissen werden und eine Umwandlung von NameID auf ...:subject-id stattfinden (siehe auch {ItyAn.01.02}). (ti, 07.06.2013) Subject-ID entstammt der NameID der Assertion. Daher ist kein expliziter Hinweis notwendig. Weitere Attribute-Ids wurde hinzugefügt statt nur subject-id auch andere designators zulassen (ti)
ti included Eocyo.01.02 : Policy Assignment SubjectAttributeDesignator@DataType: Ich würde hier wie auch schon bei der SAML NameID eine klare Festlegung befürworten. Ansonsten werden v.a. cross-community Szenarien sehr schwierig. (ti, 07.06.2013) SubjectMatchId gibt Funktionen vor, mit welchen der Datentyp korrespondieren muss. siehe Diskussion @PolicyCombiningAlgorithm
ti included Eocyo.01.02 : Policy Assignment @PolicySetId: BPPC sieht OIDs als Policy Identifier vor. XACML schreibt nur vor das es eine URI sein muss. Ich würde als Kompromiss auch die Verwendung von URN prefixed OIDs erlauben. (ti, 07.06.2013) Fomulierung wurde angepasst. (bk) OIDs müssen erlaubt sein, XACML lässt das zu, weder für OID noch für UUID kein URN-Encoding nutzen
ti included Eocyo.01.02 : Policy Assignment @PolicyCombiningAlgId: Ich halte es für riskant sich auf die Reihenfolge der Policies zu verlassen, v.a. da diese ggf. on-the-fly vom Policy Provider zusammengebaut werden. Hier wäre deny-override (in Kombination mit einem deny-biased PEP) sinnvoller. (ti, 07.06.2013) Fomulierung wurde angepasst. (bk) PEP sollte deny-biased konfiguriert sein. Statt fallback-deny am Ende des Sets muss mindestens eine gegebene Regel gültig sein, sonst führt NOT-APPLICABLE zu deny (ti)
ti included Eocyo.01.02 : Policy Assignment ResourceAttributeDesignator@AttributeId: Woher weiss der Policy Provider auf welche Ressourcen ID der Benutzer zugreifen darf? Was ist die Ressourcen ID in diesem Kontext? (ti, 07.06.2013) AttributeId für RessourceDesignator ist immer XDSFolder.codeList. EFA-IHE-spezifische Attribute-Designator-ID verwenden (Vorschlag: urn:ihe:iti:xds-b:2007:folder:code) (ti)
ti included Eocyo.01.03 : Policy Attachment Die zu verwendenden Basis-PolicySets sind eigentlich durch die Rollenbeschreibungen und das Rechtemodell der EFA voll definiert. Wäre es somit hier nicht sinnvoller diese Regeln (ggf. nicht normativ) mitzuliefern? (ti, 07.06.2013) XACML actions wurden für PolicyAttachment definiert. Policies werden vorgegeben, welche den Lebenszyklus der Akte widerspiegeln (rk)
Abgerufen von „https://wiki.hl7.de/index.php?title=cdaefa_Diskussion:EFA_Policy_Assertion_SAML2_Binding&oldid=16989“