[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] future feature idea
my assumption has always been that version is at least implied in the
naming of the referenced resource (i.e. 'slipstreaming' is bad juju).
URL dependent systems almost demand it. if you look at any RFC or most
specifications, version information is apparent in the pointer:
http://www.w3.org/TR/1999/REC-html401-19991224/
http://www.w3.org/TR/1999/PR-html40-19990824/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
of course this isn't enforceable to any great extent (other than mother
nature's way of thinning the herd via support cataclysm :o), but it is
common (consciously or not, we rely upon this now for specification
references throughout the existing spec). not sure how this plays out in
shared libraries, etc., but i suspect that renaming files isn't going to
go over to well as a means of version reference :-) on the other hand,
trying to specify version information internally will have its pitfalls
(what do you do with externally referenced BINARIES? laugh now, but
kookier things have happened!)
as i opined earlier, i don't think event driven updates are practical
outside of an enclosed system (unless we go *way* outside of the lines)
because that opens a messaging nightmare. internal implementation? great
idea, but not as a specificed mechanism.
that's my 0.1024852 Batswana Pulas
b
Seth Proctor wrote:
> 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]