I think the original question from Polar leads two arguments: "how to
compute obligation(s) in the composed policy?" and "how to determine the
permission in the composed policy?". For the first argument, I think that
responses from both Carlisle and Bill show the reasonable semantics. The
difference is related to the interpretation of <All-must-permit> predicate
and "Indeterminate". I think this is the issue of the second argument. I am
not sure how we should determine the permission that has Indeterminate even
in the case no obligations are used.
I am not sure whether this helps our discussion, SAML defines the semantics
of <Condition> element as follows:
-If any condition evaluates to Invalid, the assertion status is Invalid.
-If no condition evaluates to Invalid and one or more conditions evaluate
to Indeterminate, the assertion status is Indeterminate.
-If no conditions are supplied or all the specified conditions evaluate to
Valid, the assertion status is Valid.
Condition uses a set of values Valid, Invalid, and Indeterminate, and it
seems to give those values a priority like Invalid
> Indeterminate
> Valid.
If we translate Valid->Permit and Invalid->Deny, then the answer of Policy
C becomes equivalent to Carlisle's idea.
Michiharu
IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642
Fax +81 (46) 273-7428
From: Carlisle Adams <> on 2002/02/22 06:42
To:
"'bill parducci'" <>
cc:
XACML TC <>
Subject: RE: [xacml] Discussion summary and revised post-condition proposa
l
Hi Bill,
I suppose it could go either way, but my feeling was that if the PDP
couldn't get an answer regarding Policy A, then it couldn't give an answer
regarding Policy C.� If more information was available, or if some server
somewhere wasn't down, or whatever, the PDP would be able to evaluate
Policy A and Policy B and return a Permit/Deny answer.� As it is, however,
it has to return indeterminate because it just doesn't know.
I can see the argument saying that "All-must-permit" means "if you get
anything other than permit, you must deny".� I could certainly live with
that interpretation if others prefer it.� This comes back to defining the
3- or 4-valued logic for each of our combinators since, at least in our
current syntax, the combinator is likely to be <and> rather than
<All-must-permit>...
Carlisle.
----------
From: � bill parducci[SMTP:]
Sent: � Thursday, February 21, 2002 4:25 PM
To: ��� XACML TC
Subject: ������ Re: [xacml] Discussion summary and revised
post-condition proposa������ l
Carlisle Adams wrote:
�> Hi,
�>
�> I've filled in the column for Policy C below.
[...]
�>������ Policy A����� Policy B���� Policy C
�>������
------------------------------------
�>������ Permit������� Permit��������������� Permit:� P, R, and D
�>������ Permit������� Deny����������������� Deny:� S, E
�>������ Permit������� Indeterminate��� Indeterminate:� no obligations
�>������ Deny��������� Permit��������������� Deny:� Q, E
�>������ Deny��������� Deny����������������� Deny:� Q, S, E
�>������ Deny��������� Indeterminate��� Deny:� Q, E
�>������ Indeterminate Permit��������������� Indeterminate:� no
obligations
�>������ Indeterminate Deny����������������� Deny:� S, E
�>������ Indeterminate Indeterminate��� Indeterminate:� no obligations
curious as to how you arrived at these:
�>������ Policy A����� Policy B���� Policy C
�>������
------------------------------------
�>������ Permit������� Indeterminate��� Indeterminate:� no obligations
�>������ Indeterminate Permit���������� Indeterminate:� no obligations
�>������ Indeterminate Indeterminate��� Indeterminate:� no obligations
given that policy C has this:
>�������� <All-must-permit>
>�������������� Policy-A
>�������������� Policy-B
>�������� </all-must-permit>
my read is that these would be resolved thus:
������� Policy A����� Policy B���� Policy C
�������
------------------------------------
������� Permit������� Indeterminate��� Deny: E
������� Indeterminate Permit���������� Deny: E
������� Indeterminate Indeterminate��� Deny: E
b
p.s. great example, polar!
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
