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

Aus Hl7wiki
Wechseln zu: Navigation, Suche
K (Aktuelle Fassung der Kommentar-Tabelle eingefügt.)
(→‎Kommentare: Kommentare vom HL7 Interoperabilitäts Forum 2014/12 hinzugefügt.)
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 1: Zeile 1:
−
= Kommentierung =
+
= Kommentare =
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!ID
 
!Author
 
!Author
 
!Status
 
!Status
 
!Section
 
!Section
 +
!Vote
 
!Existing
 
!Existing
 
!Proposed
 
!Proposed
Zeile 9: Zeile 11:
 
!Comment Editor
 
!Comment Editor
 
!Discussion
 
!Discussion
 +
       
 
|- style="vertical-align:top;"
 
|- style="vertical-align:top;"
 +
|style="background-color: white;"|181
 
|style="background-color: white;"|ti
 
|style="background-color: white;"|ti
 
|style="background-color: #89C35C;"|included
 
|style="background-color: #89C35C;"|included
 
|style="background-color: white;"|Eocyo.01.01 : PolicySet Profile
 
|style="background-color: white;"|Eocyo.01.01 : PolicySet Profile
 +
        |style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
Zeile 18: Zeile 23:
 
|style="background-color: white;"|Punkt "BPPC" wurde entfernt. Punkt "Policy References" bleibt bestehen.
 
|style="background-color: white;"|Punkt "BPPC" wurde entfernt. Punkt "Policy References" bleibt bestehen.
 
|style="background-color: white;"|BBPC ausschließen, lediglich Punkt 3 ist zulässig, Policy Provider liefert Satz aller gültigen Regeln
 
|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;"
 
|- style="vertical-align:top;"
 +
|style="background-color: white;"|182
 
|style="background-color: white;"|ti
 
|style="background-color: white;"|ti
 
|style="background-color: #89C35C;"|included
 
|style="background-color: #89C35C;"|included
 
|style="background-color: white;"|Eocyo.01.02 : Policy Assignment
 
|style="background-color: white;"|Eocyo.01.02 : Policy Assignment
 +
        |style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
Zeile 27: Zeile 35:
 
|style="background-color: white;"|Subject-ID entstammt der NameID der Assertion. Daher ist kein expliziter Hinweis notwendig. Weitere Attribute-Ids wurde hinzugefügt
 
|style="background-color: white;"|Subject-ID entstammt der NameID der Assertion. Daher ist kein expliziter Hinweis notwendig. Weitere Attribute-Ids wurde hinzugefügt
 
|style="background-color: white;"|statt nur subject-id auch andere designators zulassen (ti)
 
|style="background-color: white;"|statt nur subject-id auch andere designators zulassen (ti)
 +
       
 
|- style="vertical-align:top;"
 
|- style="vertical-align:top;"
 +
|style="background-color: white;"|183
 
|style="background-color: white;"|ti
 
|style="background-color: white;"|ti
 
|style="background-color: #89C35C;"|included
 
|style="background-color: #89C35C;"|included
 
|style="background-color: white;"|Eocyo.01.02 : Policy Assignment
 
|style="background-color: white;"|Eocyo.01.02 : Policy Assignment
 +
        |style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
Zeile 36: Zeile 47:
 
|style="background-color: white;"|SubjectMatchId gibt Funktionen vor, mit welchen der Datentyp korrespondieren muss.
 
|style="background-color: white;"|SubjectMatchId gibt Funktionen vor, mit welchen der Datentyp korrespondieren muss.
 
|style="background-color: white;"|siehe Diskussion @PolicyCombiningAlgorithm
 
|style="background-color: white;"|siehe Diskussion @PolicyCombiningAlgorithm
 +
       
 
|- style="vertical-align:top;"
 
|- style="vertical-align:top;"
 +
|style="background-color: white;"|184
 
|style="background-color: white;"|ti
 
|style="background-color: white;"|ti
 
|style="background-color: #89C35C;"|included
 
|style="background-color: #89C35C;"|included
 
|style="background-color: white;"|Eocyo.01.02 : Policy Assignment
 
|style="background-color: white;"|Eocyo.01.02 : Policy Assignment
 +
        |style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
Zeile 45: Zeile 59:
 
|style="background-color: white;"|Fomulierung wurde angepasst. (bk)
 
|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="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="vertical-align:top;"
 +
|style="background-color: white;"|185
 
|style="background-color: white;"|ti
 
|style="background-color: white;"|ti
 
|style="background-color: #89C35C;"|included
 
|style="background-color: #89C35C;"|included
 
|style="background-color: white;"|Eocyo.01.02 : Policy Assignment
 
|style="background-color: white;"|Eocyo.01.02 : Policy Assignment
 +
        |style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
Zeile 54: Zeile 71:
 
|style="background-color: white;"|Fomulierung wurde angepasst. (bk)
 
|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="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="vertical-align:top;"
 +
|style="background-color: white;"|186
 
|style="background-color: white;"|ti
 
|style="background-color: white;"|ti
 
|style="background-color: #89C35C;"|included
 
|style="background-color: #89C35C;"|included
 
|style="background-color: white;"|Eocyo.01.02 : Policy Assignment
 
|style="background-color: white;"|Eocyo.01.02 : Policy Assignment
 +
        |style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
Zeile 63: Zeile 83:
 
|style="background-color: white;"|AttributeId für RessourceDesignator ist immer XDSFolder.codeList.
 
|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="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="vertical-align:top;"
 +
|style="background-color: white;"|187
 
|style="background-color: white;"|ti
 
|style="background-color: white;"|ti
 
|style="background-color: #89C35C;"|included
 
|style="background-color: #89C35C;"|included
 
|style="background-color: white;"|Eocyo.01.03 : Policy Attachment
 
|style="background-color: white;"|Eocyo.01.03 : Policy Attachment
 +
        |style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
Zeile 72: Zeile 95:
 
|style="background-color: white;"|XACML actions wurden für PolicyAttachment definiert.
 
|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)
 
|style="background-color: white;"|Policies werden vorgegeben, welche den Lebenszyklus der Akte widerspiegeln (rk)
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|271
 +
|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;"|
 +
|style="background-color: white;"|Ich würde mustBePresent entfernen, da es unnötigerweise zu INDETERMINATE führt bei gemischtem Betrieb. Bei einem Deny-biased PEP ist das Ergebnis das gleiche -> Vorschlag: wegnehmen um unnötige Indeterminate-Fehler beim Hybrid-Betrieb zu vermeiden  (ti, 18.12.2014)
 +
|style="background-color: white;"|Ok. Wurde entfernt. (bk, 18.12.2014)
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|272
 +
|style="background-color: white;"|ti
 +
|style="background-color: #CCEECC;"|commented
 +
|style="background-color: white;"|Eocyo.01.02 : Policy Assignment
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|Patient ist schon auf XDS & CDA Ebene bekannt -> Vorschlag: definieren, dass sie gleich sein müssen.  (ti, 18.12.2014)
 +
|style="background-color: white;"|Ok. Wird im Consent-Binding spezifiziert. (bk, 18.12.2014)
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|273
 +
|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;"|
 +
|style="background-color: white;"|homecommunityid kann zu Problemen beim P2P Zugriff führen -> Vorschlag: homecommunityid rausnehmen (ti, 18.12.2014)
 +
|style="background-color: white;"|OK. Patient-ID enthält ID der Assigning Authority (bk, 18.12.2014)
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|274
 +
|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;"|
 +
|style="background-color: white;"|Was bringt uns die Einschränkung auf GetFolderAndContents and FindDocuments? Wenn der User die Dokumente sehen darf, darf er sie sehen, egal ob er GetDocuments oder GetFolderAndContents macht. Ausserdem muss die QueryId erst aus der Nachrichten Payload gelesen werden, während die Action ID aus dem Endpunkt ersichtlich ist. -> diskutieren (ti, 18.12.2014)
 +
|style="background-color: white;"|Die Vorgaben zur Verwendung der xacml:Action-Elemente wurde entfernt. (bk, 18.12.2014)
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|275
 +
|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;"|
 +
|style="background-color: white;"|URNs als PolicyIds für standardisierte Policies sind eine sehr gute Idee, für die Fall-/Patienten-spezifischen Policies weniger, da machen UUIDs mehr Sinn -> Vorschlag: UUIDs vorschreiben (ti, 18.12.2014)
 +
|style="background-color: white;"|Ok. (18.12.2014)
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|276
 +
|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;"|
 +
|style="background-color: white;"|Subject-ID lieber nicht als II, da man nicht trivial vom SAML nameId dahin kommt. nameQualifier könnte als Quelle für root dienen, aber ist nicht notwendigerweise eine OID. zieht das auch eine nameIDFormat einschränkung mit sich? -> Vorschlag: Definieren wo das aus HPD herkommen sollte (ti, 18.12.2014)
 +
|style="background-color: white;"|Ok, da wo anwendbar, wird explizit auf die XACML-Bindings des IHE-D-Cookbook verwiesen. (bk, 18.12.2014)
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|277
 +
|style="background-color: white;"|ti
 +
|style="background-color: #D4A017;"|reconcile
 +
|style="background-color: white;"|Eocyo.01.02 : Policy Assignment
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|subject-role lieber als CV, wie in XUA (wo es genauer ein CE ist, aber das macht die matching regeln viel komplizierter) -> Vorschlag: auf CV ändern (ti, 18.12.2014)
 +
|style="background-color: white;"|Existiert für den ASTM E1986-98 (2005) eine Katalog-ID, welche als root für CV verwendet werden kann? Da für XSPA-konforme Identity Assertions string-kodierte Werte für structural role gefordert werden, ist ein string-kodierter Wert in der Policy naheliegend. (bk, 18.12.2014)
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|278
 +
|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;"|
 +
|style="background-color: white;"|suject-org-id nicht als II sondern als URN-kodierte OID ["The organization ID may be an Object Identifier (OID), using the urn format (that is, “urn:oid:” appended with the OID); or it may be a URL assigned to that organization." IHE ITI TF vol2b, p63] -> Vorschlag: mit IHE XUA abgleichen (ti, 18.12.2014)
 +
|style="background-color: white;"|Ok, wurde an XACML-Binding des IHE-D Cookbook angeglichen. (bk, 18.12.2014)
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|279
 +
|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;"|
 +
|style="background-color: white;"|primary-rule (Begin of grace period) und health record manager rule könnte auch über target abgebildet werden (für die XACML Engine effizienter zu prüfen) -> Vorschlag: Abbildung auf Target ändern (ti, 18.12.2014)
 +
|style="background-color: white;"|Ok. (bk, 18.12.2014)
 +
|style="background-color: white;"|
 +
|}
 +
 +
= Authors =
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Kürzel
 +
!Name
 +
!Organisation
 +
!E-Mail
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|fh
 +
        |style="background-color: white;"|Frank Oemig
 +
        |style="background-color: white;"|Agfa Healthcare
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|ti
 +
        |style="background-color: white;"|Tarik Idris
 +
        |style="background-color: white;"|InterComponentWare AG
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|mr
 +
        |style="background-color: white;"|Michael Rübener
 +
        |style="background-color: white;"|X-tension
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|sh
 +
        |style="background-color: white;"|Salima Houta
 +
        |style="background-color: white;"|Fraunhofer ISST
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|jc
 +
        |style="background-color: white;"|Jörg Caumanns
 +
        |style="background-color: white;"|Fraunhofer FOKUS
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|bk
 +
        |style="background-color: white;"|Ben Kraufmann
 +
        |style="background-color: white;"|Fraunhofer FOKUS
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|iw
 +
        |style="background-color: white;"|Ingo Wolf
 +
        |style="background-color: white;"|gematik
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|mk
 +
        |style="background-color: white;"|Marcel Klötgen
 +
        |style="background-color: white;"|CompuGroup Medical
 
|}
 
|}

Aktuelle Version vom 26. Januar 2015, 10:32 Uhr

Kommentare

ID Author Status Section Vote Existing Proposed Comment Comment Editor Discussion
181 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
182 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)
183 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
184 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
185 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)
186 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)
187 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)
271 ti included Eocyo.01.02 : Policy Assignment Ich würde mustBePresent entfernen, da es unnötigerweise zu INDETERMINATE führt bei gemischtem Betrieb. Bei einem Deny-biased PEP ist das Ergebnis das gleiche -> Vorschlag: wegnehmen um unnötige Indeterminate-Fehler beim Hybrid-Betrieb zu vermeiden (ti, 18.12.2014) Ok. Wurde entfernt. (bk, 18.12.2014)
272 ti commented Eocyo.01.02 : Policy Assignment Patient ist schon auf XDS & CDA Ebene bekannt -> Vorschlag: definieren, dass sie gleich sein müssen. (ti, 18.12.2014) Ok. Wird im Consent-Binding spezifiziert. (bk, 18.12.2014)
273 ti included Eocyo.01.02 : Policy Assignment homecommunityid kann zu Problemen beim P2P Zugriff führen -> Vorschlag: homecommunityid rausnehmen (ti, 18.12.2014) OK. Patient-ID enthält ID der Assigning Authority (bk, 18.12.2014)
274 ti included Eocyo.01.02 : Policy Assignment Was bringt uns die Einschränkung auf GetFolderAndContents and FindDocuments? Wenn der User die Dokumente sehen darf, darf er sie sehen, egal ob er GetDocuments oder GetFolderAndContents macht. Ausserdem muss die QueryId erst aus der Nachrichten Payload gelesen werden, während die Action ID aus dem Endpunkt ersichtlich ist. -> diskutieren (ti, 18.12.2014) Die Vorgaben zur Verwendung der xacml:Action-Elemente wurde entfernt. (bk, 18.12.2014)
275 ti included Eocyo.01.02 : Policy Assignment URNs als PolicyIds für standardisierte Policies sind eine sehr gute Idee, für die Fall-/Patienten-spezifischen Policies weniger, da machen UUIDs mehr Sinn -> Vorschlag: UUIDs vorschreiben (ti, 18.12.2014) Ok. (18.12.2014)
276 ti included Eocyo.01.02 : Policy Assignment Subject-ID lieber nicht als II, da man nicht trivial vom SAML nameId dahin kommt. nameQualifier könnte als Quelle für root dienen, aber ist nicht notwendigerweise eine OID. zieht das auch eine nameIDFormat einschränkung mit sich? -> Vorschlag: Definieren wo das aus HPD herkommen sollte (ti, 18.12.2014) Ok, da wo anwendbar, wird explizit auf die XACML-Bindings des IHE-D-Cookbook verwiesen. (bk, 18.12.2014)
277 ti reconcile Eocyo.01.02 : Policy Assignment subject-role lieber als CV, wie in XUA (wo es genauer ein CE ist, aber das macht die matching regeln viel komplizierter) -> Vorschlag: auf CV ändern (ti, 18.12.2014) Existiert für den ASTM E1986-98 (2005) eine Katalog-ID, welche als root für CV verwendet werden kann? Da für XSPA-konforme Identity Assertions string-kodierte Werte für structural role gefordert werden, ist ein string-kodierter Wert in der Policy naheliegend. (bk, 18.12.2014)
278 ti included Eocyo.01.02 : Policy Assignment suject-org-id nicht als II sondern als URN-kodierte OID ["The organization ID may be an Object Identifier (OID), using the urn format (that is, “urn:oid:” appended with the OID); or it may be a URL assigned to that organization." IHE ITI TF vol2b, p63] -> Vorschlag: mit IHE XUA abgleichen (ti, 18.12.2014) Ok, wurde an XACML-Binding des IHE-D Cookbook angeglichen. (bk, 18.12.2014)
279 ti included Eocyo.01.02 : Policy Assignment primary-rule (Begin of grace period) und health record manager rule könnte auch über target abgebildet werden (für die XACML Engine effizienter zu prüfen) -> Vorschlag: Abbildung auf Target ändern (ti, 18.12.2014) Ok. (bk, 18.12.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
Abgerufen von „https://wiki.hl7.de/index.php?title=cdaefa_Diskussion:EFA_Policy_Assertion_SAML2_Binding&oldid=22055“