Re: [xspa] intended conformance point of the XSPA XACML profile

My responses to Richards questions and/or comments;

XSPA (not just XSPA profile of XACML) describes the minimum, minimum is keyword here, set of attributes necessary to produce an access control decision during an information exchange between two healthcare organizations..... Given that you will find areas in the profile that are vague as we made special efforts not to impose design recommendations. Implementation specific requirements can and should be included as extensions to the specification, but not in it's core. The NHIN development community has already shown it's ability to adapt XSPA and grow for it's own unique needs. There is an RFI on the street entitled: "Internet DB NW for Patient Controlled Medical Data Sharing", where regional sharing of image data, from disparate implementations, will be controlled by the patient via a web based PHR. This is just one example of why we need ensure XSPA remains light, flexible, extensible...

Hunch 1 & 2 If you would like I can give you a live demonstration of our reference implementation where we can discuss the PEP-PIP, and PEP-PDP interactions.

Attributes - Again a demonstration of our reference implementation will help you in understand the data flows let me know when we can do this, maybe this is something I can do during our next TC meeting. Also it might be good for all of us to have a live demonstration of NHINConnect v2.1 at same time. This may help all understand NHIN's needs.

Duane

From: Richard Franck <Richard_Franck@us.ibm.com>
To: xspa@lists.oasis-open.org
Sent: Thursday, June 25, 2009 9:36:17 AM
Subject: [xspa] intended conformance point of the XSPA XACML profile

Hello all,

I have been tied up in a meeting all week, so I have not been able to kick off the continued discussion on the XSPA attributes and the requirements of the NHIN. I will try to start up a couple of different threads this morning while I have some time.

This first thread is to ask a fundamental question about the nature of the XSPA profile of XACML. The question can be stated succintly as: what is the intended conformance point of this profile? In other words, of the arrows shown in Figure 1 of the profile (p. 9 of the Public Review Draft 02), which of those transactions are intended to carry the attributes defined in the profile, and in what context? I think it would also be useful to refer to Figure 1 in the XACML 2.0 CORE specification as well (p. 17). This diagram is a bit more explicit and calls out some of the data flows that are only implied in the diagram from the XSPA profile.

My hunch (and it is only a hunch, because I think there are a few different interpretations that can be drawn from the XSPA document itself), is that the attributes are intended to apply in two places:
1. Between the Policy Enforcement Point and the Policy Decision Point. This corresponds to data flow #4 in the diagram from XACML CORE. The context of the transaction is the XACMLAuthzDecisionQuery / XACMLAuthzDecisionStatement defined in the SAML-XACML profile.
2. Between the Policy Enforcement Point and the Policy Information Point. This corresponds to data flow #6 in the diagram from XACML CORE. The attributes are carried on the AttributeQuery / AttributeStatement defined in the SAML CORE profile, as described in the SAML-XACML profile. I'm not entirely clear on where in a SOAP message those attributes get carried.

It is my further hunch that it is not indended that the XSPA XACML profile applies between the Policy Administration Point and the Policy Decision Point. This corresponds to data flow one in the XACML Core diagram, and it is also described (somewhat differently) in the SAML-XACML profile as using the XACMLPolicyQuery / XACMLPolicyStatement defined in that profile.

So I have two requests:

1. Can the list confirm or correct my hunches about the intended conformance point(s) of the XSPA XACML profile?

2. Can the list help me understand the use of certain attributes defined in the profile, in terms of how it could make sense to carry them on the particular data flows? The particular attributes I have questions about are: subject:hl7:permission, resource:org:permission, resource:hl7:dissenting-subject-id, resource:hl7:dissenting-role. (And I guess all of the *dissenting* attributes defined in Table 2.) I simply cannot identify a data flow where (a) the requesting side of the flow would have the information defined by these attributes and (b) the responding side of the flow would have any need of it.

Regards,

Richard Franck
Certified IT Architect, IBM Global Business Services
Healthcare and Life Sciences
office: 1-919-254-4771
mobile: 1-919-302-3880
e-mail: Richard_Franck@us.ibm.com

xspa message