[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]