feedback re: OHC - obligation profile for healthcare

[Danny Thorpe <Danny.Thorpe@quest.com>]

Mohammad,

 

Thanks for posting the proposal for an obligation profile for healthcare!

 

 

Some thoughts that occurred to me as I was reading the document:

 

1.       Please gather together the uri prefixes mentioned throughout the document into a common section near the top and use a prefix notation in attribute id and value definitions instead of “The prefix xyz is assumed to precede…” that appears before every table of definitions.  The XACML 3.0 core spec, section 1.2 Terminology does this for namespaces used throughout the core spec document. Since you are dealing with actual prefixes rather than namespaces, perhaps a bracketed name pattern to indicate the prefix would work:   OCH defined as xyz:123…   Citation would look like [OHC]hl7:anonymize, [OHC]assignee-type, [OHC]obligation-assignee:subject etc.

Gathering the prefixes together will help ensure and express uniformity across the document, so we don’t end up with one unintended rogue prefix due to a typo somewhere.

2.       Section 1.1 Binding Policies: The purpose of this section is to provide a means to reference a policy in an obligation, correct?

a.       Who is the intended recipient of the enforce-policy obligation?

b.      How will that recipient evaluate/enforce the policy? PEPs generally aren’t capable of evaluating policy logic. That’s what the PDP is for. Is this section about PDP-PDP communication?

c.       Could you give an example of the XML for such an obligation? I’m having trouble visualizing where the indicated attribute value is intended to go. If it is the body of an <AttributeAssignment> element, shouldn’t this whole section be part of section 2. Obligation Attributes?  The reason I ask is because I think enforce-policy-at could be folded into enforce-policy by using the data type as a discriminator.

d.      Consider adding <Policy(Set)IdReference> alongside Policy(Set) elements and url as a means to reference a policy. <Policy(Set)IdReference> allows for constraining the range of policy versions.

e.      What’s the attribute id for the Duration value?

f.        The naming of enforce-policy:expires-on suggests that this is to be used with the policy provided by enforce-policy, but the description suggests it applies to enforce-policy-at.

3.       Section 2.1 Obligation Type. What is the purpose of this obligation type? I understand the point that obligations can be classified as positive or negative actions, but how is this information useful to PEPs or client apps? They are obligated to perform the action(s) implied by the obligation-id regardless of what the obligation’s classification is. Why bulk up the response with data that the recipient doesn’t care about?

4.       Section 2.4 Execution Order w.r.t The Action – Transactional Properties are listed in the text, but there are no attributes defined to specify transactional requirements. If most obligations are transactional with the action, what is the use case for specifying an obligation that is not transactionally coupled to the action? And why wouldn’t that just be part of the semantics of the particular obligation-id? Are there cases where sometimes you want a transaction and sometimes you don’t for the same obligation-id?

5.       Section 3.0, Combining Algorithms – I’ll need to chew on this section awhile, and I suspect the TC will also.

a.       It would make sense to add a new attribute to the XACML schema if the new behavior were orthogonal to the decision combining process. However, since the proposed “obligation combining algorithms” require altering the policy evaluation workflow to consider applicability of all nodes instead of Boolean short-circuit, it’s not really orthogonal to rule/policy combining algorithms.

b.      Instead of modifying XACML schema to allow an additional XML attribute on <Policy> and <PolicySet> elements, another way to indicate desired obligation handling might be to use combining algorithm parameters, via <CombinerParameters> and <RuleCombinerParameters> elements.

                                                               i.      The schema for such parameters is already defined in the Xacml 3.0 core spec and is open-ended enough that no schema change would be needed to specify an obligation processing mode using a parameter id and attribute value. The parameter id and permitted values could be defined in the obligation profile.

                                                             ii.      None of the core spec combining algorithms currently define any parameters.

                                                            iii.      Specifying obligation combining mode via parameters would make obligation combining a sub-function of the rule/policy combining algorithm instead of orthogonal to them. Vendors would still need to modify their PDPs to support this behavior, but the XACML schema would not have to be changed.

6.       This obligations for health care profile will need a profile id urn so that PAPs/PDPs can indicate support for obligation combining behaviors defined in this profile.

 

-Danny

 

Danny Thorpe

Authorization Architect

Dell | Identity & Access Management, Quest Software

 

Quest Software is now part of Dell.