OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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


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


Darran Rolls     SailPoint Technologies
John Tolbert     The Boeing Company   

    6/9 voting: have quorum

Approve Minutes:

 8 January 2009 TC Meeting Minutes - Update #2:

10:05 - 10:10 Administrivia
 Jira/Subversion update

    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

    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:

    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):

    Main issue: do we want 2 options. Erik withdrew proposal.
    Consider other ways to solve use case.

 Multi-Decision Profile Proposal (also may address all or part
 of "Subject Inconsistencies" from last week):
 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):

    Tony was to get back w their analysis

 Returning a Request Context in the Decision Request Protocol

    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:

    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

    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:

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:

 XSPA Profile has some inaccessible links:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]