[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Minutes for 2 December 2010 TC Meeting
comments corrections On 02/12/2010 22:59, Rich.Levinson wrote: > 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 DEL and obligations in transfer request DEL > and obl is in response and can submit Sticky 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 is elevation of privileges > > 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" which is added to deny response , pep understands > and enforces, if pep doesn't understand then stays as deny ; 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 ??? not sure what user refers to?? > 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 on initial access request then permit w obl on request to btg , 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: agreed > 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 Aside. David after reading Mike's email agrees that BTG and bypass are different modes. > > 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; David. Not everyone can set fire alarm e.g. children > > 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; that should be Yes, can.... regards David > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security School of Computing, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]