OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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

  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

 Hal: 2 presentations in Europe

pam_xacml added to TC home page

 Anil S. - has stuff on PAM as well

Subversion live now live at Oasis
Bill to report on conformance test progress there

 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:

   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

Open Issues in SAML Profile

    see details of issue actions, resolutions in copy of email below:

RBAC Profile
 Darran follow-up to discussion in last week's minutes:

  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)
 Erik's example to incorporate:
 hierarchical node id datatype (xacml-comment):
 question on hierarchical progenitor node (xacml-comment):
 hierarchical examples Erik says are in conformance tests:

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>


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

   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

   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 

   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,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]