Title: 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