Re: [xacml] Minutes for 16 December 2010 TC Meeting

[David Chadwick <d.w.chadwick@kent.ac.uk>]

Hi Rich

a few minor edits below

regards

David


On 18/12/2010 02:35, Rich.Levinson wrote:
> Time: 13:00 EDT
> Tel: 513-241-0892 Access Code: 65998
>
> Minutes for 16 December 2010 XACML TC Meeting:
>
> I. Roll Call:
>
> Voting
> Hal Lockhart
> Bill Parducci
> Rich Levinson
> Paul Tyson
> John Tolbert
> Mike Davis
> David Staggs
>
> 7 of 10 (70%) quorum
>
> Non-Voting
> Doron Grinstein
> Remon Sinnema
> Sridhar Muppidi
> David Chadwick
> Jan Herrmann
> David Choy
> Nao Itoi
> Duane DeCouteau
>
>
> Approve Minutes:
> 2 December 2010 TC Meeting
> http://lists.oasis-open.org/archives/xacml/201012/msg00006.html
> updated to:
> http://lists.oasis-open.org/archives/xacml/201012/msg00016.html
>
> hal: updated minutes approved; no objection
>
>
> II. Administrivia
> Location of current Test Cases
> http://lists.oasis-open.org/archives/xacml/201012/msg00013.html
>
> -> rich: update the main page w latest location of test cases
>
>
> III. Issues
>
> Errata: xsi:type (SAML Profile)
> http://lists.oasis-open.org/archives/xacml/201012/msg00007.html
>
> IV. Comments (from xacml-comment)
>
> pdp/pep issue (raised at earlier mtg):
>
> david: user w number of attr authorities that need to be
> aggregated; dev mechanism: referral: points to additional

AAs not pips

> pips where attrs can be obtained;
>
> having some way in saml xacml attr, that is a referral
> attr telling a pip where it can get additional attrs
> from.
>
> hal: wouldn't you want to do this in saml
>
> david: if x509 cert do it this way, if saml do it that way,
> already have that mechanism; really is now extending
> to tell pip where to go to get addl attrs. No std
> format for referral, although using liberty alliance
> endpoint reference as "std".
>
> david: pep req to az svc, stdize how creds can be passed,
> it is a profile of xacml
>
> doron: done similar w customers, incl creds and cert and
> call to back end attr responder that provides addl
> attrs in form of saml; see it as continuing to be
> necessary, it is now config of pip, not core xacml;
> impl in dir abstraction layer - needs to be trust between attr providers
> and ? to make sure that attrs
> not been tampered with. important use case
>
> mike: the way david has expressed it, mike is in agreement
> with; attr referrals: are idps located elsewhere?
>
> david: all within circle of trust: ex driv license, credit
> card, health card managed by different authorities;
> user known by different identifier at each place;
> there are privacy issues; user has different identifiers
> in different dbs that need to be linked together; new
> web service: linking svc that user controls, idp goes

ipd sends referral to linking service which pip uses to get the batch

> to linking svc to get the batch;
>
> hal: saml has an acct linking protocol
>
> david: it does - that's interesting

Postscript. I know about one from Scot Cantor that assumes user has same 
unique ID at each AA. This is not a realistic scenario (its no different 
to original X.500 model of global DN)

>
> david: can be done by pep and pass whole thing over, then
> nothing needed, but people don't want hassle in pep,
> they want to say here's what we got from user, then
> pass in;
>
> jan: chain of pep's could do the same thing w 2nd pep collecting the
> additional attrs
>
> david: don't want user to get immersed in multi-single-sign-on
>
> mike: notion of user linking stuff is great, but not sure that
> should be part of std; natl health network: attrs of record
> being requested are passed among entities, so it seems need
> a combo of both
>
> hal: patient record is resource attrs, david's is subject attrs.
>
> mike: if no national registry, nothing to correlate the multiple
> identities
>
> david: don't want university to know credit card;
>
> hal: pdp needs to know all the attr providers, that's its job
>
> hal: attr manifest format: having pips in different components
> is fact of life in real world production; at least take
> username of initial authn as key, but even for more
> complex patterns; location of right attrs for user are
> either dynamic or different; we took opposite view, attrs
> are in different repositories; amf describes attrs used
> in decisions and tells how to go get them; the notion there is the
> provider of key attr the best source of info?
> we assumed that ldap would be best place as opposed to
> authn server;
> david: agree need metadata repository; this addresses: which
> one should I go to;
>
> hal: the way this scheme works is that you can get "group"
> of attrs
>
> david: also need mapping of userid to other repos
>
> hal: assume lookup key is in the context;
> david: sounds like overlap, not proposal to change core ldap,
> it is a profile - so idps peps pips know what attrs
> mean and what to do with them
>
> hal: all we were saying was if you need this attr, here's how
> to get it;
>
> david: pep is giving set of attrs; why would pip go get more
>
> hal: there are mechanisms: missing attrs (normative) and/or
> attr-finder (non-normative, but widely used technique);
>
> hal: amf also specified that attrs can be obtaind from reqctx
> or to use another attr amf?
>
> hal: time is 1:32, let's move on to btg
>
>
>
> BTG Profile (continued)
> http://lists.oasis-open.org/archives/xacml/201012/msg00008.html
>
> mike: there is "broad agreement" on 5 cases; main thing w btg,
> is descr of use case is fine, but mike says includes the
> concept that by being member of a domain, can assert, as
> a domain member, as opposed to providing a specific attr
> for that domain;
>
> david: not disagreeing on that: msg sent on 3-Dec:
> http://lists.oasis-open.org/archives/xacml/201012/msg00008.html
>
> has complex rule; put this into 2 rules; not talking about
> initiator having privs; let's remove the sensitivity and
> focus on btg; rule on btg: mike's rule is if y and x then
> but david uses 2 rules: 1 whether glass is broken, and
> other is person is allowed to break the glass; can return
> a set of obls to tell what to do when glass is broken;
>
> mike: those in domain covered by policy and others are not. there
> is single domain and segments within domain have rules;
> there is btg rule that has policies associated with it;
>
> david: agrees one domain

no, disagrees with one domain. BTG can be a multi-domain issue.

>
> david: mike's is that there is one rule that is pre-btg and
> can't send obls; pep says to pdp can user btg, pdp says
> yes, so user then does it.
>
> mike: if i'm a doctor, I can btg; if janitor, can't
>
> david: sounds ok - that's the 1st thing; the 2nd thing is - how
> do you know (point 5) to throw the exception; with david's
> model there is answer that btg result
>
> mike: the issue is that btg has a notion of acceptance by end user
> of conditions that apply now that glass is broken;
> hal: this is what a lot of firewalls do; if you try to access
> a prohibited site and they ask if you really want to do it;
>
> mike: yes, but then it is necessary to "capture" an attr;
>
> david: user is warned before executing btg what obls they will have;

not they as in the user, but rather the system will have (e.g. to report)

> they are obls in the future;
> mike: that's good; user is presented w obl and makes a promise;
> problem is across organizations; obl can be presented but
> how does requesting org present obl;
>
> david: give warning that if you take this action, then there
> are consequences for future actions
>
> mike: now passing policies to different systems; how do you display
> and collect response and put it in decision;
>
> david: we do that and it is user intf issue; need custom code
> for each appl;
>
> hal: could have text string and user says y or n; it is not necessary
> for pdp or pep to semantically be aware;
>
> mike: it sounds like all sorts of agreements are needed on what the
> interface will be
>
> david: no, can just tell user that they will be monitored
>
> mike: a display to a foreign system - if you pass obl to system B
> then there is no context for understanding it;
>
> hal: user is talking to appl - seems like several layers
>
> mike: need to get user ack back somehow; need to have interface
> where user can send resp back; requiring everyone to have
> same mechanism in place on all systems not realistic;
>
> david: but isn't oasis stds supposed to resolve these types of issues;
>
> paul: still not convinced: 1 someone asks for resource is denied,
> then says really needs it; other case is user wants to change
> the state of the system to invoke other rules;
>
> david: that summarizes nicely; we are saying user wants to chg
> the state of the system and there is rule that says whether
> he is entitled to chg state of system;
>
> mike: confusing: system is different state;
> rich: issue is where state is maintained; sent email describing
> approach w external "...btg" attr w trusted issuer; david
> had follow up comments to that, which have not yet been
> addressd
>
> mike: it is a vocabulary thing: it is an overloaded concept;
> generally use system state as well understood situations
>
> hal: time is running out; would like people to look further
> into it and more emails
>
> david: is there just one btg warning?
>
> mike: sequestered data under some special rules; that can be
> accessed; policy says something about this - protecting
> this data so that certain members can see this attr and
> if recognized then; however, if user comes in w attr
> then he already implicitly has the permission so never
> sees the warning;
>
> david: now sounds like people have the privs,
>
> hal: would like to continue discussion on list
>
>
> dayTimeDuration andyearMonthDuration datatypes missing in XACML?
> http://lists.oasis-open.org/archives/xacml-comment/201012/msg00000.html
>
> XACMLAuthzDecision Response
> http://lists.oasis-open.org/archives/xacml-comment/201012/msg00003.html
>
> LDAP Attributes
> http://lists.oasis-open.org/archives/xacml-comment/201012/msg00004.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

*****************************************************************