Re: [xacml] proposed amendment to Polar's resolution of PM-2-05

[Polar Humenn <polar@syr.edu>]

I'll take that as a friendly amendment, and I accept such friendly
amendment.

Cheers,
-Polar

On Fri, 5 Apr 2002, Beznosov, Konstantin wrote:

> While generally agreeing with Polar's proposal for PM-2-05 resolution, I
> have concern with the fact that his proposed text is vague in section
> 8.1  about whether a PDP must or may list attributes that are needed by
> the PDP to refine its decision:
> ------------------------------------------------------------------------
> ------------------------------------------
> 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".
> ------------------------------------------------------------------------
> -----------------------------------------
>
> I suggest to amend the text of the resolution so that the above fragment
> will read the following:
> ------------------------------------------------------------------------
> ------------------------------------------
> 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" MAY list the names
> of any attributes of the subject and the resource that are needed by the
>
> PDP to refine its "authorization decision".
> ------------------------------------------------------------------------
> -----------------------------------------
>
> The change makes a list of the attributes that are needed by the PDP to
> refine its decision optional.
>
> Regards
> Konstantin
>
> -----Original Message-----
> From: Carlisle Adams [mailto:carlisle.adams@entrust.com]
> Sent: Thursday, April 04, 2002 4:27 PM
> To: 'xacml@lists.oasis-open.org'
> Subject: [xacml] BATCH #2: E-mail vote to close issues...
>
>
>
> Hi,
>
> 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.
>
> Carlisle.
>
>
> 	----------
> 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.
>
> 	-Anne
> ================================================================
> 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
> evaluator.
>
> 	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
> assertion.
> =================================================================
> 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:Assertion>
>   <saml:AuthorizationDecisionStatement Resource="aaa" Decision="Permit"
> xsi:type="samle:AuthorizationDecisionStatementWithObligations">
>   <saml:Subject>
>    <saml:NameIdentifier SecurityDomain="aaa" Name="Alice"/>
>   </saml:Subject>
>   <saml:Actions Namespace=" http://www.oasis-open.org/xmlactions";>
>    <saml:Action>Read</saml:Action>
>   </saml:Actions>
>   <xacml:obligations>
>    <xacml:obligation obligationId="myId">
>      ...
>    </xacml:obligation>
>   </xacml:obligations>
>   </saml:AuthorizationDecisionStatement>
> </saml:Assertion>
>
>
> 	The following "samle" schema fragment defines an authorization
> decision with obligations.
>
> 	<complexType
> name="AuthorizationDecisionStatementWithObligations">
>   <complexContent>
>     <extension base="saml:AuthorizationDecisionStatementType">
>       <sequence>
>         <element ref="xacml:obligations"/>
>       </sequence>
>     </extension>
>   </complexContent>
> </complexType>
> ===============================================================
> 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
>
>