[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Minutes from 9 October 2003 Focus Group
Minor correction. The last item is #36, you have two #35's. Hal > -----Original Message----- > From: Anne Anderson [mailto:Anne.Anderson@Sun.com] > Sent: Thursday, October 09, 2003 1:34 PM > To: XACML TC > Cc: Anne.Anderson@Sun.com > Subject: [xacml] Minutes from 9 October 2003 Focus Group > > > ACTION ITEM: [Champions] please re-issue your proposals with any > issues raised below listed as open issues against your work > items. > > Present: Anne Anderson, Hal Lockhart, Tim Moses > > Agenda: Continuing reviewing XACML 2.0 work items to determine > which ones should be on the agenda for discussion at the XACML > F2F > > Tim mentioned that he is working again on the XACML LDAP > Profile. If anyone has comments or suggestions, now would be a > good time to submit them to the list. > > XACML 2.0 Work Item Review > > 26. Define policy reduction (partial evaluation) of a policy > > This was assigned to Frank as a Grid requirement, but at the > SAML F2F, the working group determined there were existing ways > to meet the Grid requirement. > > This is a candidate for closure unless someone wants to pick it > up as useful for policy analysis, debugging, etc. > > Any takers? If not, this should not be on the agenda for the > F2F. > > F2F: probably not. > > 27. Version number element or attribute in an XACML policy > > This seems like a reasonable and useful feature. We did not > review the actual proposal, but observed that "latest version" > should be the default. > > F2F: no. Resolve by e-mail > > 28. Define "current time/date/dateTime" during policy evaluation > > The attendees agreed that, assuming no time/date/dateTime > attribute was included in the PEP's input Request Context, then > the context handler should retrieve the local > time/date/dateTime when first needed, use it to populate the > Request Context, and from then on that same value should be > used. > > This discussion agrees with the proposal. > > F2F: no. Resolve by e-mail > > 29. Policy Authority Delegation > > We had a number of questions about this. It needs > clarification. Issues: > > a. Define "domain". What does it correspond to? > b. Could this be solved using a subject-domain or > resource-domain attribute that the PEP should include in its > Request, and that policies could match on? > > Wait for Frank to provide clarification before putting on F2F > agenda. > > F2F: not until/unless Frank clarifies, but then possibly > > 30. Passing of explicit policy in the Authorization Decision Query > > This was discussed at the SAML F2F, and the working group > decided the Grid requirement could be satisfied using other > models. Therefore, this is a candidate for closure. > > F2F: no > > 31. Attribute Issuer as Subject > > The attendees had a number of issues with this and feel the > work item needs a more precise definition. > > a. Can this be solved using an XACML policy used by the PDP's > context handler: Something like 'subject A is allowed to > perform the "issue" certificate action on resource "subject > B" or resources with attribute "name-domain" = B' > b. Is this mainly an issue of aligning SAML and XACML syntax? > c. Does an authentication chain really belong in the resource > policy? Isn't it a separate policy? > > F2F: not unless clarified, then possibly > > 32. Standardize naming to specify rules for requestor's authz policy > > Again, clarification is needed. > > a. What entity is the "requestor"? The PEP? We don't usually > think of a "requestor" having its own policy... > b. Would this perhaps be a Grid Profile for Use of XACML? > c. XACML already allows new SubjectCategory values to be > defined simply by defining a new urn. Grid could define > such a urn. > > F2F: not unless clarified, then possibly > > 33. XACML wsdl/porttype definition for <Req>/<Resp> exchange. > > This should probably be in a profile for use of WSDL with > XACML, which could be independent of XACML 2.0. It is a > reasonable and useful thing to do. > > F2F: no. > > 34. porttype/operations to ask for required attributes > > This requires a new, undefined interface to XACML and the > functionality of that interface is not in the scope of the > existing XACML specs. WSPL covers it, but not XACML 1.0/1.1. > It would be possible to return the Distributive Normal Form for > a policy (which specifies sets of attribute name/value pairs > that are sufficient to satisfy a given policy) as described in > one of Anne's early WSPL submissions. > > The XACML Response Context area designed for returning > Attributes that are missing might be used with this. > > This operation is not satisfied by a SAML AttributeQuery, since > an AttributeQuery is designed to return a set of Attributes > that have actually been issued to a given Subject. #34 wants a > list of Attributes that would be needed. > > F2F: no. > > 35. Policy on revealing missing attributes > > We discussed this superficially, but discussion not conclusive. > > 35. Check for requester authorized to ask for authz decision > > Comment that XACML may be used already for this as a policy > used by the context handler or entity that handles the > authentication layer around an XACML Request/Response > transaction. Discussion not concluded. > > That is as far as we got. > > -- > 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 > > > To unsubscribe from this mailing list (and be removed from the > roster of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_w orkgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]