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: Re: [xacml] Question on xacml 2.0 - multiple action-id Request/Action elements

All, Rich,

I agree with Bill. It's a bad idea to model XACML policies in that 
manner, but if you like that approach, then that is good for you. You 
know what the XACML functions and elements do, so if you can make 
"compound actions" work, then that's fine. XACML has been designed with 
the assumption that the actions are not compound actions, but I don't 
think the standard should be interpreted to make normative 
"philosophical statements". The spec says how the bits and bytes are 
processed into a result. That's it. How you use it, is up to you.

Rich, you were asking that "the TC presents its recommendations and 
guidelines". My personal recommendation and guideline is: don't do it 
like that since it will lead to complex policies. Use the multiple 
resource profile instead. I don't know about the rest of the TC.

Best regards,

Bill Parducci wrote:
> I can try to give my perspective from a slightly different angle...
> IMO the need for a slash, dash or comma to enumerate attributes within 
> a framework that has been explicitly constructed to provide to clarity 
> and interoperability is philosophically wrong.  I don't not think 
> there should be a need for such things because compound attributes as 
> suggested here should not exist.  We cannot prevent it from happening 
> but we can discourage it and I think we should.
> Beyond the points Erik and Craig raised I believe this because I don't 
> think this is just a system related issue. Lacking any form of 
> referenceable standard for this notation means it will become highly 
> localized and therefore more likely to mutate/be misunderstood over 
> time by policy editors interacting with the system. We can of course 
> create our own attribute combiner notation to define what ", + /" 
> means, but I suggest we not :)
> The attribute "readwrite" works so long as it refers to a distinct 
> action, not as implied notation equivalent to: "parse out the english 
> words that are analogous to filesystem actions and then treat them as 
> distinct entities once parsed." 
> Not sure if this makes it any clearer.  :-D
> b
> On Sep 18, 2008, at 12:38 PM, Rich.Levinson wrote:
>> Hi Bill, et al,
>> I am not sure I am following the argument. If I removed the comma or 
>> replaced it with a slash or dash would that address the concern?
>> Basically, I am saying in the simplest case, let's take simply file 
>> read and write that there are 3 possible "services" that can be 
>> offered (possibly a different rate  is charged for each):
>>     * readwrite
>>     * read
>>     * write
>> As described in previous email, each time a new file is selected, the 
>> user picks the desired service level and hits submit. The policy 
>> determines if the user has been granted access to that file at that 
>> level of service.
>> If so, then the user is presented with the appropriate form for using 
>> the service, which only has 2 operations: read and/or write. Each 
>> time the user requests one of the operations the policy determines if 
>> they have that access (and they are charged a usage fee).
>> There are no compound operations. It is simply specify the service 
>> you want, then if you get it, use the service.
>> The fact is that a file is a more complicated resource than just the 
>> number, n, of possible discrete "runtime" operations you can perform 
>> it. When a real file system is used each file has potentially n**2 - 
>> 1 "modes" in which it can be initialized prior to providing "runtime" 
>> access. The problem I have seen using XACML is that attempts have 
>> been made to provide access to these actual n**2-1+n discrete 
>> operations (or actions) using only n actions.
>> I believe my proposal is simply addressing the reality of the problem 
>> by enabling the ability to express the options that are physically 
>> available, and doing this in a manner where a user specifies the 
>> exact action they are going to use at the time they are about to use 
>> it and nothing more.
>> Comments?
>>     Thanks,
>>     Rich
>> Bill Parducci wrote:
>>> Rich,
>>> I think that it does introduce complexity in that once compound 
>>> actions are introduced the relationship between them is ambiguous 
>>> unless further machinery/description is also introduced to handle 
>>> it.  The comma used in  "read,write" lacks referenceable meaning in 
>>> the current specification and therefore lends itself to open 
>>> interpretation. In general we have always tried to avoid this type 
>>> of situation because it tends to lessen the chances for 
>>> interoperability.
>>> Therefore I would offer that is not just a complexity/performance 
>>> issue. One could argue that the TC doesn't dictate attribute values, 
>>> however it seems to me that there is merit in discouraging the 
>>> creation of non-normative syntax for creating compound attribute 
>>> values, particularly since there seems to be a viable alternative at 
>>> hand that provides the desired functionality.
>>> b
>>> On Sep 18, 2008, at 10:31 AM, Rich.Levinson wrote:
>>>> Hi Erik,
>>>> I agree there are multiple ways to address the problem. Personally, 
>>>> I do not believe the approach I have suggested necessarily results 
>>>> in any significantly increased complexity.
>>>> However, I do not think that can be the basis for how the TC 
>>>> presents its recommendations and guidelines. For example, the fact 
>>>> that the whole policy structure and requests and responses are 
>>>> written in the spec in xml does not constrain the implementor to 
>>>> use xml at all, as I understand it.
>>>> It is very possible that different implementation technologies lend 
>>>> themselves to more or less efficient policy processing depending on 
>>>> how one writes the policies. Just because an XML representation of 
>>>> a Policy is complex doesn't mean that the underlying implementation 
>>>> of that Policy necessarily has to be complex.
>>>>   Thanks,
>>>>   Rich
>>> ---------------------------------------------------------------------
>>> 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

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