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: Re: [xacml] Backgrounds of properties for new combining algorithm



> 1) Placeholder for some information used in
another access control 
> policylanguage

It sounds to me like you're talking about two
different cases here: using XACML as an intermediary
language and strictly translating from some other
language to XACML. I think you're stressing the
latter, but both of these issues apply.

In the case of using XACML as an intermediary
language (ie, a general bridge between two
proprietary languages) I think that it may well be
useful to have an area where you can include raw
information that can't easily be expressed in XACML.
Of course, this data must never be used by XACML, so
the where and how of this data being included isn't
as important.

In the case of translating from one language to
XACML (which is what you're talking about), you want
to include properties because you may need to use
custom combining algorithms and they in turn may
need special data. Unfortunately, adding properties
doesn't really solve the problem here, since what
you're really talking about is a policy language
that can't be cleanly mapped onto the semantics of
XACML. In that case, adding properties for combining
algorithms to use won't solve your problem, it might
just help things out a little. For the same reason
that you need to support new combining algorithms,
you might also need to express conditions
differently, or redefine rules, or add properties to
references. If there is a sematic mis-match, just
adding properties for combining algorithms won't
solve the problem.

Note that since you're talking about custom
combining algorithms, there are already ways to add
inputs if you need them (like getting attributes out
of the request or setting up some algorithm-specific
mechanism similar to attribute and policy
retrieval). Not that I'm advocated this approach,
I'm just saying that it can be done and it's not
more vague than what's already in the specification.
It doesn't seem to me, however, that adding
propoerties will solve your problem.

> 2) Placeholder for storing implementation specific
information

This one scares and confuses me, because now you're
not just talking about inputs for combining
algorithms, but all parts of a policy. You're also
talking about doing out-of-order execution on a
Condition, which won't always help if required
attributes aren't present. In general, it's going to
be hard to come up with the right order to do
function evaluations (some attributes might be
cached, others might suddenly become unavailable,
etc.). I agree with you that this use case isn't as
compelling.


seth



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