[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of the 5 February 2004 XACML TC Meeting
Minutes of the XACML TC General Body Meeting
5 February 2004, 10-11am EST
Attendees:
Tony Nadalin
Anne Anderson (minutes)
Michiharu Kudo
Bill Parducci (Co-chair)
Tim Moses
Maryann Hondo
Hal Lockhart (Co-chair)
Seth Procter
Steve Anderson
Polar Humenn
Frank Siebenlist
Simon Godik
Peiyin Pai (Observer)
Quorum present
1. Minutes from the 22 January 2004 TC meeting
http://lists.oasis-open.org/archives/xacml/200401/msg00052.html
Anne moved they be accepted; Hal seconded; unanimous approval.
2. Face-to-Face Meeting plans
Results as of today on the ballots to choose the date and
location are:
Can attend week of February 16 2
Can attend week of February 23 5
Can attend week of March 1 6
Can attend week of March 8 7
Can attend April 26 in New Orleans 12
Can only attend Boston 2
Can only attend Austin 0
Can attend either, no preference 0
Can attend either, prefer Boston 2
Can attend either, prefer Austin 9
Prefer week of February 16 1
Prefer week of February 23 2
Prefer week of March 1 6
Prefer week of March 8 5
Prefer April 26 7
Based on these early strong results, the Chairs will try to
arrange a meeting in New Orleans during the week of April 26 in
conjunction with the OASIS Annual Meeting and other OASIS TC
meetings.
The 3 Feb 2004 e-mail from Dee Schur at OASIS indicated that
there was already a waiting list for TCs wanting rooms for
meetings, so it may not be possible for the XACML TC to meet.
Hal will clarify this with the OASIS administration.
3. XACML RBAC Profile
The XACML RBAC Profile under discussion is at:
http://www.oasis-open.org/committees/download.php/2405/wd-xacml-rbac-profile-01.doc
Anne reviewed the history of the profile. There was a series of
meetings with the NIST RBAC team, with general approval of the
profile. The NIST RBAC team consisted of:
Rick Kuhn <kuhn@nist.gov>
David Ferraiolo <david.ferraiolo@nist.gov>
Ramaswamy (Mouli) Chandramouli <mouli@nist.gov>
John Barkley <jbarkley@nist.gov>
Two issues were raised by the NIST team, however. One was a
desire for a section on administrative policies. The other was
from Mouli, who thought he could provide a simpler way to handle
hierarchical roles in XACML. Anne responded that the RBAC
Profile actually has a section on administrative policies. It
relies on each entity (such as the Role Assigner/Enabler) using
its own XACML policy; XACML does not currently support integrated
administrative policies, such as are being proposed for XACML
2.0. On the second issue, Mouli has not produced a simpler way
to handle hierarchical roles.
Anne mentioned that many developers appear to be using the XACML
RBAC Profile, based on feedback we get related to Sun's XACML
Implementation open source. Some of these have urged making it a
standard.
Anne moved that the XACML TC approve the XACML RBAC Profile as a
Committee Draft. Hal seconded. The XACML TC voted unanimously
to make the XACML RBAC Profile a Committee Draft. Anne has an
action item to edit it into the standard Committee Draft format,
with no changes to normative text.
Anne will post the edited draft to the XACML TC mailing list for
any last editorial comments before the draft becomes the official
"Committee Draft".
4. XACML 2.0 Work Items
The TC discussed the following XACML 2.0 Work Items.
o 7. ConditionReference
General agreement that a single XML type to unify Condition,
Condition references, variable references, predicates, and values
would be good. The existing "Condition" element would be
replaced by an instance of this single XML type restricted to be
a Boolean. If a single type is not created, then the schema will
become complex: Condition will become Condition OR
ConditionReference, Apply will become Apply OR VariableReference,
etc. Exact names to be used for new elements is not settled,
however.
Tim reported that EPAL distinguishes between Predicates and
Conditions. If EPAL ever indicates interest in collaborating
with XACML, then it might be useful to preserve some of their
concepts and make use of some of their design decisions. Tim did
not feel strongly about this, just raised it as a consideration.
ACTION: Polar and Simon will produce a unified proposal and post
it to the list.
o 10. Parameters for Combining Algorithms
The current proposal for WI#11. "XACML Extension Points" is
actually a proposal limited to addressing what was
WI#10. "Parameters for Combining Algorithms". WI#10 will be
re-opened with the current proposal, while WI#11 will remain open
for possible alternative or additional proposals.
Simon clarified that, in his proposal, if a combining algorithm
does not understand the CombiningParameters, then the policy is
invalid.
Polar wants to resolve whether ConditionParameters can include
references to values, because then ConditionParameters would have
to be included in the type system. Seth likes having them
included in the type system because it makes it easier to
implement and to extend the referencing mechanism into
parameters. Can still define a DataType that is an XML
structure. Polar would like to do administration policies as
parameters to a combining algorithm.
Simon is concerned about limiting what can be put into
ConditionParameters. Doesn't want to limit them to
AttributeValue. May or may not be a problem.
Seth points out that an AttributeValue can be any type you want.
Can define new types, use XML schema instances as types, etc.
Big win to use one construct for all these.
RESOLUTION: continue discussion on the list.
o 11. XACML Extension Points
Anne presented two possible use cases for Extension Points that
are not satisfied by the proposal for WI#10: a place to put
information about the Issuer of the policy (needed by Frank's
administrative/delegation proposals); a place to put hints to the
PDP about where to find Attributes used in the policy.
Simon suggested that specific elements should be proposed for
each such use case. Anne agreed that this would be a better
approach, avoiding "kitchen sink" elements.
RESOLUTION: keep open for now as place-holder for the two use
cases, but will not necessarily do anything for 2.0.
o 13. Optional Target Elements
Current proposal: valid to leave out any Subjects, Resources, or
Actions [or Environments] elements or entire Target, where
omitted element means "no restriction", equivalent to existing
"Any...".
Polar now comfortable logically with optional target elements,
with view that they represent pre-conditions. Bill feels
optional elements are not as clear to human readers as explicit
Any elements. Bill appears to be in the minority on this.
Seth raised issue about semantics of omitted Target. Currently,
omitted Target in a Rule means the Rule inherits the Target from
its enclosing Policy. What is the meaning of "inheritance" when
the enclosing Policy also has no Target. Tim expressed the view
that the semantics of any omitted Target are "there are no
further constraints" in addition to any inherited from enclosing
policy/policyset. There was some discussion about whether this
is just wording or whether it actually has a semantic effect.
RESOLUTION: continue to discuss on list, bring to vote next time.
5. EPAL
Tim has received no response from Fred Cohen regarding the Burton
Group report that said incorrectly that XACML could not support
EPAL's "purpose" attribute.
It was suggested that the XACML TC see if the EPAL authors would
be willing to work with the XACML TC to expand or modify XACML to
meet their needs. A question was raised as to whether any TC
members felt this might be an inappropriate increase in scope for
the XACML TC, but no such concerns were expressed.
RESOLUTION: the group voted unanimously to have the chairs
approach the EPAL authors to see if they are interested in
collaborating with the XACML TC to make XACML fit their
requirements.
6. XACML 2.0 Draft 6
Tim will hold off on Draft 6 until the work items discussed today
become more clear.
7. Adjourn
Anne moved to adjourn. Maryann seconded. Meeting was adjourned
at 11am EST
--
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]