OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xspa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Two comments to the XACML profile


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]