[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for 16 December 2010 TC Meeting
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 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 to linking svc to get the batch; hal: saml has an acct linking protocol david: it does - that's interesting 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 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; 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]