RE: [xspa] Two comments to the XACML profile

["Moehrke, John (GE Healthcare)" <John.Moehrke@med.ge.com>]

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