[xacml] [batch #2] counter propoposal to 3-04

[bill parducci <bill@parducci.net>]

counter propoposal to 3-04. i think that we should 'officially' use
c/c++ syntax for mandatory-to-implement combiner algorithms. for what i
think we need to do i believe that it is going to be virtually identical
and it doesn't have a vendor specific connotation.


b

On Thu, 2002-04-04 at 13:27, Carlisle Adams wrote:
> 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
> >