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 of 26 February XACML Focus Group

[Note: we reviewed all the 2.0 work items that have not been
explicitly dropped, and their status in indicated below.  We did
not discuss all the items that have been targetted for
specifications other than XACML 2.0, such as various profiles.]

Minutes from the 26 February 2004 XACML Focus Group

  Anne Anderson,
  Tim Moses,
  Mike McIntosh

Agenda: Continuing discussing XACML 2.0 work items
Action item: Tim will publish a draft 6 with all the stable work
   items agreed to so far.

WI#7. ConditionReference

   Need final consensus proposal from the proponents.

WI#9. Policies referring to hierarchical resources

   Open issue on handling things like "read" in a file system
   requiring "execute" permission on all elements higher in the
   hierarchy.  Anne will look at WS-ResourceFramework.

WI#10. Parameters for Combining Algorithms

   Seems to be close to consensus here.  Tim will see if enough
   information to include in next draft.

WI#11. XACML Extension Points

   Feb. 12 meeting suggested not having any general extension
   points, but accepting specific extensions where justified.

WI#12. Environment Element in Target

   Already in 2.0 draft.

WI#13. Optional Target Elements

   Already in 2.0 draft.

WI#18. Obligations in Rules

    http://lists.oasis-open.org/archives/xacml/200401/msg00062.html [Polar issues]
    http://lists.oasis-open.org/archives/xacml/200402/msg00013.html [Michiharu use case]
   Waiting for Polar's alternative.

WI#22. time-in-range function

   Already in 2.0 draft.

WI#23. Use XQuery comparison functions for date, time, dateTime

   Need update from Seth on whether progress is being made.  How
   long are we prepared to delay 2.0 for this?

WI#27. Version number element or attribute in an XACML policy.

   Already in 2.0 draft.

WI#28. Define "current time/date/dateTime" during policy evaluation

   Already in 2.0 draft.

WI#29. Policy Authority Delegation

   For F2F.

WI#31. Attribute Issuer as Subject

   For F2F.

WI#32. Standardize naming to specify rules for requestor's authz policy

   Waiting for Frank to discuss his use case verbally.

WI#36. Check for requester authorized to ask for authz decision

   For F2F.

WI#37. Multiple <AttributeValue> elements for single <Attribute> in Request

  We looked these over, and agreed Rebekah has found
  inconsistencies.  Since they are editorial, Tim will correct
  them in the next draft, and Rebekah can review the fixes.

  1)  ResourceAttributeDesignator (lines 2318 - 2327),
  ActionAttributeDesignator( 2343 - 2352) and EnvironmentAttributeDesignator
  (lines 2369 - 2378) all refer to "a bag containing all the (resource,
  action, environment) attribute values that are matched by the named
  (resource, action, environment) attribute.

  a)  I presume this text corresponds to the description of the returned bag
  for an AttributeSelector as described in line 2448 - 2454?

Tim will look into this.  The results for an AttributeSelector
and for an AttributeDesignator should be the same type.

  b)  In the section for SubjectAttributeDesignator (lines 2268 - 2310), there
  is no mention of a bag returned containing the values even for a categorized
  subject.  Does this imply a different processing requirement for

No.  Text should be made consistent.  Tim will do.

  2)  Can an element be defined directly with the type AttributeDesignatorType
  or was the intention that this complex type definition serve only as the
  root of a type hierarchy?

Intention was only the root.  AttributeDesignatorType maybe
should be made abstract.  Tim will look into this.

  3)  Lines 2445 - 2454 define processing rules that relate to the
  MustBePresent attribute of an AttributeSelector, including the required
  status code.  No such constraint on the required status code is listed in
  lines 2264 - 2266 for AttributeDesignators.  Should there mandatory status
  codes specified?

Yes.  The results obtained form an AttributeSelector and from
AttributeDesignators should be consistent.  We should copy the
text from AttributeSelector into the text rfor AttributeDesignator.

  4)  Line 2707 indicates that the data type of the AttributeValue MAY be
  specified by using the DataType attribute of the parent Attribute element.
  However, line 2683 indicates that DataType xml attribute of an Attribute
  element is mandatory.  Is this a contradiction?

Line 2707 should be changed to say MUST, not may.

  5)  AttributeValueType.  Lines 2456 - 2469 indicate that a DataType URI is a
  required xml attribute required for the complex type in the xacml namespace.
  Lines 2696 - 2708 indicate do not define such a required xml attribute for
  the AttributeValueType in the xacml-context namespace.  Lines 3448 - 2469 of
  the Appendix state that an XACML <AttributeValue> element MAY contain an
  instance of a structured XML data type. Lines 3524 - 3525 says "The
  <AttributeValue> element SHALL represent an explict value of a primitive
  type.  The example shows the use of an Attribute value element as the child
  of the <Apply> element.   Lines 3534 - 3535 states "The
  <AttributeDesignator> and <AttributeSelector> elements SHALL evaluate to a
  bag of a specific primitive type. Do these different characterizations

Note that we have two different definitions for AttributeValue;
the one in the Request Context does not have its own DataType -
it uses the the Attribute DataType element.  The AttributeValue
in a Policy does have its own DataType xml attribute.

Lines 2456 - 2469 apply to AttributeValue in a Policy.

Lines 3534 - 3535 are in the appendix describing standard
functions and datatypes, so that is why A.7 says the type must be
primitive type.

  6)  Is it reasonable to state that a named attribute appears in the context
  of Policy syntax but not Context syntax?

Tim will resolve.

  7)  Is the string equality requirement listed on line 2999 the string
  equality function defined at line 3643?

Tim will resolve.

WI#38. Policies for the Administration of XACML Policies

  For the F2F.

WI#39. Make Status in the XACML Response optional

   Already in 2.0 draft.

WI#40. Define a SAML PolicyQuery and PolicyStatement

   Anne has published a working draft for the SAML Profile.

WI#42. Requests asking for access to multiple elements in a hierarchical resource

   This is actually different from #9.  #9 needs to say how, in a
   policy, a condition can be made to apply to an entire subtree
   in a hierarchy, rather than having to spell out

WI#43. Examine interactions between approved work items


WI#45. Fix AttributeAssignment example in Section (Rule 3)

   Already in 2.0 draft.

WI#46. Status detail for missing attributes

   Waiting for Seth to produce schema for specifying a missing

WI#47. New SAML Authorization Decision Query/Response using XACML

   Being dealt with in the SAML Profile document.

WI#48. PAP Interface to a PDP/PRP

   For XACML Interface Definitions Specification.  Tim will get
   to this soon.

WI#50. Fix obligations erratum: fulfilled by PDP

   Already in 2.0 draft.  CLOSED.

WI#51. Clarify obligations: "fulfill" vs. "understand"

   Already in 2.0 draft.

WI#52. New section explaining not backwards compatible and listing changes

   Needs to wait for all changes to be made.

WI#53. Drop <Function> element

   Will this change with the new reference proposals?  Tim has
   not yet clarified the explanation in the current draft.

WI#54. Is resource-id required?

   Needs to be incorporated into the next draft.  This has been
   resolved by a vote on 8 Jan to make resource-id optional.

WI#55. Converge SAML and XACML Attribute schema definitions

   Some of this is going into the XACML Profile; rest depends on
   continued conversation with SAML people.

WI#56. Should Request Context be optional (non-normative)

   Hal's detailed text was accepted 8 Jan 2004.  This is in Tim's
   draft of Draft 6.

WI#58. Standard hierarchy schemas

   Anne still working on this.  Can be in a separate profile, so
   2.0 need not wait for this.

WI#59. Define standard "role" subject attribute

   12 Feb 2004 FG recommended including in next draft.

   26 Feb 2004 FG recommends putting this into the next version
   of the RBAC profile.

WI#60. Define standard "purpose" attributes

   Tim has published a draft Privacy Profile as a contribution.
   The TC needs to agree to make this a Working Draft.

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]