Re: [xspa] Two comments to the XACML profile

[Erik Rissanen <erik@axiomatics.com>]

Thanks Duane,

About 1: But the obligations are in the spec, though they are
non-normative. I am not sure it is a good idea to have them in there in
the current form if we all know that it's not a good idea to implement
them like that. Sorry if I don't have a better alternative proposal
right now. :-) I think the key is to change the granularity of the requests.

About 2: Yes, we agree here. What I am really just saying is that this
should be made more explicit in the document. In the figure in section
2.1 I think the very high level box "PIP" should be broken up into
several pieces so it becomes more clear for implementers that there are
different kinds of attributes which are derived from different sources.
For instance "native/intrinsic" resource attributes, resource security
metadata, subject identifying attributes, subject security attributes,
federated subject attributes, etc.

Such composition into a more fine grained architecture would provide a
foundation for future extensibility, give an ability to change
individual pieces over time and help avoiding the risk of building "yet
another future legacy system". Again, my apologies for not having a
concrete proposal yet. I've been focusing on the XACML core spec, so I
haven't had the time to write down this yet.

Best regards,
Erik

Duane DeCouteau wrote:
> 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
>>
>