[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]