minutes 15 January 2009 TC meeting

["Rich.Levinson" <rich.levinson@oracle.com>]

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.

	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.

  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