[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes 26 March 2009 TC Meeting
Time: 10:00 am EDT
Tel: 512-225-3050 Access Code: 65998
Minutes for 26-Mar-09 XACML TC Meeting:
10:00 - 10:05 Roll Call & Approve Minutes
Note: we are going back to bi-weekly schedule.
Next meeting is April 9.
Voting Members
Erik Rissanen Axiomatics AB
Rich Levinson Oracle Corporation
Hal Lockhart Oracle Corporation
Anil Saldhana Red Hat
Dilli Arumugam Sun Microsystems
John Tolbert The Boeing Company
Members
Anthony Nadalin IBM Group Member
Notes:
Dilli (should have been) promoted to voting member
before the call.
Tony became a voting member after the call.
not sure if quorum
19 March 2009 TC Meeting minutes to approve:
http://lists.oasis-open.org/archives/xacml/200903/msg00089.html
http://lists.oasis-open.org/archives/xacml/200903/msg00099.html
above links are identical
hold off approval to next mtg (4/9) in case we're not at quorum
10:05 - 10:10 Administrivia
Volunteers for editorial cleanup request
http://lists.oasis-open.org/archives/xacml/200903/msg00106.html
Hal: fair amount of work to pass Mary's test.
John Tolbert: core and saml
Dilli also volunteers
Hal: looking to go to cd 2 weeks from today (goal)
Rich: aggressive?
Hal: goal, maybe month
Erik: try for 2 weeks
Hal: we will try to have docs ready for April 9 mtg.
John: how are we going to make changes? post to list?
Hal: people signup for docs, post new drafts
Rich: what is list of operations?
Hal: oasis checklist, plus internal inconsistencies, fixing is
easy when found.
Rich: need care on identifiers
Hal: identifiers all stay same; new are version 3.
Hal: up front URIs can be left until we are ready for cd, oasis
will assign us URI(s);
Links on "members only" page; follow link to tech details: following
links to oasis spec info/reqts for updates in prep for CD.
http://www.oasis-open.org/members/
http://docs.oasis-open.org/templates/
http://docs.oasis-open.org/templates/QAChecklistV2.html
http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html
v3.0 Core, Draft 10 uploaded
http://lists.oasis-open.org/archives/xacml/200903/msg00088.html
Erik: corrections, plus Category on Obligations
v3.0 XACML/SAML Profile, Draft 7 Uploaded
http://lists.oasis-open.org/archives/xacml/200903/msg00109.html
Hal: added new section in request section
ws-fed: common claims dialect: indicated could do on xacml
ws-trust: provides alternative both quite similar, should
be easy to support both in parallel
Hal: will add an example in ws-trust section
v3.0 Hierarchical Profile, Draft 6 uploaded
http://lists.oasis-open.org/archives/xacml/200903/msg00107.html
cover email for hierarchical
http://lists.oasis-open.org/archives/xacml/200903/msg00105.html
Hal: attempted to make changes based on earlier proposal
that Hal emailed;
Hierarchical URI
ancestor attributes: self, parent, ancestor, ancestor-or-self;
also can use any xacml data type
concern: the "one true name"; Hal thinks it is general issue,
discussed in core security considerations;
Rich's comments will be probably be incorporated at first glance
Misc topics:
Anil S: (arrived late): There is interop (next week) in Chicago
that he, David, Duane, others? working on.
10:10 - 11:00 Issues
Obligation Question: "AttributeAssignment@Issuer"
http://lists.oasis-open.org/archives/xacml/200903/msg00101.html
Rich: optional Issuer attr add to Obligation: agreed w Erik.
Discussion on WD 4 of Muliple Resource Profile
http://lists.oasis-open.org/archives/xacml/200903/msg00102.html
Erik: we don't send multiple response even though we have
multiple requests
Erik: If list is incorrect, there is only one Result.
Rich: partial results should be reported
Erik: basically ok
Discussion on WD 6 of Hierarchical Profile
http://lists.oasis-open.org/archives/xacml/200903/msg00110.html
Rich: multiple hierarchies should be described in some
tangible manner so that operational bullets can be
described clearly.
Hal: thinks we are in agreement will try to make some
clarifications based on comments.
Rich: below is some more detail on "what the concept is".
Specific means of presenting the concept is not of concern,
just that the concept gets across. One sidepoint is that
within a given "hierarchy" there is no problem if that
single hierarchy is a DAG w multiple roots. The only concern
is that the DAG properties of one hierarchy not "spill over"
into other hierarchies. Since the DAG, itself, may be the
result of combining multiple hierarchies, that may be where
the confusion originated. In this case if multiple original
hierarchies are combined into a DAG for some subset (M<=N) of
thetotal set of original hierarchies, that is no problem.
There will then be a new set of "original hierarchies consisting
of the DAG plus the N-M remaining hierarchies that were not
combined into the DAG. In this case in the description below
the resources originally would have had N slots. Now they
would have N-M+1 slots.
For example, if a resource can be envisioned as
having a set of "slots", each of which is assigned
to one of N possible hierarchy memberships, then
if the resource has an entry in some subset of those
slots, then the value would be its "identifier"
within that particular hierarchy.
Whenever the organization managing the resources
decided it had some new hierarchical structure that
it wanted to use with some or all of the resources,
then a new "slot" would be created identifying the
new hierarchy. i.e. these "slots" would have two
components: 1. a unique identifier for the hierarchy
with which the slot is associated. 2. an identifier
for the resource by which it is known in that
hierarchy, which as discussed can be of any xacml
datatype. Each hierarchy has its own rules for its
own members in terms of naming.
Also, a resource typically would only need to hold
the slots for which it is a member. If it only belonged
to one hierarchy, it would have one slot with the
name of the hierarchy, and its name within the
hierarchy.
My point is not to go overboard on how a resource's
membership in multiple hierarchies is implemented,
just the notion that there is some kind of mechanism
that serves the overall purpose. Another analogy would
be the credit cards in a person's wallet. If you had
3 credit cards you'd be a member of 3 credit card
hierarchies, each separate and distinct, but their
identifiers are all collected together conveniently
in your wallet. Similar for resources: they would
have a wallet of "slots" etc.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]