OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]