Re: [xspa] Two comments to the XACML profile

[Duane DeCouteau <ddecouteau@sbcglobal.net>]

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
>