Greetings,
After a week of not reading email, it's made for a hell of a Sunday.
I'll look forward to the con call tomorrow.
As I have only skimmed Ann and Bill's arguments, I was thinking about this
these very problems last week while in my other OMG venue.
Base Policy. I think that the "Base" policy is merely a logical term that
refers to the policy that the PDP abides by. It may not be reproducible
in a practical manner (i.e. too large, etc.).
As for Bill's existence of a default policy I agree, I had this same
concept in SAL,
http://www.omg.org/news/meetings/workshops/presentations/docsec_present/2000/sal-ws1.pdf.
Although, not the direct subject of the paper, you might see that if you
defined a policy, you had to "apply" it to get it to work. Also, you had
to do so with a default policy of "Allow" or "Disallow",
(Apply "named policy" Disallow)
That is because the language follows the 3 valued logic approach. The
named policy may evaluate to "DoNotUse", in which case the policy engine
needed a default.
However, you are not going to get anywhere without the "Apply" construct,
i.e. Administrative interfaces to the PDP. (I think these interfaces are
out of the scope of XACML.) Unless you have notions like "set_policy" or
"add_policy" and their semantics, you will not have any semantics about
"what" policy a given PDP should follow.
As for the logic, I would follow a three valued logic, and let "Error" be
an artifact of evaluation.
I envisioned the applicable policy to contain the following semantic
notation.
Typed Inputs (SAML?):
R - Resource
A - Action
S - Subject
3 Valued (T,F,N) Policy Predicates Notation:
AP - Applicable Policy
P - Combined Policy (And, Or, etc.)
2 Valued Predicates (T,F)
T - Target Predicate
J - Subject Predicate
An Applicable Policy is of the form:
AP(R,A,S) == T(R,A) and J(S) -> P(R,A,S)
The "AP" is an applicable policy that is merely just a 3 valued predicate
that is structured with a predicate, T, on the target (R,A), and a
predicate, J, on the subject, S.
The "P" is merely an applicable policy or a combination of predicates on
R, A, and S, such using "and" and "or".
The logic (truth tables) is as follows. The operator "->" signifies a
partial function.
and T F N or T F N -> T F N
T T F T T T T T T T F N
F F F F F T F F F N N N
N T F N N T F N
You will see that this logic explains Ann's proposal. Applicable Policies
are merely clauses that are structured with the "->" operator.
If the premise of the "->" is false, the policy predicate yields "N"
(not-applicable). This works nicely with the definitions of "and" and
"or", as policies will only evaluate to "N" if their constituents evaluate
as such. Furthermore, combined policies will only evaluate to "N" if *all*
their constituents evaluate to "N", so short cuts on evaluations can
happen.
Now, there is a problem, with this pesky "<NOT></NOT>" that is wanted.
May I suggest a solution?
The problem with "not" is that it usually means "compliment" of the set.
With a 2 valued logic, {T,F} is okay because they are compliments of each
other (although when you go to first order logic, you're back in the same
boat, but I digress). With a three valued logic, that is much more
difficult. So, I would suggest to define "Not" operators for those things
where the compliments are well defined, or that are of concern to the
group. Such as
Positive Negative
-------- --------
<equal> ... <notEqual>
<lessThan> ... <notLessThan>
<after> ... <notAfter>
etc.
That way you can still have the "not" that Hal's customers want, except
not in a generalized fashion, which screws up the logic.
<and>
<not>
applicablePolicy
</not>
....
</and>
are not legal and cannot exist in the language.
Also, one other point, if we go with this approach, we have to introduce
value tags, such as "<true/> and <false?> since,
<and>
</and>
<or>
</or>
i.e. with 0 constiuents, both evaluate to "N".
So, writing an applicable policy where the T and J predicates are true may
be all there is needed to indicate that the AP policy evaluates to true.
AP(R,A,S) === T(R,A) & J(S) -> true
Do we have an agenda for tomorrow?
Cheers,
-Polar