This email is an update to the previously published minutes:
http://lists.oasis-open.org/archives/xacml/201012/msg00006.html
as suggested by David Chadwick:
http://lists.oasis-open.org/archives/xacml/201012/msg00010.html
This email should be the minutes to vote for approval at the
TC mtg tomorrow: 16-Dec-10
Rich
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
2nd mentioned, but need details
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 point and obl in response, 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: commented on user, btg mechanics (more detail below)
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 emergency 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: yes, 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