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] | [Elist Home]

Subject: [xacml] Proposed resolution to PM-2-05: Ensuring Completeness

Anne had wrote:
[This proposal depends on the proposed resolution to PM-3-03 and
PM-3-03A: each PDP will have one base
<policyCombinationStatement> or <policyStatement>]

Resolution: A PDP must have a single base policy, which may be
either a <policyStatement> or a <policyCombinationStatement>.
The combiner algorithm in this base policy, together with the
tree of associated <policySet> and <ruleSet> declarations,
specifies the complete set of rules that the PDP will use in
evaluating an access decision request.

This resolution is against the Version 12 document:

I would suggest that we add a Normative section for Operational Semantics.
I suggest that we put it between Section 8 and Section 9 (of course
altering the numbering of 9 to 10, etc). We may add more normative parts
for other operational parts of the model. However, I think the only one we
have to really worry about is the PDP, which is the XACML policy language

However, given the enormous flexibility of our model, I don't think we can
actually state specify by XACML language alone, what happens behind the
PDP, a.k.a retrieving policies, attributes, (lazy evaluation) etc. It
appears that our PDP can be an interconnected collection of PRPs, PIPs,
and even other PDPs recursively. I think it best just to state the
compliance rules for a PDP for our viable language elements.

The basic crux of the argument is that the when faced with evaluating a
XACML policy or policy set it will do so in accordance to the semantics
that we lay out in this document. (I've kept the terminology somewhat
non-saml specific (i.e. "authorization decision request"), and apply that
conformance to the SAML profile section.

Here it goes:

8.0 Operational Model (Normative)

8.1 Policy Decision Point (PDP)

Given a valid XACML "policy statement" or a "policy set statement", a
compliant XACML PDP MUST evaluate that statement in accordance to the
semantics specified in Sections 5, 6, and 7 when applied to an
"authorization decision request". The PDP MUST return a "authorization
decision", with one value of "permit", "deny", or "indeterminate".  The
PDP MAY return an "authorization decision" of "indeterminate" with an
error code of "insufficient information", signifying that more information
needed. In this case, the "authorization decision" will list any the names
of any attributes of the subject and the resource that are needed by the
PDP to refine its "authorization decision".

Decision Convergence

A client of a PDP MAY resubmit a refined authorization decision request in
response to an "authorization decision" of "indeterminate" with an error
code of "insufficient information" by adding attribute values for the
attribute names that are listed in the response.

When the PDP returns an "authorization decision" of "indeterminate" with
and error code of "insufficient information", a PDP MUST NOT list the
names of any attribute of the subject or the resource of the "authorization
decision request" of which values were already supplied in the
"authorization decision request". Note, this requirement forces the PDP to
eventually return an "authorization decision" of "permit", "deny", or
"indeterminate"  with some other reason, in response to successively
refined "authorization decision requests".

9. Profiles (Normative, but not mandatory to implement)

9.2 SAML Profile

A compliant SAML based PDP MUST reply to an SAML Authorization Decision
Request with a SAML Authorization Decision in accordance with operational
semantics of the PDP stated in Section 8.1.

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

Powered by eList eXpress LLC