RE: [xspa] Two comments to the XACML profile

["Davis, John M." <Mike.Davis@va.gov>]

John,

I agree that a general purpose profile is useful so that other domains can leverage it by applying international and realm-specific vocabularies and that is included in scope of the XSPA work.  Part of the XSPA work per their charter is also to specifically provide a US Domain profile supporting TP-20.  This includes the necessary vocabularies such as those that you have identified which are/will be directly called out in TP-20.  The XSPA TC is following the mandate of their charter. 

Secondly, the healthcare representatives working in the XSPA TC are also the same ones working in the OASIS XSPA TC, including the TP-20 author.  It's hardly a case where HITSP is suddenly being presented with something they didn't ask for.  This profile and its activities have been discussed in HITSP committee and drafts of these profiles have been provided to the Security, Privacy and Infrastructure committee.  The demonstrations to date have all been OASIS-HITSP co-sponsored and have been very successful and have included in the profiles the vocabularies specified in TP-20 as described and referenced in the profile effort underway.  In addition, as you well know, HL7 is continuing to advance these vocabularies, already accepted by HITSP and referenced here as well as standards from other healthcare SDOs.  The point is that HITSP does in fact have a stake in XSPA and is determining the vocabulary as part of TP-20, and the vocabularies cited in the profiles reflect that fact (except maybe POU which right now does not have a home).  

Lack of definitive standard vocabulary in this area is in my opinion causing the "self-inflicted" confusion to efforts such as NHIN, which is rolling its own vocabularies lacking a definitive U.S. specific SAML Authorization Profile, for example.  

Let's understand that the XSPA charted effort was always intended to include both a U.S. realm specific profile and a more general one.   There is also the long-term maintenance issue, the opportunity for other verticals to work within OASIS for the same purpose, the fact that the vocabulary standards in the HITSP profiles are or will be explicitly cited in TP20, and the pressing need for a clear and complete profile that can be demonstrated.  Given the above, I believe the current direction is sound and on track.  

HITSP made the decision to pursue creating these profiles in OASIS some time ago.  This was done specifically to avoid creating them directly in HITSP (which was a possibility) or even IHE (which was unable to get these on their schedule in time).  It was done based on the likelihood that HITSP would be incapable of maintaining the profiles over the long term and that they should therefore need to belong to an SDO. 

I'm concerned that this late discussion revisiting decisions already made is only going to delay or cancel work well in progress. The fact is that HITSP has been unwilling to take on this effort in committee or even stand up a working group for TP-20 as I recommended months ago. If you or HITSP wants to change that, then bring up the long-term ownership and maintenance of these profiles again as a topic during our TP-20 F2F discussions next week in a more appropriate venue.  


Regards, Mike Davis, CISSP
Department of Veterans Affairs
CHIO Emerging Health Technologies
Standards Security Architect
Co-Chair HL7 Security WG, Co-Chair ASTM PMI WG
760-632-0294

-----Original Message-----
From: Moehrke, John (GE Healthcare) [mailto:John.Moehrke@med.ge.com] 
Sent: Thursday, October 23, 2008 7:46 PM
To: Duane DeCouteau; Erik Rissanen
Cc: xspa@lists.oasis-open.org
Subject: RE: [xspa] Two comments to the XACML profile


I very much agree with the statements. I think that we are confusing demo with what should be put into this standard/guidance. I raised this question on the HL7 permissions call yesterday as well. Even that group is going to moiré and more fine grained object, and yet I don't see any use-cases that are calling for more fine-grained. The use-cases I am seeing are far more concerned with simple issue of federated access and how to control access. This is simple for the XACML community, but the not for current healthcare community. 

So the goal of the XSPA workgroup may seem easy, but I assure you that it is ground breaking to the healthcare community (I suspect almost all industries). It is to make the basics of SAML/XACML/WS-TRUST solution as easily understandable as possible. The HL7 permissions, HL7 consent directive, confidentialityCode, etc; are all self-inflicted confusions that healthcare can work out themselves (as said by someone inside that space). XSPA should take as little, course-grained, of the healthcare specifics and explain how they fold in and thus 'work'. Simply understanding the intersection of these two communities and being able to explain it is highly important.

What this means is that I don't think XSPA should include normative requirements to utilize any healthcare specific vocabulary.

This normative binding of specific vocabulary to specific workflows can be done, and should be done, by HITSP. They have specific workflows in the cross-community space, with stakeholders, business actors, and defined objects/documents. Most importantly they have the authority from the US government to do this job. 

John Moehrke
co-chair of the HITSP - Security, Privacy and Infrastructure committee



> -----Original Message-----
> From: Duane DeCouteau [mailto:ddecouteau@sbcglobal.net]
> Sent: Tuesday, October 21, 2008 3:58 PM
> To: Erik Rissanen
> Cc: xspa@lists.oasis-open.org
> Subject: Re: [xspa] Two comments to the XACML profile
> 
> Erik,
> 
> Response 1.  It is important that we don't confuse our interop
> demonstrations use of obligations during RSA2008 and London as a XSPA
> implementation or design requirement, they are not.  I agree that there
> are better ways of doing this, I also believe this is something that
> should be left to the vendor community and Healthcare systems that
> implement this standard.
> 
> Response 2.  HL7 provides widely accepted international standards for
> Healthcare.
> I have an action item to update the profile adding the OID
> representation of the HL7 Permission Catalog.  The HL7 Permission
> Catalog provides us our object/action pairing, this update should
> resolve any scaling and maintenance issues.  The XACML profile also
> describes the optional use of SNOMED-CT.  SNOMED-CT provides the
> implementor with additional clinical detail.  Regardless of which
> object/action vocabulary is used, I think we both can agree, that each
> healthcare organization will need to translate to their applications
> internal object/action pairings.
> 
> A supporting examples document is already being worked on   Your
> architectural vision and input would be very much welcomed in its
> development.
> 
> Regards,
> 
> Duane
> 
> Erik Rissanen wrote:
> > All,
> >
> > I have two concerns about the XACML profile. I have had these on my
> > mind for a long time, from the RSA interop itself, but I haven't had
> > time to work out concrete proposals yet, so I haven't posted about
> > them to the list. But I'll post these concerns anyway now, since the
> > profile is moving forward.
> >
> > 1. The manner by which content based filtering is done, that is, the
> > "do not show radiology reports" use case, is probably not done in a
> > scalable way. It means implementing special case treatment in the
> > PEP/application for each type of resource which can be filtered out.
> > It might be better to increase the granularity of the requests
> > instead, ideally using the multiple resource profile of XACML. Then
> > there is no need for filtering in the PEP/application.
> >
> > 2. I have concerns about the way HL7 based attributes are used in the
> > requests. The problem is that if the application is producing these
> > attributes, then the application will be tied to the current HL7
> > authorization model, and you get stuck with a legacy problem if/when
> > HL7 changes or something new is done. I have some early ideas for how
> > it should be done instead, but I haven't worked out the details yet.
> >
> > I think what is needed is an architecture which differentiates between
> > different kinds of attributes which are derived from different
> > sources. This architecture could contain metadata repositories for
> > security model specific attributes and perhaps attribute
> > translation/inheritance. I would prefer the profile to have such an
> > architecture explicitly visible so people don't hardcode HL7 into
> > their applications. (Perhaps the architecture could be a specification
> > by itself, on which the HL7 profile can be based on.) However, doing
> > so would mean more technical work and would delay the profile. Maybe
> > the current approach could be a good first iteration?
> >
> > Note that I am not saying the the HL7 attriributes are wrong as they
> > are, just that the profile should elaborate on how the attributes are
> > produced and distributed, to provide guidance to implementors.
> >
> > Best regards,
> > Erik
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php