[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes 12 February 2009 TC meeting
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 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]