OASIS eXtensible Access Control Markup Language (XACML) TC

  • 1.  Minutes for 2 December 2010 TC Meeting

    Posted 12-02-2010 23:01
    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
    
    
    


  • 2.  Re: [xacml] Minutes for 2 December 2010 TC Meeting

    Posted 12-03-2010 15:12
    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
    
    *****************************************************************