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
> ambiguities/issues had been
> 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:]
>>> 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
>>>
>>>
>>> II. Administrivia
>>>
>>> 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):
>>> latest: (david summary + follow on comments)
>>> 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 of issues addressed is in 1st link, docs are in 2nd link:
>>> list-fixes: http://lists.oasis-
>>> open.org/archives/xacml/201104/msg00018.html
>>> doc-links: http://lists.oasis-
>>> 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
>>> comments:
>>> 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
>>> comments:
>>> 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
>>> 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
>
> ---------------------------------------------------------------------
> 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
