Thanks for the replies. My follow –ups are inline below, prefixed by [DT] Danny Thorpe Authorization Architect Dell Identity & Access Management, Quest Software Quest Software is now part of Dell. From: Mohammad Jafari [mailto:
mjafari@edmondsci.com] Sent: Sunday, November 11, 2012 3:32 PM To: Danny Thorpe Cc:
xacml@lists.oasis-open.org Subject: RE: feedback re: OHC - obligation profile for healthcare Thanks very much Danny for your comments. Please find my answers inline below. Regards, Mohammad 1. Please gather together the uri prefixes […] Thanks, I fixed this for the next update. 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? Since this is happening in an exchange scenario, the recipient (or assignee as we called it in the profile) is the PDP at one or all of the parties that receive the data. The PDP is just ordering the PEP to communicate these obligations with the remote PDPs (often done via annotation). The annotation mechanism is something out of the scope although it is good if we can provide a non-normative example to clarify the scenario. I will add a separate section on the functional requirements or a more elaborate discussion of the operational semantics (informal) to address this. [DT] Ok, I think I see the scenario a little better. If a PDP is making use of its own PEP to consult another PDP, can we give that PDP-embedded PEP a distinctive name to distinguish it from a typical PEP residing in an application? A delegating PEP? In application scenarios I’ve worked with thus far, we would want to make “darned sure” that policy is never communicated to end user applications, only to cooperating PDPs. Distinguishing which PEP role is being referred to in the profile text would help. 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. The actual policy appears as a parameter, i.e. in the body of an <AttributeAssignment>. I fixed this to separate obligation id from the parameter which may be a URL/policy id or the actual XML of the policy. On that note, do we want to define “XACML policy” as a standard data type in Section 10.2.7 of the core spec? [DT] Hmm. I don’t think carrying policy in an obligation or decision response is a common enough scenario to warrant modifying the core spec to make policy a core data type. SAML-XACML provides a mechanism for carrying policy in a response, and the XACML Admin / Delegation profile might touch on this topic. I’m fine with this obligation profile just stating “XACML <Policy> or <PolicySet> element can appear here” for now. 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. Thanks. I incorporated this for next update. e. What’s the attribute id for the Duration value? I removed this for the next update. I think having an expiration date is sufficient to support this use-case. 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 . Thanks. I fixed this. 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? I think the nature of obligation (i.e. negative vs. positive) can affect/facilitate the processing of obligation at PEP. For example, negative obligations are in nature, an authorization policy to be enforced by the remote PDP (at the recipient side) and the processing of this for PEP is to communicate this say in the form of annotation. It is possible to leave this to the semantics of each obligation and how it must be processed but as a general rule, I believe the less we leave things to be implicit in the semantics of the obligation the better. However, I agree that eventually, if this does not have a direct effect on the obligation processing by the PEP we might have to remove it. This will be clearer after the operational semantics are designed in more detail. 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? Allowing non-transactional enforcement can be desirable in cases where allowing access takes precedence over the success of the obligation enforcement. For example, a post-action obligation to report the log of access to a remote audit server might fail in case of network problems and yet it can be argued that this should not stop access to the medical record in under emergency condition. I will fix this in the next update. 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. Thanks. I agree that the algorithm parameters are a better carrier for this feature. I will fix this in the next update as well. 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. Is this something I should apply for, or we can simply decide to use something? [DT] I think we can just decide on a URN, following the Xacml TC naming pattern of other profiles. If something needs to be formally registered we can take care of that later in the TC cycle. For example, in the Xacml 3.0 Multiple-Decision Profile (
http://docs.oasis-open.org/xacml/3.0/xacml-3.0-multiple-v1-spec-cs-01-en.pdf ), there are multiple sections that are optional for implementations to support. Each optional feature has its own identifying URN so that implementations can indicate what optional features they support. How implementations implement this discovery/disclosure, though, is not defined by XACML.