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

# xacml message

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

Subject: RE: [xacml] Proposed Agenda for 5 May 2011 TC Meeting

• From: "Tyson, Paul H" <PTyson@bellhelicopter.textron.com>
• To: "Erik Rissanen" <erik@axiomatics.com>,<xacml@lists.oasis-open.org>
• Date: Thu, 5 May 2011 10:55:45 -0500

```Hi Erik,

I don't understand the first point, about prioritizing NA and Ind return values.  Can you give an example?

And generally I don't know why we need to analyze policy equivalence with respect to each combining algorithm.  My point is that if there is any difference in the result of evaluating equivalent policies, there is a defect in the policy evaluation specification.  The defect might be algorithm-specific, in which case the definition of that algorithm would have to be revised.

I don't say these issues can all be quickly resolved, which is why I suggest deferring them to post-3.0, meanwhile not making any prejudicial changes to section 7.

Regards,
--Paul

> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com]
> Sent: Thursday, May 05, 2011 10:34
> To: xacml@lists.oasis-open.org
> Subject: Re: [xacml] Proposed Agenda for 5 May 2011 TC Meeting
>
> Hi All,
>
> Personally I prefer it the way it is the new working draft. It allows
> for more possiblities.
>
> Creating policy equivalence would mean basically that we need to:
>
> - Define a priority between N/A and Indet for all combining algorithms.
> (Presumably N/A goes first.)
>    - A corollary is that combining algorithms need to evaluate children
> sufficiently deep to not violate that order.
>    - Another corollary is that the "AND" function used in the
> "refactoring" of the policies also must follow this.
> - Drop any combining algorithms from the spec which currently do not
> meet that priority. Permit-unless-deny, Deny-unless-permit, several 2.0
> algorithms, only-one-applicable comes to mind from the top of my head.
> - Think it through so that there is nothing else we are missing.
> Preferably provide some formal proof of it.
> - Require that any user extension combining algorithm MUST meet the
> same
> criteria (though there probably won't be any room for those, since
> likely only one variant of permit-overrides respective deny-overrides
> will be possible. Or maybe combiner parameters leave some room for
> other
> cases?)
>
> Best regards,
> Erik
>
>
> On 2011-05-05 16:59, rich levinson wrote:
> > Hi Paul,
> >
> > I do not disagree with your reminder to us to focus on getting the
> 3.0
> > specs on track
> > as the primary agenda item. This should be our top priority.
> >
> > Re: the section 7 changes, I am not in favor of rolling them back,
> but
> > would prefer that
> > we specifically identify any remaining issues with the text, and
> > determine what is needed
> > to be done to correct those issues. I had thought the
> > significantly narrowed, but I agree there were some remaining points
> > that were worth
> > nailing down, since we are taking the time to work thru it.
> >
> > So, bottom line is: my opinion is that since we have started this
> > work, and made progress,
> > we should see it thru to completion. It seems to me that there are
> > just a few distinct points
> > that may need further clarification.
> >
> >     Thanks,
> >     Rich
> >
> >
> > On 5/5/2011 10:42 AM, Tyson, Paul H wrote:
> >> I thought the main purpose of weekly meetings was to get the 3.0
> >> specs back to cs status as soon as possible.  If so we should put
> >> "XACML working drafts" first on the agenda.
> >>
> >> I think the only area of discussion is the substantive changes in
> >> section 7 of the core spec.  Erik made these to clarify return
> values
> >> from policies in the event of indeterminate targets.  I believe this
> >> uncovers some underlying issues that cannot be resolved quickly.  I
> >> would prefer to remove the section 7 changes from wd-19 and leave
> the
> >> ambiguity in the spec until we can work through the issues.  As Bill
> >> pointed out, underspecification is not an error.
> >>
> >> Regards,
> >> --Paul
> >>
> >>> -----Original Message-----
> >>> From: rich levinson [mailto:rich.levinson@oracle.com]
> >>> Sent: Thursday, May 05, 2011 00:25
> >>> To: xacml
> >>> Subject: [xacml] Proposed Agenda for 5 May 2011 TC Meeting
> >>>
> >>> Time: 13:00 EDT
> >>> Tel: 513-241-0892 Access Code: 65998
> >>>
> >>> Proposed Agenda for 5 May 2011 TC Meeting:
> >>>
> >>> I. Roll Call&   Approve Minutes:
> >>> Roll call:
> >>>
> >>> Approve Minutes: 28 April 2011 TC Meeting Minutes (updated):
> >>> http://lists.oasis-open.org/archives/xacml/201104/msg00076.html
> >>>
> >>>
> >>>
> >>> Ongoing: "ITU-T Files of Interest":
> >>>    Abbie will provide status as available
> >>>    hal: http://lists.oasis-
> open.org/archives/xacml/201105/msg00000.html
> >>>
> >>> Ongoing: F2F Planning Update
> >>>    status:  F2F will be held in June 28th, 29, 30th in Lexington,
> MA
> >>>     at the Boeing facility
> >>>     John Tolbert to publish logistics information
> >>>    hal: http://lists.oasis-
> open.org/archives/xacml/201105/msg00001.html
> >>>
> >>> Ongoing: OASIS XACML Webinar: OASIS asks is there interest to
> develop?
> >>>    XACML Webinar set for 8 June, 2011 at 11:00ET US
> >>>    Hal, Erik and Doron will be presenting. Development in progress.
> >>>
> >>> Ongoing: "OASIS IDtrust Member Section to host IIW - 3-5 May 2011":
> >>>    dee: http://lists.oasis-
> open.org/archives/xacml/201103/msg00057.html
> >>>    is there any news from this conf?
> >>>
> >>>
> >>> III. Issues
> >>>
> >>> new:<PolicySet>   elements under PPS elements in RBAC profile"
> >>>    jan:
> >>> http://lists.oasis-open.org/archives/xacml/201104/msg00066.html
> >>>    rich:
> >>> http://lists.oasis-open.org/archives/xacml/201104/msg00083.html
> >>>    rich: should this be resolved w action item to update 1st ref in
> >>> doc?
> >>>
> >>> new (carryover): "Profile examples"
> >>>    rich: links to hier examples:
> >>>     anne's 2004 doc: http://lists.oasis-
> >>> open.org/archives/xacml/200406/msg00033.html
> >>>     actual doc: http://lists.oasis-
> >>> open.org/archives/xacml/200406/pdf00003.pdf
> >>>     rich: forest and dag non-xml resource examples:
> >>>      http://lists.oasis-
> open.org/archives/xacml/200902/msg00058.html
> >>>     rich: background on xml resource URI example: (many emails
> followed
> >>> this
> >>>     to point where we came to agreement on current spec):
> >>>      http://lists.oasis-
> open.org/archives/xacml/200910/msg00024.html
> >>>    doron: to start a discussion thread on list and provide examples
> >>> that
> >>> his
> >>>      company is using to represent their hier operations
> >>>
> >>> Update: BTG Profile (Break The Glass):
> >>>    david: http://lists.oasis-
> >>> open.org/archives/xacml/201104/msg00074.html
> >>>    remon: http://lists.oasis-
> >>> open.org/archives/xacml/201104/msg00078.html
> >>>    david: http://lists.oasis-
> >>> open.org/archives/xacml/201104/msg00081.html
> >>>    remon: http://lists.oasis-
> >>> open.org/archives/xacml/201104/msg00082.html
> >>>
> >>> Update: "Attribute predicate profile for SAML and XACML":
> >>>    remon(zbac): http://lists.oasis-
> >>> open.org/archives/xacml/201104/msg00080.html
> >>>    Greg, is in the process of splitting document into a SAML
> Profile
> >>>      and XACML profile. He is a bit unclear as to what is needed in
> >>> XACML
> >>>      profile based upon Paul's comments on the list. Hal offered
> that a
> >>>      Profile may created or an artifact on non-normative document
> >>> track.
> >>>      Greg noted that he is awaiting feedback from the SAML group on
> the
> >>>      proposal made to that group.
> >>>
> >>> update: "XACML working drafts"
> >>> "WD-19 of core and WD-14 of SAML profile" these specs are being
> >>> reviewed.
> >>>     list-fixes: http://lists.oasis-
> >>> open.org/archives/xacml/201104/msg00018.html
> >>> open.org/archives/xacml/201104/msg00017.html
> >>>
> >>>
> >>> Following are carried over: not ref'd in last minutes:
> >>>
> >>> Update: "The Indeterminate flavors question" (aka: Extended
> >>> Indeterminate)
> >>>    remon: http://lists.oasis-
> >>> open.org/archives/xacml/201104/msg00079.html
> >>>    erik:
> >>> http://lists.oasis-open.org/archives/xacml/201104/msg00045.html
> >>>    paul:
> >>> http://lists.oasis-open.org/archives/xacml/201104/msg00046.html
> >>>    rich:
> >>> http://lists.oasis-open.org/archives/xacml/201104/msg00053.html
> >>>
> >>> Carried: PIP directive (additional information directives)
> >>> original (David): http://lists.oasis-
> >>> open.org/archives/xacml/201010/msg00005.html
> >>>    Hal: noted that this topic has been quiet and offered that he is
> >>>      working on an approach to possibly combining some of the ideas
> >>>      that have been considered.
> >>>
> >>> Carried: "usage of status:missing-attribute in case of an
> >>> AttributeSelector
> >>>        - control of the pip through xacml rules"
> >>>    jan: http://lists.oasis-
> open.org/archives/xacml/201103/msg00059.html
> >>>    paul:
> >>> http://lists.oasis-open.org/archives/xacml/201103/msg00060.html
> >>>    erik:
> >>> http://lists.oasis-open.org/archives/xacml/201104/msg00002.html
> >>>    jan:
> >>> http://lists.oasis-open.org/archives/xacml/201104/msg00003.html
> >>>
> >>> Carried: ""Web Friendly" Policy Ids":
> >>>    hal: http://lists.oasis-
> open.org/archives/xacml/201103/msg00044.html
> >>>    paul:
> >>> http://lists.oasis-open.org/archives/xacml/201103/msg00046.html
> >>>
> >>> Carried: Specifying a specific associated Resource in a Policy
> (Sticky
> >>> Policies):
> >>>    hal: http://lists.oasis-
> open.org/archives/xacml/201103/msg00012.html
> >>>
> >>>
> >>>
> >>> -------------------------------------------------------------------
> --
> >>> To unsubscribe from this mail list, you must leave the OASIS TC
> that
> >>> https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that