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 - UPDATED

This email is an update to the previously published minutes:
as suggested by David Chadwick:
This email should be the minutes to vote for approval at the
TC mtg tomorrow: 16-Dec-10

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

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

Doron Grinstein
Sridhar Muppidi
David Chadwick
Jan Herrmann

Voting Members: 8 of 12 (66%)

Approve Minutes:
18 November 2010 TC Meeting (updated)

    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:
 erik comment:

   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:
 much discussion on this issue - these links point to Nov, Dec:

   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

    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:
greg comment (rich submitted on greg's behalf):
rich comment:
greg response:
franz response:
paul response:
greg providing more context on issue:

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:
 rich comment:
 david response:

WSDL for v3.0 (carried over from previous meeting)
Jan volunteered to investigate at 11/18 mtg

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