Re: 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)
One concept that seems workable for binding the attribute recs from
various sources together is to have the user provide the key and proof
of ownership (i.e., id and password) for addl source databases via
challenge at first attempted use of each addl attr database; then that
binding is stored by the user's "home" ID provider for future use. This
is similar to the process used to persist by the commercial provisioning
products to persist the links to authoritative attr DBs that do not have
a common key.
Specification of this type of architectural solution may not be in-scope
for XACML (or SAML) standards, of course.
Martin
Martin F. Smith
Director, National Security Systems
US Department of Homeland Security
NAC 19-204-47
(202) 447-3743 desk
(202) 441-9731 mobile
(800) 417-6930 page
Original Message-----
From: xacml-return-2313-martin.smith=dhs.gov@lists.oasis-open.org
[mailto:xacml-return-2313-martin.smith=dhs.gov@lists.oasis-open.org] On
Behalf Of David Chadwick
Sent: Monday, December 20, 2010 2:33 AM
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] Minutes for 16 December 2010 TC Meeting
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
*****************************************************************
---------------------------------------------------------------------
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