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: Re: [xacml] BATCH #2: E-mail vote to close issues...

Title: BATCH #2: E-mail vote to close issues...
"each predicate in a <target> must refer only to attributes that will always be
present in a SAML access decision request"
I think we had a discussion on that last monday and there was no agreement.
I have 2 proposals for that:
1. To say nothing.
2. To say that pdp should be able to obtain values of attributes in saml compliant manner.
----- Original Message -----
Sent: Thursday, April 04, 2002 1:27 PM
Subject: [xacml] BATCH #2: E-mail vote to close issues...


This e-mail vote is to officially close the following batch of issues.  The proposed resolutions are included.  (As Anne has noted, there are two resolutions given for PM-2-05 but one appears to be favoured.  Silence on this issue, therefore, indicates an acceptance of Polar's proposed resolution.)  If you have any objections to the resolutions on any of these issues, please make them known to the list by responding to this e-mail.  A new resolution (or an amendment to the current resolution) must be included in your posting.

This e-mail vote closes at the end of the day on Thursday, April 11, 2002.  If no objections are posted by that time, the current batch of resolutions will pass and the issues will be closed.


    From:   Anne Anderson[SMTP:Anne.Anderson@Sun.com]
    Sent:   Thursday, April 04, 2002 12:45 PM
    To:     Carlisle.Adams@Entrust.com
    Cc:     Anne Anderson
    Subject:        Issues ready for e-mail vote

    MI-1-03, PM-2-05, PM-2-06, PM-8-05, PM-3-04

    The final text for the proposed resolutions follows.  Note that
    there are two proposed resolutions for PM-2-05, although I think
    mine got unofficially voted down.

    MI-1-03: Definition and purpose of Target (Anne)

    Proposed Resolution: a <target> element consists of three
    predicates over elements in a SAML access decision request: one
    over Subject, one over Resource, and one over Action.  Any of
    these predicates may be universal in that they may result in
    "true" for "anySubject", "anyResource", or "anyAction".

    the <target> element in a <rule>, <policyStatement>, or
    <policyCombinationStatement> has two purposes.  First, it allows
    <rule>s, <policyStatement>s, and <policyCombinationStatement>s to
    be indexed based on their applicable subject, resource, and/or
    action.  Second, it allows a PDP to quickly and efficiently
    reduce the set of <rule>s, <policyStatement>s, and
    <policyCombinationStatement>s that must be evaluated in response
    to a given access decision request.

    These intended purposes place three restrictions on what can be
    included in a <target>.  First, the predicates in a <target> must
    be very efficient to evaluate.  Second, each predicate in a
    <target> must refer to only one of <subject>, <resource>, and
    <action> (for indexing purposes).  Third, each predicate in a
    <target> must refer only to attributes that will always be
    present in a SAML access decision request, since a <target> must
    not return a result of "indeterminate".

    In a <rule>, the <target> element is logically part of the
    <condition> element.  Were indexing and efficiency not a concern,
    the tests in the <target> could be incorporated into the
    <condition>.  The <target> element serves as the "first pass"
    test for whether the rule applies:

        if (<target> == true) {
            if (<condition> == true) {
                return <effect>;
        return <not applicable>;
    PM-2-05: Ensuring Completeness (Anne and Polar)

    Anne Proposed 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.

    Polar's Proposed Resolution: 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.
    PM-2-06: Encapsulation of XACML policy (Anne)

    Proposed Resolution: The XACML syntax will not contain its own
    security features.  An XACML rule has no XACML-specified
    encapsulation.  An XACML policyStatement or
    policyCombinationStatement MAY be encapsulated in a SAML
    PM-8-05: How to return obligation via SAML (Michiharu)

    Proposed Resolution: Here is an authorization decision syntax
    that returns obligation(s). SAML AuthorizationDecisionStatement
    is extended to include xacml:obligations element by type
    extension. "samle" namespace prefix is used to indicate SAML
    extension for the decision assertion with obligation. Note that
    the following example just shows the overview for simplicity.

      <saml:AuthorizationDecisionStatement Resource="aaa" Decision="Permit"
       <saml:NameIdentifier SecurityDomain="aaa" Name="Alice"/>
      <saml:Actions Namespace="http://www.oasis-open.org/xmlactions">
       <xacml:obligation obligationId="myId">

    The following "samle" schema fragment defines an authorization
    decision with obligations.

    <complexType name="AuthorizationDecisionStatementWithObligations">
        <extension base="saml:AuthorizationDecisionStatementType">
            <element ref="xacml:obligations"/>
    PM-3-04: Pseudo Code for Combiner Algorithms (Ernesto)

    Proposed Resolution: Java syntax should be used to describe any
    mandatory-to-implement combiner algorithms.

    Anne H. Anderson             Email: Anne.Anderson@Sun.COM
    Sun Microsystems Laboratories
    1 Network Drive,UBUR02-311     Tel: 781/442-0928
    Burlington, MA 01803-0902 USA  Fax: 781/442-1692

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

Powered by eList eXpress LLC