Minutes for 16 December 2010 TC Meeting

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

Time: 13:00 EDT
Tel: 513-241-0892 Access Code: 65998

Minutes for 16 December 2010 XACML TC Meeting:

I. Roll Call:

Voting
  Hal Lockhart
  Bill Parducci
  Rich Levinson
  Paul Tyson
  John Tolbert
  Mike Davis
  David Staggs

 7 of 10 (70%) quorum

Non-Voting
  Doron Grinstein
  Remon Sinnema	
  Sridhar Muppidi
  David Chadwick
  Jan Herrmann
  David Choy
  Nao Itoi
  Duane DeCouteau

	
Approve Minutes:
  2 December 2010 TC Meeting
  http://lists.oasis-open.org/archives/xacml/201012/msg00006.html
	updated to:
  http://lists.oasis-open.org/archives/xacml/201012/msg00016.html

	hal: updated minutes approved; no objection
	

II. Administrivia
   Location of current Test Cases
    http://lists.oasis-open.org/archives/xacml/201012/msg00013.html

  -> rich: update the main page w latest location of test cases


III. Issues

   Errata: xsi:type (SAML Profile) 
    http://lists.oasis-open.org/archives/xacml/201012/msg00007.html

IV. Comments (from xacml-comment)

   pdp/pep issue (raised at earlier mtg):

    david: user w number of attr authorities that need to be
	aggregated; dev mechanism: referral: points to additional
	pips where attrs can be obtained;

	having some way in saml xacml attr, that is a referral
	 attr telling a pip where it can get additional attrs
	 from.

     hal: wouldn't you want to do this in saml

     david: if x509 cert do it this way, if saml do it that way,
	already have that mechanism; really is now extending
	to tell pip where to go to get addl attrs. No std
	format for referral, although using liberty alliance
	endpoint reference as "std".

    david: pep req to az svc, stdize how creds can be passed,
	it is a profile of xacml

    doron: done similar w customers, incl creds and cert and
	call to back end attr responder that provides addl
	attrs in form of saml; see it as continuing to be
	necessary, it is now config of pip, not core xacml;
	impl in dir abstraction layer - needs to be trust 
	between attr providers and ? to make sure that attrs
	not been tampered with. important use case

    mike: the way david has expressed it, mike is in agreement
	with; attr referrals: are idps located elsewhere?

    david: all within circle of trust: ex driv license, credit
	card, health card managed by different authorities;
	user known by different identifier at each place;
	there are privacy issues; user has different identifiers
	in different dbs that need to be linked together; new
	web service: linking svc that user controls, idp goes
	to linking svc to get the batch;

    hal: saml has an acct linking protocol

    david: it does - that's interesting

    david: can be done by pep and pass whole thing over, then
	nothing needed, but people don't want hassle in pep,
	they want to say here's what we got from user, then
	pass in;

    jan: chain of pep's could do the same thing w 2nd pep 
	collecting the additional attrs

    david: don't want user to get immersed in multi-single-sign-on

    mike: notion of user linking stuff is great, but not sure that
	should be part of std; natl health network: attrs of record
	being requested are passed among entities, so it seems need
	a combo of both

    hal: patient record is resource attrs, david's is subject attrs.

    mike: if no national registry, nothing to correlate the multiple
	identities

    david: don't want university to know credit card;

    hal: pdp needs to know all the attr providers, that's its job

    hal: attr manifest format: having pips in different components
	is fact of life in real world production; at least take
	username of initial authn as key, but even for more
	complex patterns; location of right attrs for user are
	either dynamic or different; we took opposite view, attrs
	are in different repositories; amf describes attrs used
	in decisions and tells how to go get them; the notion 
	there is the provider of key attr the best source of info?
	we assumed that ldap would be best place as opposed to
	authn server; 

    david: agree need metadata repository; this addresses: which
	one should I go to;

    hal: the way this scheme works is that you can get "group"
	of attrs

    david: also need mapping of userid to other repos

    hal: assume lookup key is in the context; 

    david: sounds like overlap, not proposal to change core ldap,
	it is a profile  - so idps peps pips know what attrs
	mean and what to do with them

    hal: all we were saying was if you need this attr, here's how
	to get it;

    david: pep is giving set of attrs; why would pip go get more

    hal: there are mechanisms: missing attrs (normative) and/or
	attr-finder (non-normative, but widely used technique);

    hal: amf also specified that attrs can be obtaind from reqctx
	or to use another attr amf?

    hal: time is 1:32, let's move on to btg



   BTG Profile (continued)
    http://lists.oasis-open.org/archives/xacml/201012/msg00008.html

    mike: there is "broad agreement" on 5 cases; main thing w btg,
	is descr of use case is fine, but mike says includes the
	concept that by being member of a domain, can assert, as
	a domain member, as opposed to providing a specific attr
	for that domain;

    david: not disagreeing on that: msg sent on 3-Dec:
      http://lists.oasis-open.org/archives/xacml/201012/msg00008.html

	has complex rule; put this into 2 rules; not talking about
	initiator having privs; let's remove the sensitivity and
	focus on btg; rule on btg: mike's rule is if y and x then
	but david uses 2 rules: 1 whether glass is broken, and
	other is person is allowed to break the glass; can return
	a set of obls to tell what to do when glass is broken;

    mike: those in domain covered by policy and others are not. there
	is single domain and segments within domain have rules;
	there is btg rule that has policies associated with it;

    david: agrees one domain

    david: mike's is that there is one rule that is pre-btg and
	can't send obls; pep says to pdp can user btg, pdp says
	yes, so user then does it.

    mike: if i'm a doctor, I can btg; if janitor, can't

    david: sounds ok - that's the 1st thing; the 2nd thing is - how
	do you know (point 5) to throw the exception; with david's
	model there is answer that btg result

    mike: the issue is that btg has a notion of acceptance by end user
	of conditions that apply now that glass is broken; 

    hal: this is what a lot of firewalls do; if you try to access
	a prohibited site and they ask if you really want to do it;

    mike: yes, but then it is necessary to "capture" an attr;

    david: user is warned before executing btg what obls they will have;
 	they are obls in the future; 

    mike: that's good; user is presented w obl and makes a promise;
	problem is across organizations; obl can be presented but
	how does requesting org present obl;

    david: give warning that if you take this action, then there
	are consequences for future actions

    mike: now passing policies to different systems; how do you display
	and collect response and put it in decision;

    david: we do that and it is user intf issue; need custom code
	for each appl;

    hal: could have text string and user says y or n; it is not necessary
	for pdp or pep to semantically be aware;

    mike: it sounds like all sorts of agreements are needed on what the
	interface will be

    david: no, can just tell user that they will be monitored

    mike: a display to a foreign system - if you pass obl to system B
	then there is no context for understanding it;

    hal: user is talking to appl - seems like several layers

    mike: need to get user ack back somehow; need to have interface
	where user can send resp back; requiring everyone to have
	same mechanism in place on all systems not realistic;

    david: but isn't oasis stds supposed to resolve these types of 
	issues;

    paul: still not convinced: 1 someone asks for resource is denied,
	then says really needs it; other case is user wants to change
	the state of the system to invoke other rules;

    david: that summarizes nicely; we are saying user wants to chg
	the state of the system and there is rule that says whether
	he is entitled to chg state of system;

    mike: confusing: system is different state; 

    rich: issue is where state is maintained; sent email describing
	approach w external "...btg" attr w trusted issuer; david
	had follow up comments to that, which have not yet been
	addressd

    mike: it is a vocabulary thing: it is an overloaded concept;
	generally use system state as well understood situations

    hal: time is running out; would like people to look further
 	into it and more emails

    david: is there just one btg warning?

    mike: sequestered data under some special rules; that can be
	accessed; policy says something about this - protecting
	this data so that certain members can see this attr and
	if recognized then; however, if user comes in w attr
	then he already implicitly has the permission so never
	sees the warning;

    david: now sounds like people have the privs,

    hal: would like to continue discussion on list


   dayTimeDuration andyearMonthDuration datatypes missing in XACML?
    http://lists.oasis-open.org/archives/xacml-comment/201012/msg00000.html

   XACMLAuthzDecision Response
    http://lists.oasis-open.org/archives/xacml-comment/201012/msg00003.html

   LDAP Attributes
    http://lists.oasis-open.org/archives/xacml-comment/201012/msg00004.html