xacml — archive

[Polar Humenn <polar@syr.edu>]

 MHonArc v2.5.2 -->

















xacml message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]








Subject: RE: [xacml] [CR] AttributeSelectorIndirect




From: Polar Humenn <polar@syr.edu>
To: Daniel Engovatov <dengovatov@crosslogix.com>
Date: Fri, 06 Sep 2002 14:54:20 -0400 (EDT)






On Fri, 6 Sep 2002, Daniel Engovatov wrote:

>
> >However, if you really want to put a "value" as the second argument, of
> >which I cannot see a good argument against, it would require a SCHEMA
> >CHANGE.
>
> That what was my reason for allowing <attributevalue> to specify a sequence.
>
> >Given that we agree with that, If you believe the /a/b/c/text() will
> >return a sequence of one you would use:
> >
> > <ResourceMatch MatchId="function:string-equal">
> >   <AttributeSelector RequestContextPath="/a/b/@b1/">
> >   <Apply FunctionId="string-first-and-only">
> >      <AttributeSelector
> >                RequestContextPath="/a/b/c/text()"/>
> >   </Apply>
> > </ResourceMatch>
>
> Illegal.  First argument is of type sequence<string> -
> need to

That is true, the first argument is of type sequence<xs:string>, because
that is what the schema says. The first element of the ResourceMatch
structure must be a AttributeSelector or a AttributeDesignator.

> 1)wrap both arguments in first-and-only

Nope. You need a value of type "a", you need a sequence of type "b",
denoted as [b], and a function that compares things of type "a" to type
"b" and returns a boolean.

In Haskell, the formal type signature of the resourceMatch function is:

resourceMatch :: ( a -> b -> Boolean ) -> [b] -> a -> Boolean

It's formal definition in Haskell would be:

resourceMatch f []     a = False
resourceMatch f (b:bs) a = (f a b) || (resourceMatch bs a)


  NB:: (b:bs) means a sequence where b is the head element and bs is the
       rest. function application is by juxtaposition. || is an infix
       logical OR operator. [] is the empty sequence.

For our cases, the functions we would use would be functions of type
( a -> a -> Boolean), i.e. functions that compare two elements of the
same type, such as "string-equal", or "integer-equal".

> 2)use string-member-of - with <attribute value> for first argument, if you
> do not care whether the selector
> returns multiple values

Unfortunately, the first argument, by the schema, says that it must be the
Selector or Designator. The explicit value to match against is the second
element in the schema. To reverse them, which I wouldn't mind, we would
need a SCHEMA change, and I would have to change the definition of the
match functions.

> 3) use set-equal, with second argument specified using string-sequence
> function, or another selector,

Then, technically you want two ResourceMatch expressions. The one above
and the following, of which the type signature is:

resourceMatch2:: ([a] -> [b] -> Boolean) -> [a] -> [b] -> Boolean

and its definition:

resourceMatch2 f as bs = f (as bs)

But you see that this kind of "Match" is nothing but a function
application, so why not just use Apply?

> 4) use that new string-at-least-one-member-of (or, God, can it be made
> shorter? ;) , again, if you do not
> care about

This is pretty much the operation of ResourceMatch, and the other Match
functions.

-Polar

> All this options, unless we go back to my original proposal to make
> functions determine appropriate sequence
> length at runtime (yeah, I know, it is not good), require relaxing
> requirements for the <*Match> functions,
> to be the same as condition - arbitrary types of arguments to the top
> predicate.  Which is not bad at all, on
> the other hand - unless you go really crazy, and start putting extension
> function with side effects into
> matches.
>
> daniel;
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>









References:

RE: [xacml] [CR] AttributeSelectorIndirect
From: Daniel Engovatov <dengovatov@crosslogix.com>






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]


  









Powered by eList eXpress LLC