RE: [xacml] BATCH #2: E-mail vote to close issues...

Title: BATCH #2: E-mail vote to close issues...

I vote 
to close these issues with the amendment to MI-1-03 that I proposed previously 
here:

 

http://lists.oasis-open.org/archives/xacml/200204/msg00062.html

 

Hal

  
-----Original Message-----
From: Carlisle Adams 
  [mailto:]
Sent: Thursday, April 04, 2002 
  4:27 PM
To: ''
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:] 
    
Sent:   Thursday, April 04, 2002 12:45 PM 
    
To:     
     
    
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:  
Sun 
    Microsystems Laboratories 
1 Network 
    Drive,UBUR02-311     Tel: 781/442-0928 
Burlington, MA 01803-0902 USA  Fax: 
    781/442-1692