[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of Focus Group 29 July 2004
Minutes of the XACML TC Focus Group
29 July 2004
Present:
Anne Anderson
Tim Moses
Ed Coyne
Polar Humenn
Michiharu Kudo
Agenda:
1. URI match, IP address matching
2. Hierarchical resources
3. Profiles to move to CD status along with core
4. RBAC - snag
5. Delegation
6. Date on closure for core and profiles
7. Anne on vacation
Minutes
1. URI match, IP address matching
[Tim] these were resolved on the list. We will use regexp for
everything. Bill can't say "I told you so" :-)
2. Hierarchical resources
[Anne] Plan to add new "scope" value for case where an entire
XML document or an entire sub-tree of it is to be accessed,
with one result returned.
If combining algorithm is "deny-overrides", then if any node
in the requested document is "deny" then the one result will
be Deny. If ALL nodes are "permit" then the one result will
be Permit.
All applicable policies will be applied to all nodes.
[Michiharu] Semantics of the scope must be clearly defined.
Orthogonal to the combining algorithm.
[Anne] May need to specify a "super-combining-algorithm" such
as "deny-overrides".
[Michiharu] could avoid complexity of "super-combining-alg" by
saying XACML policy does not deal with that level of
complexity. So don't introduce new level, but have the
Context Handler deal with the new "scope" value.
[Tim and Anne] agree this is a good approach.
[Tim] The Hierarchical Resources Profile will overlay the core
XACML functionality. The Multiple Resources Profile will
overlay the Hierarchical Resources Profile to specify how
"scope" is dealt with.
[Anne] issue of optimization: PDP may need to know the
scope in order to deal with entire set of nodes at once.
[Michiharu] they could use custom combining algorithm in this
case. Optimization could depend on each application's
semantics. XACML should just specify sufficient way to
specify policy that fits most use cases.
[Anne] will continue to state semantics of scope such that
requirement is for result being same "as if" given steps are
performed, but no requirement for actually performing steps
one by one.
ACTION [Anne] will produce new draft of the profile.
[Michiharu] question about examples using resource-ancestors.
Wanted to be sure Daniel was happy with the fact that it is
impossible to tell the sequence of ancestors, so can't write
policy that depends on path to the node.
[Anne] Daniel is aware of this, and seems satisfied.
[Anne] is "document-id" Attribute OK?
[Michiharu] hasn't yet done actual use case. "document-id"
might be used in the specified way (entire resource of which
"resource-id" may be a part). If target document is XML
document, then it may have "document-id", so then document-id
makes sense. But if use hierarchical resource spec with
<ResourceContent> that represents policy for file system -
there "document-id" means nothing. Fine so long as inclusion
of "document-id" whenever <ResourceContent> is optional, and
not required.
[Anne] Fine.
3. Profiles to move to CD status along with core
Hierarchical Resources
Multiple Resources
SAML
DSig Profile? - next revision will simply point to SAML
Profile as recommended way to encapsulate and sign XACML
artifacts, and will mention some of the canonicalization
issues that artifact generators will need to deal with
(since SAML punts on this). Everything just guidelines, not
normative.
Privacy Profile? - not much discussion on the list, but the
profile is very simple and short. Tim will test the waters
for the TC is interesting in progressing this.
LDAP Profile - NO: Tim has been focusing on a SQL approach rather
than LDAP, so no longer interested in progressing the LDAP
Profile. Tim's basic idea is PDPs have a "topic" that is
syntactically identical to a <Target>, but semantically says
"this is the set of queries I will answer". He has a data
model and algorithm for generating SQL queries from the
<Target>. Will not finish this in time for the Core CD vote
and standardization process.
4. RBAC - snag
[Anne] Is now convinced that the current Profile, while OK for
basic and hierarchical RBAC, does not deal adequately with
Separation of Duty. Problem is that, until policy is
executed, it is not necessarily known (and should not be
necessary to know) which role is needed for the access being
requested. Yet can't request all role Attributes, since
various roles are not allowed to be held at the same time in
Separation of Duty.
A new function can be created to request the specific role
Attribute needed, but such a function does not fit into the
model used by the current Profile (the function is described
in the current Profile).
This problem was brought to Anne's attention by Aleksey
Studnev (Exigen Group) and by Stefan Berthold, (Technische
Universitaet Dresden, Fakultaet Informatik) "eXtensible Access
Control Markup Language: XACML im Vergleich mit P3P und EPAL"
(http://dud.inf.tu-dresden.de/~kriegel/ss04/hauptseminar/Berthold2004_HS_XACML.pdf).
Aleksey proposed a solution, but Exigen Group is not a member
of OASIS and appears to be uninterested in clarifying the
status any IPR it might hold in Aleksey's solution. Anne is
doing a literature search for a free-and-clear solution.
Until and unless such a solution is found, Anne is unwilling
to progress the current Profile.
5. Delegation
[Tim] Simon has volunteered to write up a specific profile
draft.
[Polar] Fine. No time to work out the algorithm, etc. Still
thinks adding <Issuer> element is a mistake.
[Anne] Can still object to anything in the draft, as anyone
else can!
6. Date on closure for core and profiles
[Tim] Will propose at next meeting that we pick a date for
final comments on the core and any profiles that will be
progressed to Committee Draft stage with the core. There are
no outstanding specific issues, so only remaining issue is
giving people any necessary time to review and comment.
7. Anne on vacation
Anne WILL be on the call next week (5 August), but will be on
vacation the following week (12 August) and will have to miss
that call.
--
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]