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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: future feature idea



[note: no, I don't expect this to get picked up for 1.1, but I've been  
thinking about it quite a bit lately, so I thought I'd send it on now
for future consideration]

Much of the recent conversation around Rule References, Properties, etc.
has brought up the issue of management. How do I know when something has
changed out from under me? How do I know what affect changing my policy
will have on other policies? How do I know that a policy still has the
same meaning (roughly) that it had before? These are all important
issues, and lead to the general issue that management of decentralized
XACML policies will be very challenging. What I'm going to suggest here
will not solve all the problems, but it could help a little, and since
I've been weighing its pros and cons lately, I thought I'd throw it out
here and see what other people think.

As I was thinking about shared libraries recently, it occured to me that
XACML doesn't provide a fairly fundimental feature, namely versioning.
There is no way for me to reference a policy and know which version of
that policy I'm getting, or whether I'm still getting the policy that I
was originally relying on. Yes, you can sign a policy, and therefore
ensure that you're getting a particular policy, but there's no way to
specify a set of versions that are acceptible, and there's no way to
specify within a policy that a given reference must match a given
signature. Soo, here's what I was thinking about.

I think it might be useful to have optional XML attributes on the
Policy[Set]IdReference tags as well as the Policy[Set] tags. A reference
could specify what version it required, or that it required a policy of
some version or earlier, or in some range. A Policy[Set] could specify
its version, update it as the policy changes, and a relying policy could
be treated as invalid if the right versions of referenced policies
aren't available. There are some things that make this tricky, like how
you specify version numbers, how you get people to use versioning
consistently, and how you specify ranges, etc., so I'm not 100% on this
idea just yet. Still, I thought it might help with the management
overhead, so I thought I'd throw it out here and see what people think.

Comments?


seth



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