MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [xacml] XACML Issues List Version 01
From: Tim Moses <>
To: 'Ken Yagen' <>,"XACML (XACML Mailing List)" <>
Date: Wed, 09 Jan 2002 17:18:56 -0500
Title: Message
Ken -
Here are some additional thoughts on our outstanding issues. All the
best. Tim.
[PM-1-01] - The current schema supports negative
authorizations.
We use a construct of the following form …
<and>
<rule1/>
<rule2/>
<rule3/>
<not>
<or>
<rule4/>
<rule5/>
<or>
</not>
</and>
rule4 and rule5 specify circumstances under which, if either
were to hold, access is to be denied. While rule1, rule 2 and rule3 specify
circumstances, all of which must hold if access is to be granted.
[PM-1-02] - The alternative view is that post-conditions must be
executed if and only if the associated rule contributes to the permit
decision.
[PM-2-01] - The current schema allows one possible way of
achieving this. Separate applicable policies from independent PAPs (Policy
Administration Points) may be combined in a single "applicable policy"
by a PRP. This approach does, however, make the original PAPs
anonymous.
[PM-2-02] - A different transform algorithm is all that is
required. In the example, the "classification" is "older than two
years", and the transform algorithm specifies how to deduce the age of a
file.
[PM-2-03] - The administrative model in Figure 9 deals with this
question, placing it out of scope for the schema. If we do need to tackle this,
I suggest leaving it for a later version.
[PM-2-04] - Section 6.4 of version 0.8 of the language proposal
is reserved for tackling this question in the LDAP case. Do we need to tackle
other cases?
[PM-2-05] - This is a job for the PRP and should (I think) be
out of the scope for our specification. The PRP has to be configured with the
names and locations of the PAPs whose policies it recognizes.
[PM-3-01] - We could add "policy" to the
"sequence" in "rule". Then we would have to give policies
unique identifiers, not just string names. Perhaps, we should add
"applicable policy", instead of "policy".
[PM-3-02] - Ultimately, the PEP has to know whether or not to
grant access. So, someone has to decide, and (by definition) it is the PDP. So,
the "don't care" response isn't helpful. However, saml should have an
error code to indicate that the PDP is not the appropriate PDP to render a
decision on a particular request.
[PM-4-01] - In the 0.8 schema, valueRef has an attribute to
indicate the entity to which it applies (principal, resource, etc.). It only has
to be consulted if the attribute type identifier is ambiguous.
[PM-5-02] - We should register an OASIS identifier for the use
of regular expressions in this context.
[PM-5-04] - Attributes in saml assertions are identified by a
namespace, which is a URI, and a name, which is a string.
[PM-5-07] - Delegation could be expressed in attribute
assertions. The very issuance of an attribute assertion is a form of delegation.
So, XACML should not have to concern itself with the process by which an entity
obtained an attribute.
[PM-6-01] - Policy environments have to use consistent type
definitions for the attributes they use.
-----------------------------------------
Tim Moses
Tel:
613.270.3183
