Re: Additional Combining Algorithms Profile V1.0 and some notes on combining algorithms

[Erik Rissanen <erik@axiomatics.com>]

Hi,

See inline.

On 02/07/2013 06:56 PM, Mohammad Jafari wrote:
> Hi,
>
> I think the last "if" block is not necessary and can be removed (check the last table in the attached PDF).

I know. Pablo here at Axiomatics told me that after we had voted it up,
but since it does not change the normative meaning, I did not want to
pull it back to make changes.

> Which made me think that probably pseudo-code is not the best way to explain the policy/rule combining behavior, because we are somehow mixing the "what" and "how". I suggest the policy/rule combining should be described as a "function" and then, if necessary, a (non-normative) algorithm be proposed for computing it --leaving it up to developer to perhaps find other ways to compute it more efficiently in the specific context. 
>
> Please see the attached PDF in which I discussed this briefly.

Yes, that's an alternative way to define them. But the pseudo code works
too and that's how it has been done in the past, so I figured for sake
of familiarity it's good to do so now too. I would be fine with either,
but I suspect most techies with less formal training are more
comfortable reading pseudo code than logical notation. ;-)

> Also, we must be aware that the combing algorithm of this profile is different from the others we have seen so far, since not only does it care about the order of the children*, it also depends on the number of children. I think this is a bit counter-intuitive and somehow stretching the meaning of "combining algorithm" for implementing something that is not inherently/semantically a combining algorithm's job. Maybe a cleaner approach is to support conditions on Policy/PolicySets to avoid complicated workarounds like this.

Yes that would have been cleaner, but given the time frame of the
standard, and the controversial nature of this topic (some
implementations depend on restricted form of targets for optimizations,
if I have understood it correctly from the email archives), this was a
more pragmatic approach to get this in there for those who find it useful.

>
> [*] Sensitivity to the order of children (as it also exists in the standard "first-applicable" combining algorithm) is generally undesirable. It makes the policy more difficult to understand and maintain, since the rules/policies will no longer be independent of each other and adding a rule/policy requires going through the entire collection to analyze its implicit effects on the others which is an administrative nightmare --remember iptables.

I would think that there are situations where people like to express
"rules and exceptions" in this manner. If someone does not like ordered
algorithms, then can choose to not use them. I think they serve a
practical purpose.

Best regards,
Erik

> Regards,
> Mohammad Jafari
> Security Architect, Edmond Scientific Company
>
>
> -----Original Message-----
> From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Chet Ensign
> Sent: Friday, January 25, 2013 3:01 PM
> To: tc-announce@lists.oasis-open.org; members@lists.oasis-open.org; xacml@lists.oasis-open.org
> Subject: [xacml] 30-day Public Review for XACML 3.0 Additional Combining Algorithms Profile V1.0
>
> OASIS members,  
>
> The OASIS eXtensible Access Control Markup Language (XACML) TC [1] members have recently approved a Committee Specification Draft (CSD) and submitted this specification for 30-day public review:
>
> XACML 3.0 Additional Combining Algorithms Profile Version 1.0 Committee Specification Draft 01 / Public Review Draft 01
> 10 January 2013
>
> Specification Overview:
>
> This profile defines new useful but optional combining algorithms for XACML 3.0. 
>
> TC Description: 
>
> The XACML Technical Committee defines a core XML schema for representing authorization and entitlement policies. 
>
> Public Review Period:
>
> The public review starts 28 January 2013 and ends 27 February 2013.
>
> This is an open invitation to comment. OASIS solicits feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work.
>
> URIs:
>
> The prose specification document and related files are available here:
>
> Editable Source (Authoritative):
> http://docs.oasis-open.org/xacml/xacml-3.0-combalgs/v1.0/csprd01/xacml-3.0-combalgs-v1.0-csprd01.doc 
>
> HTML: 
> http://docs.oasis-open.org/xacml/xacml-3.0-combalgs/v1.0/csprd01/xacml-3.0-combalgs-v1.0-csprd01.html
>
> PDF:
> http://docs.oasis-open.org/xacml/xacml-3.0-combalgs/v1.0/csprd01/xacml-3.0-combalgs-v1.0-csprd01.pdf
>
> ZIP distribution file (complete):
> For your convenience, OASIS provides a complete package of the prose specification and related files in a ZIP distribution file. You can download the ZIP file here:
>
> http://docs.oasis-open.org/xacml/xacml-3.0-combalgs/v1.0/csprd01/xacml-3.0-combalgs-v1.0-csprd01.zip
>
> Additional information about the specification and the eXtensible Access Control Markup Language (XACML) TC may be found at the TC's public home page:
>
> https://www.oasis-open.org/committees/xacml
>
> Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be located via the button labeled "Send A Comment" at the top of the TC public home, or directly at:
>
> https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=xacml
>
> Comments submitted by TC non-members for this work and for other work of this TC are publicly archived and can be viewed at:
>
> https://lists.oasis-open.org/archives/xacml-comment/
>
> All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with this public review of "XACML 3.0 Additional Combining Algorithms Profile Version 1.0", we call your attention to the OASIS IPR Policy [2] applicable especially [3] to the work of this technical committee. All members of the TC should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification. 
>
> OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work.
>
> ========== Additional references:
>
> [1] OASIS eXtensible Access Control Markup Language (XACML) TC https://www.oasis-open.org/committees/xacml
>
> [2] http://www.oasis-open.org/who/intellectualproperty.php
>
> [3] http://www.oasis-open.org/committees/xacml/ipr.php
> https://www.oasis-open.org/policies-guidelines/ipr#s10.2.3
> RF on Limited Terms Mode 
>
> /chet
> ----------------
> Chet Ensign
> Director of Standards Development and TC Administration
> OASIS: Advancing open standards for the information society http://www.oasis-open.org
>
> Primary: +1 973-996-2298
> Mobile: +1 201-341-1393
>
> ---------------------------------------------------------------------
> 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 
>