[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Corrected: minutes 15 January 2009 TC meeting
|
Date:
15-Jan-09
Time: 10:00 am ET Tel: 512-225-3050 Access Code: 65998 Agenda: 10:00 - 10:05 Roll Call & Approve Minutes (Note: while we are on weekly schedule, Bill and Rich are doing alternate weeks of mtg proposal and minutes.) Roll Call: Voting Members Erik Rissanen Axiomatics AB Bill Parducci Individual Rich Levinson Oracle Corporation Hal Lockhart Oracle Corporation Anil Saldhana Red Hat Seth Proctor Sun Microsystems Members Darran Rolls SailPoint Technologies John Tolbert The Boeing Company 6/9 voting: have quorum Approve Minutes: 8 January 2009 TC Meeting Minutes - Update #2: http://lists.oasis-open.org/archives/xacml/200901/msg00030.html 10:05 - 10:10 Administrivia Jira/Subversion update http://lists.oasis-open.org/archives/xacml/200901/msg00008.html TC can only have single jira project, they suggest profiles be "tasks" so we have to update "everything". Bill proposes we continue working the way we have been, i.e not use Jira. Erik: maybe just use it for core. Hal: that would be confusing w multiple places to look for issues. Not clear why Jira is being managed as only one project per TC, but that appears to be unworkable for us right now. Public Review of XSPA Profile of XACML v2.0 for Healthcare v1.0 60 day review cycle begins: http://lists.oasis-open.org/archives/xacml/200901/msg00013.html The "related files" ref'd in the email have pointers to them in the references section of the document. 10:10 - 11:00 Issues Issues within TC: Advice Obligation Type (Erik updated proposal based on last week's discussion, there were also follow-up emails to this email): http://lists.oasis-open.org/archives/xacml/200901/msg00017.html Main issue: do we want 2 options. Erik withdrew proposal. Consider other ways to solve use case. http://lists.oasis-open.org/archives/xacml/200901/msg00034.html Multi-Decision Profile Proposal (also may address all or part of "Subject Inconsistencies" from last week): http://lists.oasis-open.org/archives/xacml/200901/msg00015.html and follow-up emails. "Multi-decision": current suggestion Hal's scheme <Attributes> level items get xml:id attrs, preceded by list of sets of items that are combined into virtual request context. These lists could have multiples of same category interpreted as cross product. Hole in scheme: each list produces single decision. Cross product requires multiple responses. [Correction: there is no explicit "hole" in the scheme that this comment is referring to. It should simply be regarded as an impression that more work is needed before there is general agreement that the scheme is accepted. There are several follow-up comments on this scheme that are still ongoing as of the time of this correction. - rich] Hal will do revised scheme. Any attribute in 2.0 can be marked for return, and then used for correlation. Erik in 3.0 can say what attr values you want back. in 2.0 in result can set ResourceId and that's all. Hal: in 3.0 "IncludeInResult" Rich: Possibly a CorrelationId attribute in the Attributes element would be more useful, since results are based on combos of Attributes elements, not the child Attribute elements. Also, could result in adding extraneous attrs to the Attributes collection just for purpose of correlation. Policy Combining (additional review was in progress): http://lists.oasis-open.org/archives/xacml/200901/msg00016.html Tony was to get back w their analysis Returning a Request Context in the Decision Request Protocol http://lists.oasis-open.org/archives/xacml/200901/msg00014.html Use cases: Erik asked to clarify the feature: the main issue appears to be what, in addition to original submitted request may be returned - i.e. additional attrs obtained by PDP from other contexts may not be ok to return to PEP. [Correction: the above description gives the unintended impression a clarification is still needed, which it is not. (This was poor grammar on my part, which really was abbreviated note-taking, which should have indicated that "Erik had asked Hal to clarify the feature to ensure that no attrs other than those submitted in the request were being required to be returned." The emails in the thread that followed showed that Erik accepted the text of the changes as being consistent with that view. The bottom line on this issue is that the text as suggested by Hal is accepted by Erik and no objections were raised to going ahead and applying that text to the document. - rich] Possible problems w hierarchical profile: http://lists.oasis-open.org/archives/xacml/200901/msg00031.html Rich: main issue is that "hierarchy" is ambiguously defined. Thinks that hierarchy should mean one parent, one root. In general, multiple "hierarchies" can be brought to bear on given decision, and a given node can belong to multiple hierarchies, and the hierarchies may span different collections of resources and/or have partial/complete spanning of one set of resources, but each "hierarchy" should be one parent one root. DAG can map one to another and allows multiple parents. (Rich: but that's a "DAG" not a hierarchy, this is not the DAG profile of XACML.) URL hierarchy and file hierarchy Hal, Seth: it was used to emulate some policy models that used hierarchical scheme and some still had constructs non-representable. Seth thinks it should be cleaned up. But is it worth it. Anil: agree hier profile w seth. Is it used or not? Seth: largely unused. Allows policies to make references to hierarchical entities without knowing who related to who. Hal: profile just had "usable amount of stuff". Rich: scope in multi-profile vs parent/ancestor in hier will come up w suggestion for how to address. Erik sent helpful memo just prior to discussion, but it was not read in time for discussion: http://lists.oasis-open.org/archives/xacml/200901/msg00037.html Meeting adjourned - remaining issues next time: Issues from xacml-comments and xacml-users lists: What are rules, if any, for schema-validating Requests and PolicySets prior to delivery to the PDP. If some do, some don't then what does this do to interoperability and overall security concerns: http://lists.oasis-open.org/archives/xacml-users/200901/msg00023.html XSPA Profile has some inaccessible links: http://lists.oasis-open.org/archives/xacml-comment/200901/msg00000.html |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]