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: Minutes for 2 December 2010 TC Meeting


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

Minutes for 2 December 2010 TC Meeting:

13:00 - 13:05 Roll Call & Approve Minutes:


  have quorum

voting
Hal Lockhart
Bill Parducci
Rich Levinson
John Davis
David Staggs
Erik Rissanen
Paul Tyson
Gareth Richards

non-voting
Doron Grinstein
Sridhar Muppidi
David Chadwick
Jan Herrmann

Voting Members: 8 of 12 (66%) 


Approve Minutes:
18 November 2010 TC Meeting (updated)
http://lists.oasis-open.org/archives/xacml/201011/msg00015.html

	hal: minutes approved no objections

XACML v3 Status:
1 attestation received to date

New Issues:

Carrying any Policies:
 david original issue:
   http://lists.oasis-open.org/archives/xacml/201011/msg00051.html
 erik comment:
   http://lists.oasis-open.org/archives/xacml/201011/msg00052.html

    hal: starting on 3.0 decided admin policy model, additional
	policies could come effective only for one request.
	decided to make that part of saml wire protocol, not core;
	embedded pdps would probably have proprietary
	last year, chgd core schema to allow other policies in
	 policy element, but rejected that, but decided to put
	 extension point in wire protocol, there for can put
	 in policies in non-xacml format;

    david: using that extension points and obligations in transfer
	 request and obl is in response and can submit policies to
	 the pdp.



Draft BTG Profile (Break The Glass):
 david original issue:     http://lists.oasis-open.org/archives/xacml/201011/msg00017.html
 much discussion on this issue - these links point to Nov, Dec:
   http://lists.oasis-open.org/archives/xacml/201011/maillist.html
   http://lists.oasis-open.org/archives/xacml/201012/maillist.html


    hal: many emails on btg proposal;

    david: couple issues:
	1. model: what is btg; helpful msg from john w use cases
	  user is granted access, 
		denied access, 
		denied but can btg, 
		4th case

	  seth impl w/o altering pdp; david has also impl it;
	  want to define std way; pdp to understand btg; make it
	   easier for infrastructure; state-based,
	  protocol info is transferred in std way

	 issues around is there a btg operation?
	 how does pdp/ch take into acct that this is btg resp

	  suggestion on list is that it is obl; what profile
	   could do is define obl called "btg", pep understands
	   and enforces, if pep doesn't understand; happy w that
	   as soln.

	  any objections? none heard. this is just a "sign" that
	   some people are ok and no one explicitly not ok

	  will produce 2nd version of profile

	  people he's talked to agree there are 2 actions:

	   1. am I entitled to btg?
	   2. am I entitled to open the fire door

	  once you have done btg, then 2nd obl

	   1. make req, rsp says btg reqd

	   2. make req for btg permission, rsp says ok + obl

	   3. make original req w btg perm.

	mike davis: still discussing: the presence of a permission
	 that a user has btg is not what they are looking for;
	 info is protected by sensitivity issue
	 asserting that user has permission is not btg

	david: user 

	mike: auth attr is a perm;

	david: if condition is fulfilled (btg), you get access ow no.

	mike: sent out email today - incl a number of core defns
	 w use case w policy, walks thru in some detail;

	doron from bitkoo: from experiments done, bloody knuckles; just an
	 obligation w permit, need to present condition; if real
	 emergency if remote, need to work autonomously; return
	 permit w obl. fin trans: mgr override; special loan ovrd.

	 analogy of x500 vs ldap; success of ldap is simplicity;
	 keep lang simple, let people use as needed;

	david: agrees that btg and override are similar

	doron : permit w obl

	david: deny w obl, then permit w obl, and user has option
	 to do it or not.

	doron: human is another input device; pdp is not human
	 aware, it has helpers like pip to intermediate w human;

	david: 

	mike: agree w "mode c", have different view on override and
	 bypass; canadians agree, but bypass on purpose and system
	 is insecure state; btg is runtime attr asserted, not 
	 already resident in pdp; screen warning and user asserts
	 they want to btg, then user submits that attr to policy
	 and it

	doron: would you want to be in burning room where you had
	 to ask the door if you could leave

	mike: emergency is different than btg; in healthcare is 
	 condition where there is threat to safety; never kill
	 patients to protect their data; every vertical has one;
	 another: never impose security that impedes cash flow;
	 rather lose a few free videos than stop the revenue.

	mike: in emergence case you can elevate your permissions
	 to deal w emergency; define purposes of use to acct
	 for different policy context; 

	david: thinks there is agreement on distinction between
	 btg and emergency;

	 doctors can btg. doctors can access rec if btg is true.
	 same term used for 2 things; perf action to get attr
	 to get access;

	mike: if you have role of clinician; don't want to open
	 back channel to get info; as a role to start with;

	hal: need to get clear on defns before submitting recommendations;
	 what is scope of btg? if set fire alarm, it applies to
	 everyone, but this sounds more particular, is that a btg
	 user for good or is it temporary;

	mike: latest email addresses these questions; these things
	 are defined or can change defns;

	jan: sounds like only certain people can btg?

	mike: no: can constrain to subset users;

	david: thinks only diff now is if pdp is involved.

	hal: next step?

	david: critical point of disagreement is btg "permission"
	 wrt "rbac" model; diff in hotel case; it is public access
	 permission; in hospital attr restricted to "professionals".

	hal: lot of raising dynamic roles; how are these cases
	 different

	paul: analogy breaks down when restricting btg to certain
	 users; if restricted then its not btg

	hal: on PIP access what is status

	david: postpone to next mtg; still active;

	jan: nothing to report on wsdl at this point - not defined
	 where context handler is implemented?

	hal: deliberately left details unspecified. saml profile
	 effectively requires 2 chs to build message then to process
	 the msg.

	hal: please continue discussion on the list;

	doron from bitkoo: have one attestation, looking to provide
	 a 2nd one for 3.0; for xacml 2 there are use cases; is there
	 something for 3.0?

	erik: has some test cases to donate;

	hal: bill will post location of current test cases.

	adjourned 2:00 PM
	next call Dec 16.



Ongoing Issues:

Attribute Assertions in XACML request
 paul original issue:
   http://lists.oasis-open.org/archives/xacml/201010/msg00012.html
 greg comment (rich submitted on greg's behalf):
   http://lists.oasis-open.org/archives/xacml/201011/msg00001.html
 rich comment:
   http://lists.oasis-open.org/archives/xacml/201011/msg00016.html
 greg response:
   http://lists.oasis-open.org/archives/xacml/201011/msg00024.html
 franz response:
   http://lists.oasis-open.org/archives/xacml/201011/msg00044.html
 paul response:
   http://lists.oasis-open.org/archives/xacml/201011/msg00033.html
 greg providing more context on issue:
   http://lists.oasis-open.org/archives/xacml/201011/msg00025.html


PIP directive (carried over from previous meeting)
 Discussion of emails at 11/18 meeting was postponed pending
  interested parties in attendance.
 David Chadwick has raised the concept of additional processing
 associated with PDP <-> PIP interaction:
  david original:
    http://lists.oasis-open.org/archives/xacml/201010/msg00005.html
  rich comment:
    http://lists.oasis-open.org/archives/xacml/201010/msg00013.html
  david response:
    http://lists.oasis-open.org/archives/xacml/201010/msg00015.html


WSDL for v3.0 (carried over from previous meeting)
 Jan volunteered to investigate at 11/18 mtg
  http://lists.oasis-open.org/archives/xacml/201011/msg00012.html




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