[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for New Orleans F2F
below are the minutes for the face to face in new orleans. as usual the written summary can't do justice to the thought process (much less the passion by which the ideas were presented ;o), but the combined efforts of anne and i should give those of you who were unable to attend a good idea of where we stand on the remaining v2 issues. b ======================================================= = Meeting Minutes for April 28, 2004 F2F, New Orleans = ======================================================= Attending: (v) Mike McIntosh, IBM (v) Michiharu Kudoh, IBM (v) Ed Coyne, Veterans Health Administration (v) Hal Lockhart, BEA (p) Don Choi, US Defense Information Systems Agency (v) Simon Godik, Overxeer (v) Polar Humenn, self (v) Bill Parducci, Overxeer (v) Anne Anderson, Sun (v) Daniel Engovatov, BEA (v) Tim Moses, Entrust (o) Thomas Bui, Boeing ACTION ITEMS: 1. [Simon]: provide Tim with reference for the canonical time format. 2. [TC]: supply Bill with list of things to include in the changes/backwards compatibility section. 3. [Anne]: produce revised Hierarchical Resources proposal. This is the only item somewhat committed for 2.0 that has not yet been resolved. 4. [Polar]: produce a working draft with absolutely no Haskell of a proposed solution for delegation. 5. [Anne]: MAY produce a non-normative introductory document that duplicates much of what is in Sections 2-4. 6. [Daniel]: produce well-written, clear proposal for Hierarchical Resources. 7. [Michiharu]: describe how resource-ids are generated from RequestContext is generated, in case of XML documents. 8. [Anne]: get Tim her comments, proposed corrections on Functional Requirements section. 9. [Tim]: based on Anne's notes and existing Base Policies section, describe the three levels of PEP conformance. 10.[Anne]: SAML Attribute Profile for XACML draft. 11.[Frank]: provide proposal for environment attributes related to time intervals. 12.[Michiharu,Mike]: find out what the licensing requirements are for Obligations. May be in the form of a contact person and telephone number. We know they are RAND. We need to know what the royalties will be. 13.[Michiharu]: provide the patent # for the Obligations patent that has issued in the U.S. 14.[Tim]: provide Anne with leaf names of the two schema URLs. 15.[Anne]: ask OASIS webmaster for and provide Tim with 2 fixed URLs that terminate in the two leaf schema names. ========== Meeting began 9:00am, quorum reached. Agenda review. ========== SAML and XACML Attribute Convergence: [Anne] presented draft SAML profile for XACML to cover requests between PEP <--> PDP <--> PRP [Tim] discussed current draft from SSTC on the topic. The two current options for attribute type-casting: in-band (instance) and meta data exchange, the latter a current mechanism supported by SAML. The general consensus is that the TC work to provide a profile for each. SSTC has a document in progress that Anne and Tim will work with the appropriate SSTC members to derive a solution that is mutually acceptable to both TCs. ========== XACML constraints on PEP: Upon discussion, the TC arrived at three conforming PEP models: Base, Deny-Biased, Permit-Biased. Base conformance: * Permit access if Response is "Permit". If Obligations are presented, then Permit only if understand, can discharge, and will discharge any Obligations returned with the response. * Deny access if Response is "Deny". If Obligations are presented, then Deny only if understand, can discharge, and will discharge any Obligations returned with the response. * Not Applicable Response: access behavior is undefined. * Indeterminate Response: access behavior is undefined. Deny-biased conformance: * Permit access ONLY if Response is "Permit". If Obligations are presented, then Permit only if understand, can discharge, and will discharge any Obligations returned with the response. All other Responses result in the denial of access to Subject. Note: other actions--consultation of additional PDPs, reformulation/resubmission of query, etc.--are not prohibited. Permit-biased conformance: * Deny access ONLY if Response is "Deny". If Obligations are presented, then Deny only if understand, can discharge, and will discharge any Obligations returned with the response. All other Responses result in the permission of access to Subject. Note: other actions--consultation of additional PDPs, reformulation/resubmission of query, etc.--are not prohibited. ========== Base Policy discussion: The concept of a Base Policy was discussed. The following definition emerged: Section 7.2: For purposes of this specification, in relation to a particular Request, a given PDP is defined as a Policy Combining Algorithm and a set of policies and/or policy sets. The PDP SHALL return a Response as if it evaluates a single policy set consisting of this Policy Combining Algorithm and the set of policies and policy sets. TBD: align with Section 2.10 We would move the remaining existing text in 7.2 that describes various "MAY" models - collecting applicable policies in response to the contents of the Request into a PolicySet template that has a pre-defined PolicyCombingAlgorithm, etc. - into Sections 2-4. Note that this might affect Conformance Tests. ========== Are XACML policies portable? [Polar] Can't expect any particular attributes from the request. If could depend on getting subject-id, resource-id, action-id, and the standard environment attributes, then could write a policy that would always apply. But this could be done with a profile document. ========== Hierarchical Resources: (see also “Alternate Hierarchical Resource Proposal” below) The policy considerations necessary to protect hierarchical resources was discussed. Anne began the discussion with a review of her proposed solution. After significant discussion the matter, a number of issues remain: * Support normative, but not mandatory? * Do we need a new DataType for "xpath-expression" (see possible uses below)? Requires DataType to be evaluated to see if it is valid. Probably sufficient to say "#string, limited to 'must be an XPath expression'". There is no currently defined data type for an "XPath" expression, so we would have to define one. * What information is supplied in the Request Context in order to request access to a hierarchical resource? PROPOSAL: <Resource> <Attribute AttributeId="...:xpath" DataType="...:xpath-expression???"> <AttributeValue DataType="...:xpath-expression???"> [expression] </AttributeValue> </Attribute> <ResourceContent> [an XML document representing the hierarchical resource] </ResourceContent> </Resource> * Do we retain existing XACML 1.1 support for "scope"? [Daniel] wants it. * Does the PDP iterate through each node in the requested node set, returning one <Result> element in the <Response> for each such node? PROPOSAL: Yes, or equivalent to. Each <Result> element includes the ResourceId of the node to which it applies (what DataType?? xpath-expression that evaluates to exactly that node?) and <Decision> (Permit, Deny, Indeterminate, NotApplicable) for that node. * Does PDP return <Result> elements only for leaf nodes? Probably yes. * Is there an easy way to optimize, so that minimal re-evaluation of XPath expressions is done? * Is there a standard way to create an XML document from a hierarchy that is not an XML document to begin with? USE CASE: Unix File System PROPOSAL: Create document in which XML tags are the values of the IDENTITIES of the nodes in the hierarchy. Directory subtree: //aaa/b/c/d //aaa/e //aaa/f/g/h //aaa/f/i/j becomes: <aaa> <b> <c> <d/> </c> </b> <e/> <f> <g> <h/> </g> <i> <j/> </i> </f> </aaa> * Are there hierarchies we want to support that do not have identifiers for each node that can be used as tags in this way? * Do we need to be able to attach attributes such as "owner" to nodes in the hierarchy. * Is there a simpler syntax to use for specifying paths and subtrees in the hierarchy than XPath [Daniel Action Item]. * Do we need any hierarchy-specific functions other than the existing xpath-node-match? Probably not. =========== Veteran’s Health Administration Presentation: [Ed] presented CCOW Health care Implementation. * user-centered technique for integrating applications * HL7 context management * Context manager: sentillion Want to have multiple applications view same patient context information. Change patient being viewed in one, and it changes in others. Applications come from different vendors, have different interfaces, etc. Want to use Tivoli for the transport, communication between entities, which they hope will be enabled to use XML. Planning to use XACML and XACML Profile for RBAC. Tim pointed out that XACML RBAC alone does not support Separation of Duty. XACML can handle if, for example, once Action A is performed by Subject A, the application writes Subject A into the document as the entity that performed Action A. Then XACML can be used to say Subject for Action B must not match the identity of the entity that performed Action A by making an AttributeSelector into that field of the document. =========== Presentation Obligations in Rules: Michiharu presented a simple Use Case to illustrate the use of Obligations in Rules 1st Rule: Simon can eat weeds on weekdays. 2nd Rule: Simon can eat weeds on weekends. 1st Rule: Simon can eat weeds on weekdays, but Obligation=charge $5 2nd Rule: Simon can eat weeds on weekends, but Obligation=charge $10 In XACML 1.0 have to create two Policies to achieve same effect. [Bill] To handle "conflicting obligations", just define one big Obligation ($5 on weekdays, $50 on holidays) and let the PEP interpret it. Obligations are opaque to the PDP so there doesn’t seem to be any value to the XACML specification to add this overhead to the policy decision device. [Polar] If we add Obligations to Rules, we have no difference between Policy and Rule. Tentative conclusion: drop this work item for 2.0. [Michiharu] is comfortable with this. ======================================================= = Meeting Minutes for April 29, 2004 F2F, New Orleans = ======================================================= Attending: (v) Mike McIntosh, IBM (v) Michiharu Kudoh, IBM (v) Ed Coyne, Veterans Health Administration (v) Hal Lockhart, BEA (p) Don Choi, US Defense Information Systems Agency (v) Simon Godik, Overxeer (v) Polar Humenn, self (v) Bill Parducci, Overxeer (v) Anne Anderson, Sun (v) Daniel Engovatov, BEA (v) Tim Moses, Entrust (v) Frank Siebenlist ========== Meeting began 9:00am, quorum reached. Agenda review. ========== Distributed Administration: [Frank] presented his proposal for distributed administration. After several hours of discussion there weren’t any immediate objections to pursuing the general model further. [Hal] concerned that Issuer is only constrained by Subject, however didn’t feel that this will necessarily be a problem in practical terms [Daniel] concerned that revocation is not addressed [Polar] concerned that they model may “get away” from the intended implementation. [Tim] is concerned that the complexity of a fully generalized model may take a long time to resolve and that we may wish to add some constraints that will limit this. [Hal] Since this will not make it into the 2.0 specification that we shouldn’t consider limitations yet. Also, called for examples of cases that are either not covered or are more fully explanatory. Submissions should be presented as Working Drafts (vs. simple e-mail threads). ========== WI #68 – Attribute assertion: After significant discussion, the conversation distilled to [Frank] asking for a mechanism that allows a Subject to query a PDP for conditions by which access is granted to a resource in a time interval. It was the general consensus of the TC that XACML is not designed to behave in this fashion. Hal proposed that a time-interval attribute mechanism be defined as a potential mitigation alternative. Frank agreed that this would be of value. Action Item: [Frank] will formulate a specific proposal to address this. ========== [Polar] The current spec mentions the PDP as being the source for current time and that this should be the Context Handler. It is generally agreed this is the correct and that the retrieval of time and date information is done by the Context Handler and not by the PDP. ========== [Simon] Proposed that all time values referenced in XACML must be in the Canonical format defined by XML Schema. ========== WI 52 – Section on differences between XACML v1.1 and v2.0 [Bill] requested input on format and granularity of content. Areas of interest include: * Backwards compatibility * Loss of “Any” * Semantics of missing components have changed * Variable Definition & Reference Combining Parameters * Expression substitution groups * Look in SAML diff doc as a template * Version in Policy ========== WI 65 – Addition layer of aggregation to XACML [Daniel] taken care of by work underway with SAML. Work Item closed. ========== Alternate Hierarchical Resource Proposal [Daniel] revisited Hierarchical resource topic since he is concerned that only a single ResourceId represents multiple [child] resources in a single request. [Daniel] proposed two independent mechanisms. 1) A shortcut for submitting multiple Request Contexts in one to a Context Handler. The Context Handler is responsible for decomposing those into separate RequestContexts, each about one resource in the original RC. The PDP will make its decisions based on one decomposed <resource> at a time, and will never be able to see more than one <resource> at a time. Following syntax is from [Anne]. [Daniel] presented a somewhat different syntax for this that would require the PDP itself to decompose the multiple requests. <resources> <resource> resource1 </resource> <resource> resource2 </resource> [...] </resources> Before the PDP sees this RequestContext, it is modified by the Context Handler into a sequence of RequestContexts, which are presented to the PDP one at a time. Each such RequestContext contains one of the <resource> elements from the original. The <Result> from each decision is included in the <Response> to the original many-in-one RequestContext. This mechanism MAY be used to request multiple elements in a hierarchy, but it is not limited to that. The XPath approach allows one statement for expressing the set of resources for which individual decisions are requested. It is limited to hierarchies, and works best with XML resources. 2) Orthogonally, [Daniel] has proposed a mechanism for supplying the ancestors/parents of a resource, by supplying an Attribute containing a bag of the resource's ancestors/parents. It does not require any particular syntax for expressing the ancestors, and the ancestors do not even need to be in the same tree. It loses all information about the chaining of the ancestors. But is this information actually useful? The XPath approach also proposed a mechanism for supplying the position of a resource in a hierarchy, by supplying a description of the entire resource as an XML document. With Daniel's proposal, a policy can contain predicates like: <and> </a/b/c is in resource-ancestors> <action-id = read> </and> These two mechanisms MAY be combined to produce an alternative way to ask some types of questions about hierarchical resources. <resources> <resource> resource-id=/a/b/c/d resource-ancestors={/a/b/c, /a/b, /a} </resource> <resource> <--this resource is not part of the same hierarchy, but is an example showing how the proposal is not limited to describing hierarchical resources resource2 resource-ancestors={lzq, px} </resource> <resource> resource-id=/a/b/c resource-ancestors={/a/b, /a} </resource> ... </resources> There is NO requirement that there be any connection between the individual <resource> elements that are supplied. The PDP will make its decision based on only a single <resource> element at a time, and it will not even see the others. ============= SAML Attribute Assertions [Hal] Can a SAML Attribute Assertion refer to anything other than a Subject in an XACML RequestContext? How a SAML Attribute Assertion where the SAML Subject is actually an XACML Resource would work. How does the Context Handler know whether to plug the SAML Attribute value into the Subjects, Resource, Action, or Environment section of the RequestContext? [Anne] If the PDP passes a ResourceAttributeDescriptor to an AttributeFinderModule, the AttributeFinderModule can use the existing "resource-id" Attribute value to request a SAML Attribute that has that id as its SAML Subject. "Subject" and "Resource" are relative to the context in which they are used. A SAML Subject is simply the subject entity of the attribute value binding. It does not imply anything about the role that entity plays in other contexts, where it might be a resource that is bound to a security label, for example.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]