[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes 12 February 2009 TC meeting - upd w attendance
Time: 10:00 am EDT
Tel: 512-225-3050 Access Code: 65998
Proposed Agenda for 12-Feb-09 TC Meeting:
10:00 - 10:05 Roll Call & Approve Minutes
Voting Members
Erik Rissanen Axiomatics AB
Bill Parducci Individual
Rich Levinson Oracle Corporation
Hal Lockhart Oracle Corporation
Anil Saldhana Red Hat
Darran Rolls SailPoint Technologies
Seth Proctor Sun Microsystems
John Tolbert The Boeing Company
Duane DeCouteau Veterans Health Administration
David Staggs Veterans Health Administration
Members
Anil Tappetla Cisco Systems, Inc.
5 February 2009 TC Meeting Minutes
http://lists.oasis-open.org/archives/xacml/200902/msg00004.html
minutes approved no objection
10:05 - 10:15 Administrivia
"deprecation terminology" investigation:
Erik posted agreed approach in XACML core WD8 (below)
Hal was going to try to get more info: ITU-T etc.
Hal: no more info, but we are going ahead w wording
Two new xacml events: calls for presentations:
European Identity Conference 2009 (EIC): 5-8 May 2009 Munich, Germany
European e-ID Management Conference: 25-26 June 2009 London, England
http://lists.oasis-open.org/archives/xacml/200902/msg00007.html
Hal: 2 presentations in Europe
pam_xacml added to TC home page
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml#other
http://lists.oasis-open.org/archives/xacml/200812/msg00004.html
Anil S. - has stuff on PAM as well
Subversion live now live at Oasis
Bill to report on conformance test progress there
http://lists.oasis-open.org/archives/xacml/200901/msg00071.html
Hal: trying to get procedures clarified; not going to make
rules change for informative docs this year. We will just
put conformance tests there for now.
10:15 - 11:00 Issues
[Documents posted]
XACML 3.0 Core WD 8 uploaded by Erik:
http://lists.oasis-open.org/archives/xacml/200902/msg00003.html
Erik: major new: combining algs, advice
Hal: advice and obls appear in same place, obls are mandatory
to understand but not advice
Erik: also both appear at the rule level
Erik: only issue left on core is the multi-decision schema
there is a comment on the combining (xacml-comments or
xacml-user this morning)
[New Issues]
Product Data Sheet
Already ref'd in References: http://www.soph-ware.com/products.html
http://lists.oasis-open.org/archives/xacml/200902/msg00005.html
http://www.oasis-open.org/committees/download.php/27298/xacmlRefs-V1-84-1.htm#Products
Open Issues in SAML Profile
http://lists.oasis-open.org/archives/xacml/200902/msg00006.html
see details of issue actions, resolutions in copy of email below:
RBAC Profile
Darran follow-up to discussion in last week's minutes:
http://lists.oasis-open.org/archives/xacml/200902/msg00008.html
Darran: address isat rules
Hal: not aware of any general REA architecture; our rbac profile
has free floating pieces.
Rich: examples - should use existing profile capabilities, if
new fcns reqd that may be issue
Erik: doesn't want new fcns to delay;
Hal: sod? what why dropped?
David: sod was demo'd
Erik: dynamic separation is where issue comes in.
Darran: examples within current scope ok to move ahead.
adding more info in examples
Rich: line 147-149 of v2.0 says sod not addressed; also
section 3 does talk about REA.
Darran: final point in email -
David: in US realm; certification committee looking at archs for rbac,
can be proposed to cochair on that committee as well.
[carryover from previous meetings]
Hierarchical profile
v3.0 Hierarchical Resource Profile Proposal (wd-04)
http://lists.oasis-open.org/archives/xacml/200901/msg00079.html
Erik's example to incorporate:
http://lists.oasis-open.org/archives/xacml/200901/msg00037.html
hierarchical node id datatype (xacml-comment):
http://lists.oasis-open.org/archives/xacml/200901/msg00056.html
question on hierarchical progenitor node (xacml-comment):
http://lists.oasis-open.org/archives/xacml-comment/200901/msg00004.html
hierarchical examples Erik says are in conformance tests:
http://lists.oasis-open.org/archives/xacml-comment/200810/msg00003.html
Multiple Decison Request Proposal
Erik still working on proposal.
Meeting adjourned: 11:04 AM ET
*********************************************
SAML Profile email: w actions and resolutions annotated to
all the issues raised:
-------- Original Message --------
Subject: [xacml] Open issues in the SAML profile
Date: Mon, 09 Feb 2009 12:56:59 +0100
From: Erik Rissanen <erik@axiomatics.com>
To: XACML TC <xacml@lists.oasis-open.org>
All,
Here are some issues in the SAML profile which I have pointed
out earlier, but I never got any response to since we started
discussing the ReturnContext issue, and forgot about these.
(I have made some improvements to these proposals since my
previous email.)
Note, these all apply to the working draft 5 which Anne finished
before she left. Not the original 2.0 SAML profile.
1. We have previously talked about how policies supplied in a S
AML XACML Authz request are in relation to the other policies in
the PDP. We said some weeks ago that the supplied policies will be
inserted in the top level policy set *before* the existing policies
in the PDP. I noticed that the SAML profile draft already contains
text on this issue which says *after* the existing policies.
I think it makes more sense to put policies before since then for
some combining algorithms they will be more significant which might
be desirable if you are providing policies in the first place.
*** Proposal: change insertion of policies to *before*.
Resolution: ok, tc accepts proposal
2. *** Proposal: fix wording on wording on page 24, around line 768.
It says "If the CombinePolicies XML attribute is true,. then
the PDP MAY choose to use such XACML Policy instances.".
I think it should say "..., then the PDP MUST combine the supplied
policies with the existing policies in the PDP".
The same wording appears also at the top of the next page,
which should also be changed.
Resolution: ok, tc accepts proposal
3. In section 4.7 there are some TBDs about matching the holder of attributes.
This can be easily fixed now that the core schema is done.
*** Proposal: fix the attribute holder matching. It should say that
"The <Match> elements shall be evaluated according to the XACML
schema against the <Attributes> elements in the <Request>.
If any <Match> element evaluates to "Match" then the supplied
attributes shall apply to the <Attributes> element which was
referenced by the attribute designator or selector contained
in the <Match> element".
Hal: policy issuer always uniquely identified, this relates to
changes in those other places. May need additional props
for the policy issuer - need to find what this clump of
attrs apply to and this is what does that.
Issue: when Anne wrote it, core schema was not yet defined
Resolution: ok, tc accepts proposal
4. *** Proposal: change wording at end of section 4.11. It says now
"An implementation MUST be prepared to handle any circular
dependencies that may arise".
This could be interpreted such that the PDP must be able to
resolve circularly inherited attributes among the supplied
attributes in a SAML XACML Authz request. This is not the intent.
It was meant to mean that the PDP must not crash or otherwise
behave badly if there is a circular dependency.
I propose that we say
"An implementation is not required to resolve any inherited
dependencies between supplied attributes, but MUST NOT treat
any circular dependencies which may arise as an error or
otherwise fail on them."
Erik: has to do w supply of attrs - if related to holder then they
could inherit in improper manners, e.g. circular dependencies;
Anne says impl must be able to "handle" it; a,b,c example
verbally described - clarify wording to just ensure it doesn't
crash.
Erik: there are provided attrs, outside RequestContext; after pdp
finds group A, it doesn't need to then go get more attrs.
Hal: sounds like proposal is a single level process to avoid
circular.
Hal: put aside for now, move on.
Action: Erik will send out email w more explanation
5. In section 5.2, page 33, it says that
the <ReferencedPolicies> MUST contain copies of all policies
referenced from the supplied policies.
I think this is a too strict requirement and it may in many
cases be useful to have SAML XACML policy assertions with
"external" policy references, and it should be allowed.
*** Proposal: Change the above mentioned MUST to a MAY in the section 5.2.
Erik: conceivable that policy references contained in message, says
currently ref'd policy must be included.
RBAC profile has ref'd policies that do not fit proposed model.
Rich: what, in general, does pdp do if a PolicyRef not resolvable.
Hal: should look into that - may not be there explicitly.
Hal: should not be left uncertain what to do.
Action: Erik: proposal ok w additional wording pdp uses same mechanism
as internal policies (which now also needs to be looked into)
6. In section 5.6, at the end of page 35, it says that
"The <saml:Issuer> element identifies the entity that generated
the XACMLPolicy Response message".
I think it should not always have to like this.
I can imagine situation where a policy repository contains signed
policies in SAML assertions and those are returned by a policy query.
In this case I might want to receive the original issuer of the policy,
rather than the policy query service as the issuer.
*** Proposal: Change the text to
"The <saml:Issuer> element identifies the originator of the contained
XACML Policy, which MAY be the generator of the XACMLPolicy Response
message".
Resolution: ok, tc accepts proposal, similar to pki revocation lists
- net distr point may be diff from authority source.
7. Section 8 contains specifications for metadata.
This section is to a large degree unfinished work.
Instead of including this section here and now,
we should write a proper metadata profile,
which should be compatible with the SAML metadata framework.
*** Proposal: remove section 8 for now.
Resolution: ok, tc accepts proposal - need fresh schema there
8. Section 9 contains (line 1248) a really long URN, which I think is a typo.
**** Proposal remove the prefixing duplicate URN string.
RResolution: ok, tc accepts proposal - typo, fix (somebody pasted twice)
Best regards,
Erik
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]