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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

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

Subject: XACML expressiveness (WAS: RE: [xacml-users] retrieving a list or query filter of resources the caller is authorized for)


> -----Original Message-----
> From: Oleg Gryb [mailto:oleg_gryb@yahoo.com] 
> Sent: Monday, April 19, 2010 14:22
> To: Yoichi Takayama; Oleg Gryb
> Cc: Tyson, Paul H; Ralf Lorenz; xacml-users@lists.oasis-open.org
> Subject: Re: [xacml-users] retrieving a list or query filter 
> of resources the caller is authorized for
> Yoichi, Paul,
> There are few points that I want to comment on:
> 1.
> >"Extracting" in what way and what do you want to extract 
> exactly, and 
> where from? 
> F(Bag-of-string, Expr) = String
> Expr is a XACML expression (actually it was a variable ref in 
> my case) evaluated to an integer that represents a string 
> index in a bag
> Bag-of-string - is a bag of strings
> String - returned value, which is the string with the index 
> provided by Expr

That's right: the XACML policy language has no ordered lists, therefore
no way of selecting from a list by index.  I don't know if this is
because the TC decided against it, or just that no one ever brought the
use case forward.  The XACML request context consists of bags of
attribute values identified by id, type, and issuer.  There is no
concept of order in the request context.  However, in a policy you could
use a *-bag function to construct a bag of values that you might want to
treat as ordered.

> I'm not sure what other details I can provide, except that I 
> didn't make up the example, I needed it to return a message 
> from a policy.
> I'll try to generalize that "rigidness" problem. XACML 
> defines expressions and variables just like any programming 
> language, but it stops short from making expressions commonly 
> available everywhere and suggests using static (or literal) 
> content instead.
>  AttributeValueType can't have expressions (e.g. variable 
> references) inside. It means that constructs like 
> AttributeAssignment that is used to define Obligations can't 
> not contain expressions that will be interpreted by a PDP 
> engine. 

This limitation was removed in 3.0, which allows expressions in
Obligation and Advice.


> 2. It's good that AssociatedAdvice was introduced in XACML 
> 3.0, but  can I put an expression to AssociatedAdvice that 
> will be interpreted by a PDP before a response is sent back 
> to a client? The second qs: why it was named as an "advice"? 
> Can't we have it more generic by calling it DecisionDetails 
> and allowing any details that might be related to a decision? 
> Advice is just one particular case, right? 

The TC decided that "Advice" was general enough.  There are no
particular semantics or requirements attached to it, so it can be used
for anything the users or implementors want to do.



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