[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] Proposal of Model for comparing two sequences
Polar
First, my proposal is meant for applying only to the comparison operator
(meaning that it returns a boolean value), not to arithmetic computation
functions such as integer-subtract. I think we had better distinguish these
two types if we support sequence in our function model. Personally,
arithmetic functions are supposed to implicitly have "OnlyFirst"
ComparisonBase. So your example should be:
<Apply FunctionId="function:integer-subtract" ComparisonBase="OnlyFirst">
<AttributeValue>10</AttributeValue>
<AttributeValue>20</AttributeValue>
</Apply>
However, what if the first argument is AttributeDesignator (or
AttributeSelector)? it may return a sequence with two or more integer
values. In that case, I think it would be more explicit to specify:
<Apply FunctionId="function:integer-subtract" ComparisonBase="OnlyFirst">
<AttributeSelector RequestContextPath="/a/b/c"/>
<AttributeValue>20</AttributeValue>
</Apply>
If you think that comparison base for arithmetic functions are redundant,
it can be omitted. Then only we have to do is to add a text that the
comparison semantics for integer-subtarct function is "OnlyFirst". Does it
make sense?
Michiharu Kudo
IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
Polar Humenn
<polar@syr.edu> To: Michiharu Kudoh/Japan/IBM@IBMJP
cc: "'XACML '" <xacml@lists.oasis-open.org>
2002/09/12 01:24 Subject: Re: [xacml] Proposal of Model for comparing two sequences
Michiharu,
Convoluting the SIMPLE apply function is a bad idea. Not only that, you'd
have to do so for the Condition construct as well.
For example, what would the following be:
<Apply FunctionId="function:integer-subtract" ComparisonBase="ANY">
<AttributeValue>10</AttributeValue>
<AttributeValue>20</AttributeValue>
</Apply>
-Polar
On Thu, 12 Sep 2002, Michiharu Kudoh wrote:
>
> This includes a proposal document (pdf and word format) of model for
> comparing two sequences.
>
> As far as I understand, the model for comparing two sequences in function
> draft 0.8 seems not sufficient for comparison (matching) framework. I am
> assuming that our data model supports a sequence as a base type. For
> example, type-member-of function supports only equality comparison but
not
> other kinds of comparison such as string-greater-than etc. My opinion is
> that we need to specify two things: how to compare two sequences and how
to
> compare each element. In the following example,
>
> >(resourceMatch string-equal ["Michiharu","Polar","Daniel"] "Daniel")
> >evualates to True.
>
> The above means that whether ANY element of the first sequence matches
the
> value of the second argument. This corresponds to "how to compare
> sequences". The string-equal corresponds to "how to compare each
element".
> According to the current function draft, it is specified:
>
> In <Target>:
> <Resource MatchId="function:string-equal">
> <AttributeSelector RequestContextPath="/a/b/c/text()">
> <AttributeValue>Daniel</AttributeValue>
> </Resource>
>
> In <Condition>:
> <Apply FunctionId="function:string-member-of">
> <AttributeValue>Daniel</AttributeValue>
> <AttributeSelector RequestContextPath="/a/b/c/text()">
> </Apply>
>
> In this case, /a/b/c/text() returns ["Michiharu", "Polar", "Daniel"].
> I would like to specify this without using string-member-of:
>
> <Apply FunctionId="function:string-equal" ComparisonBase="ANY">
> <AttributeSelector RequestContextPath="/a/b/c/text()">
> <AttributeValue>Daniel</AttributeValue>
> </Apply>
>
> "ANY" means that means that it compares each element of the first
sequence
> with the second argument. If none of the comparisons becomes true, then
the
> result of this comparison becomes false. Other wise, the result becomes
> true. This is more generic because you can specify other functions (e.g.
> integer-equal and integer-greater-than) in FunctionId attribute like:
>
> (resourceMatch integer-equal [100,200,300],100)
> <Apply FunctionId="function:integer-equal" ComparisonBase="Each">
> <AttributeSelector RequestContextPath="/a/b/c/text()">
> <AttributeValue>100</AttributeValue>
> </Apply>
>
> (resourceMatch integer-greater-than [100,200,300],50)
> <Apply FunctionId="function:integer-greater-than" ComparisonBase="Each">
> <AttributeSelector RequestContextPath="/a/b/c/text()">
> <AttributeValue>50</AttributeValue>
> </Apply>
>
> The above examples cannot be handled by the functions defined in the
> current draft.
> The following is my proposal of "model of sequence comparison" that
> summarizes comparison patterns like "ANY" (I use a slightly different
> definition from the above). There is no need to define functions like
> "string-equal-memeber-of" and "string-match-member-of" but we can get the
> same functionality.
> (See attached file: XACMLSequenceComparison.doc)(See attached file:
> XACMLSequenceComparison.pdf)
>
> Michiharu Kudo
>
> IBM Tokyo Research Laboratory, Internet Technology
> Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
>
>
>
>
>
> Polar Humenn
> <polar@syr.edu> To: Michiharu
Kudoh/Japan/IBM@IBMJP
> cc: "'XACML '"
<xacml@lists.oasis-open.org>
> 2002/09/11 00:52 Subject: Re: [xacml] Data
model in function
>
>
>
>
>
>
>
> The answer to your question would be B. (only if you use the
ResourceMatch
> with "string-equal", as opposed to "string-match").
>
> There is nothing inconsistent with the data model.
>
> The semantics of ResourceMatch allows matching using different functions,
> i.e. string-equal, string-match.
>
> The definition, of which I already I already posted in,
> http://lists.oasis-open.org/archives/xacml/200209/msg00040.html
> for ResourceMatch is:
>
> resourceMatch f [] a = False
> resourceMatch f (b:bs) a = (f a b) || (resourceMatch bs a)
>
>
> NB:: (b:bs) matches 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.
>
> The symbol "f" represents the function applied, such as "string-match",
or
> string-equal. The expression:
>
> (resourceMatch string-equal ["Miciharu","Polar","Daniel"] "Daniel")
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> result of resource designator
>
> evualates to True.
>
> (resourceMatch string-match ["Michiharu","Polar","Daniel"] "Z.*")
>
> evaluates to False.
>
> Unforunately, we are limited in the way in which we can perform this
> operation in the "Apply" construct using our standard functions, because
> some people were adverse to using a higher order expressions, such as the
> in the semantic definition above.
>
> For the Apply construct, using the "string-member-of" is defined as
> strictly using apply the "string-equal" function to each member of the
> sequence. So, getting some other function applied such as "string-match"
> is problematic.
>
> If you want the same capability in the apply construct we can just expand
> the number of functions, such as "string-equal-memeber-of" and
> "string-match-member-of" to get the differing functionality. But I
haven't
> heard a call for that functionality, yet. :)
>
> Cheers,
> -Polar
>
> On Tue, 10 Sep 2002, Michiharu Kudoh wrote:
>
> >
> > Hi, Polar and Daniel
> >
> > What I am concerned is a potential difference in data model between
> *Match
> > function and *Apply function. Assume that the following policy fragment
> is
> > correct. (Polar said so since *Match function implicitly supports
> > comparison between each value of the sequence and a constant value
using
> > existential comparison).
> >
> > <ResourceMatch MatchId="function:string-equal">
> > <AttributeSelector RequestContextPath="/a/b/c/text()">
> > <AttributeValue>bb1</AttributeValue>
> > </ResourceMatch>
> >
> > How should the above policy be mapped to an expression specified in the
> > condition? A), B), or other?
> >
> > A)
> > <Apply FunctionId="function:string-equal">
> > <AttributeSelector RequestContextPath="/a/b/c/text()">
> > <AttributeValue>bb1</AttributeValue>
> > </Apply>
> >
> > B)
> > <Apply FunctionId="function:string-member-of">
> > <AttributeValue>bb1</AttributeValue>
> > <AttributeSelector RequestContextPath="/a/b/c/text()">
> > </Apply>
> >
> > My opinion is that if we use the same data model in both *Match
function
> > and *Apply function, we should use the same policy specification (case
> A).
> > If we use different data model, then the mapping should be explicitly
> > described.
> >
> > Michiharu Kudo
> >
> > IBM Tokyo Research Laboratory, Internet Technology
> > Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
> >
> >
> >
> >
> >
> > Polar Humenn
> > <polar@syr.edu> To: Daniel
Engovatov
> <dengovatov@crosslogix.com>
> > cc: Michiharu
> Kudoh/Japan/IBM@IBMJP, "'XACML '" <xacml@lists.oasis-open.org>
> > 2002/09/09 22:35 Subject: RE: [xacml]
[CR]
> AttributeSelectorIndirect
> >
> >
> >
> >
> >
> >
> > On Fri, 6 Sep 2002, Daniel Engovatov wrote:
> >
> > > My guess that in your example what you really want to use
> > > are functions string-member-of and integer-member-of.
> >
> > No. The *Match function semantics have that capability. You specify
with
> > the MatchID the function that does the individual comparisons. This
> > approach lets you specify predicates that aren't just based on
equality,
> > such as some regular expression matching function.
> >
> > -Polar
> >
> >
> > > In this case if the selector returns more then one value, at
> > > least one should match. It fits the current type model.
> > >
> > > For integer-member-of - value returned by the selector will
> > > be converted to integer value and numerical comarison will be used.
> > > Result will be INDETERMINATE if the conversion could not be
> > > performed.
> > >
> > > daniel;
> > >
> > > ---------------------
> > > <ResourceMatch MatchId="function:string-equal">
> > > <AttributeSelector RequestContextPath="/a/b/c/text()">
> > > <AttributeValue>bb1</AttributeValue>
> > > </ResourceMatch>
> > >
> > > The first attribute selector may return a sequence of primitive types
> > > (e.g.
> > > bb1 and bb2). Then what is the semantics of the
function:string-equal?
> > > Does
> > > that compare each of the return value of the attribute selector with
> > > "bb1"?
> > >
> > > What if function:integer-equal is used?
> > >
> > > <ResourceMatch MatchId="function:integer-equal">
> > > <AttributeSelector RequestContextPath="/a/b/@b1">
> > > <AttributeValue>100</AttributeValue>
> > > </ResourceMatch>
> > >
> > > Comparison is done based on numeric comparison?
> > >
> > > Michiharu Kudo
> > >
> > > IBM Tokyo Research Laboratory, Internet Technology
> > > Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
> > >
> > >
> > >
> > >
> > >
> > >
> > > Polar Humenn
> > >
> > > <polar@syr.edu> To: Michiharu
> > > Kudoh/Japan/IBM@IBMJP
> > >
> > > cc: XACML
> > > <xacml@lists.oasis-open.org>
> > >
> > > 2002/09/06 22:14 Subject: Re: [xacml]
> > > [CR] AttributeSelectorIndirect
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi Michiharu,
> > >
> > > Comments are inline.
> > >
> > > On Fri, 6 Sep 2002, Michiharu Kudoh wrote:
> > >
> > > >
> > > > Polar
> > > >
> > > > I have a couple questions.
> > > >
> > > > 1. How to mandate a returned data from the attribute selector to be
a
> > > > sequence of a specific type? Are you suggesting to specify DataType
> > > > attribute in the attribute selector element?
> > >
> > > You always must apply a function to any result of an attribute
> selector.
> > > That function specifies the types of its formal parameters, and
> > > therefore
> > > implies the type of the attribute selector. You said so yourself for
> > > AttributeValues.
> > >
> > > > 2. I am not clear on how to specify resource match using
> > > > function:string-equal. Is the following policy fragment correct if
> the
> > > > attribute selector returns a sequence of a primitive type (string
> type
> > > > because function:string-equal implies that)?
> > > >
> > > > <ResourceMatch MatchId="function:string-equal">
> > > > <AttributeSelector RequestContextPath="/a/b/@b1/">
> > > > <AttributeSelector RequestContextPath="/a/b/c/text()"/>
> > > > </ResourceMatch>
> > >
> > > This example is wrong. The second element of a ResourceMatch must be
a
> > > primitive value, currently an explicit AttributeValue.
> > >
> > > <ResourceMatch MatchId="function:string-equal">
> > > <AttributeSelector RequestContextPath="/a/b/@b1/">
> > > <AttributeValue>bb1</AttributeValue>
> > > </ResourceMatch>
> > >
> > > 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.
> > >
> > > 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>
> > >
> > > If for some reason, your resource data model is screwed up, and your
> > > "/a/b/c/text()" attribute selector returns a sequence of more than
one
> > > or
> > > empty, you will get an Indeterminate (i.e. an error).
> > >
> > > > 3. I want to see specification examples how to use each function in
> > > Match
> > > > element and Condition element.
> > >
> > > Above is one example.
> > >
> > > > Sample XACML Contexts and policy specifications would be helpful to
> > > > understand how to use functions. Otherwise, I cannot have a clear
> > > > mapping between XPath 1.0 (and 2.0) functions and XACML functions.
> > >
> > > Is the above enough to get the point across?
> > >
> > > -Polar
> > >
> > > > Michiharu Kudo
> > > >
> > > > IBM Tokyo Research Laboratory, Internet Technology
> > > > Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Polar Humenn
> > > > <polar@syr.edu> To: Michiharu
> > > Kudoh/Japan/IBM@IBMJP
> > > > cc: XACML
> > > <xacml@lists.oasis-open.org>
> > > > 2002/09/05 23:01 Subject: Re:
[xacml]
> > > [CR]
> > > AttributeSelectorIndirect
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Michiharu,
> > > >
> > > > Comments inline.
> > > >
> > > > On Wed, 4 Sep 2002, Michiharu Kudoh wrote:
> > > >
> > > > >
> > > > > Hi, Polar
> > > > >
> > > > > I think that the policy syntax I posted before can be consistent
> > > with
> > > the
> > > > > functions and data types specified in the latest draft of XACML
> > > standard
> > > > > function. (when I first proposed, there was no notion of sequence
> > > data
> > > > > type) Since XACML supports a sequence and a set data types,
> > > functions
> > > > that
> > > > > processes XPath expressions can be mapped to those data types.
> > > > >
> > > > > Basically XPath 1.0 defines a return type as an object data type
> > > > > (either node-set, boolean, number, or string). To define a
mapping
> > > > > rule from XPath object data type to XACML sequence data type
would
> > > be
> > > > > a choice, I think. The problem would be that "node-set" of XPath
is
> > > > > different from "sequences of primitive types". It is not a
sequence
> > > of
> > > > > primitive-type data but just a set of (DOM) nodes which may
include
> > > a
> > > > > structured node. But if we ignore that structured node case, it
> > > would
> > > > > be easy to map node-set to "sequence of primitive type". Then the
> > > > > definition of <AttributeSelector> processes XPath expressions and
> do
> > > a
> > > > > data conversion. Examples are the following:
> > > > >
> > > > > Suppose there is a XML document:
> > > > > <a a1="aaa">
> > > > > <b b1="bb1">
> > > > > <c>bb1</c>
> > > > > </b>
> > > > > <b b1="bb2"/>
> > > > > </a>
> > > > >
> > > > > Case A:
> > > > > XPath expression of "/a/@a1" returns an attribute node:
> > > > > attribute node "a1" that contains a text node "aaa"
> > > >
> > > > I believe we mandate this to be a sequence of a specific type
implied
> > > by
> > > > the function applied to it. Such as if we used
> > > "function:string-member-of"
> > > > on this result of this XPATH expression its type is implied to be a
> > > > sequence of xs:string, for XACML purposes.
> > > >
> > > > > Case B:
> > > > > XPath expression of "/a/b/@b1" returns two attribute nodes "b1":
> > > > > attribute node "b1" that contains "bb1"
> > > > > attribute node "b1" that contains "bb2"
> > > >
> > > > Again, I believe we mandate this to be a sequence of a specific
type
> > > > implied by the function applied to it. If we used
> > > > "function:string-memeber-of" it would be considered a sequence of
> > > > xs:string containing "bb1" and "bb2".
> > > >
> > > >
> > > > > Case C:
> > > > > XPath expression of "/a/b/c/text()" returns a text node:
> > > > > text node that contains "xyz"
> > > >
> > > > again, same thing.
> > > >
> > > > > Above three cases indicates a natural mapping from node set to a
> > > sequence
> > > > > of primitive data types. (For simplicity, I ignore primitive data
> > > type
> > > > > here)
> > > >
> > > > I agree.
> > > >
> > > > > Case D:
> > > > > XPath expression of "/a/b" returns two notes:
> > > > > element node "b" that contains element "c" and attribute "b1"
> > > > > element node "b" that contains attribute "b1"
> > > > >
> > > > > In Case D, there is no natural mapping from returned node set
> > > because
> > > > > returned object is a structured node. (In XPath 1.0, there is a
> > > > conversion
> > > > > definition of structured node (as a string value), I don't think
it
> > > fits
> > > > to
> > > > > XACML case.)
> > > > >
> > > > > One possibility would be to raise an error for Case D, or returns
> an
> > > > empty
> > > > > sequence without error.
> > > >
> > > > I think returning and empty sequence is a REALLY bad idea. If we
> > > allowed
> > > > this kind of thing, there is no need for a type system or any
> > > integrity
> > > to
> > > > the evaluation of policy against its inputs.
> > > >
> > > > If you have a node-set that is some type other than the standard
> types
> > > > that we support, you should use create a type extension and
functions
> > > that
> > > > explicity know how to deal with that extension, otherwise it is an
> > > error
> > > > (which can quite possibly be handled at compile time).
> > > >
> > > > > (Anyway, policy writer must be sure that the XPath
> > > > > expression really returns sequence of primitive types.)
> > > > > Based on the above observation, the following example returns
true:
> > > > >
> > > > > <ResourceMatch MatchId="function:has-string-intersection">
> > > > > <AttributeSelector RequestContextPath="/a/b/@b1/">
> > > > > <AttributeSelector RequestContextPath="/a/b/c/text()"/>
> > > > > </ResourceMatch>
> > > >
> > > > I thinkthe function you would use here would be
> > > "function:string-equal"
> > > > because the ResourceMatch has the semantics of applying the
function
> > > named
> > > > by MatchId to the elements in the sequences to see if there is a
> > > match.
> > > >
> > > > -Polar
> > > >
> > > > > For example, function:has-intersection returns true because the
> > > first
> > > > > argument and the second argument has an intersection ("bb1") as a
> > > string
> > > > > value.
> > > > >
> > > > > Michiharu
> > > > >
> > > > > IBM Tokyo Research Laboratory, Internet Technology
> > > > > Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Polar Humenn
> > > > > <polar@syr.edu> To:
Michiharu
> > > > Kudoh/Japan/IBM@IBMJP
> > > > > cc: XACML
> > > > <xacml@lists.oasis-open.org>
> > > > > 2002/08/30 21:47 Subject: Re:
> [xacml]
> > > [CR]
> > > > AttributeSelectorIndirect
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Michiharu,
> > > > >
> > > > > Comments inline.
> > > > >
> > > > > On Fri, 30 Aug 2002, Michiharu Kudoh wrote:
> > > > >
> > > > > >
> > > > > > Line 804-810 of draft 0.16e, there is a resource match in
Example
> > > 2
> > > > Rule
> > > > > 1:
> > > > > >
> > > > > > <ResourceMatch MatchId="function:node-match">
> > > > > > <ResourceAttributeDesignator AttributeId="urn:...:xpath"
> > > > > > DataType="xsi:string"/>
> > > > > > <AttributeValue
> > > DataType="xsi:string">/md:record</AttributeValue>
> > > > > > </ResourceMatch>
> > > > > >
> > > > > > In the above example, the node-match function is defined as
> > > > > >
> > > > > > Function: node-match
> > > > > > input: xs:string, xs:string
> > > > > > output: xs:boolean
> > > > > > description: receive two xpath expressions and executes xpath
> > > processor
> > > > > on
> > > > > > both xpaths. It generates two objects (object type is defined
in
> > > XPath
> > > > > 1.0,
> > > > > > i.e. node-set, string, numeric, or boolean). When two objects
> have
> > > an
> > > > > > intersection, then it returns true, otherwise return false.
> > > > >
> > > > > This function, although a little unwieldy, is fine, provided you
> can
> > > > > provide a deterministic definition for a node-match. ("when two
> > > object
> > > > > have an intersection") is somewhat lacking.
> > > > >
> > > > > > Instead of the above node-match function and the resource match
> > > > > > specification, I would prefer the definition and resource match
> > > > > > specification using <AttributeSelectorIndirect> below:
> > > > > >
> > > > > > Function: node-match
> > > > > > input: object, object
> > > > > > output: xs:boolean
> > > > > > description: receive two objects. When two node-sets have an
> > > > > intersection,
> > > > > > then it returns true, otherwise return false.
> > > > > >
> > > > > > <ResourceMatch MatchId="function:node-match">
> > > > > > <AttributeSelectorIndirect>
> > > > > > <ResourceAttributeDesignator AttributeId="urn:...:xpath"/>
> > > > > > </AttributeSelectorIndirect>
> > > > > > <AttributeSelector RequestContextPath="/md:record"/>
> > > > > > </ResourceMatch>
> > > > >
> > > > > Why?
> > > > >
> > > > > Your previous approach is fine, and works within our type system.
> It
> > > > takes
> > > > > two arguments of primitive types ("xs:string") and returns an
> > > xs:boolean.
> > > > >
> > > > > This approach requires "node-match" to be polymorphic and for
XACML
> > > > > processors to understand abstract data types. Our simple type
> system
> > > > > cannot support it. We would now have much more than primitive
> types,
> > > and
> > > > > sequences of primitive types. We would have abstract data types
> > > (i.e.
> > > > > arbitrary XML nodes) introduced into the type system.
> > > > >
> > > > > Also, in this case, you must note that the selectors must contain
> > > the
> > > > > "DataType" attribute to make type sense out of their results, as
> > > these
> > > > > selectors can end up in other function applications. I think we
> are
> > > > > trying to get rid of the DataType attribute, because of the type
> > > > > inference.
> > > > >
> > > > > Also, I think you left the "DataType" attribute out in this
> example,
> > > for
> > > > > obvious reasons. You don't know what legal value to give it.
> > > > >
> > > > > In both cases, however, you still need to come up with an
explicit
> > > > > specification of for the function "node-match".
> > > > >
> > > > > If you can come up with a specification of node-match, I would
> > > strongly
> > > > > prefer that it was a function that fit with our type system, i.e.
> > > your
> > > > > first example, which takes two XPATH expressions and returns a
> > > boolean.
> > > > >
> > > > >
> > > > > > Other example (not AttributeSelectorIndirect but
> AttributeSelector
> > > > case)
> > > > > is
> > > > > > line 825-835. The function:string-equal should be the
> > > > > > function:general-string-equal because <AttributeSelector>
returns
> > > an
> > > > > object
> > > > > > data type (maybe node-set) and it is not proper to hand it to
> > > > > string-equal
> > > > > > function.
> > > > >
> > > > > I don't even have a specification for "string-equal", let alone
> > > > > "general-string-equal", so I don't really understand the
> difference.
> > > > >
> > > > > Cheers,
> > > > > -Polar
> > > > >
> > > > > > <Condition FunctionId="function:string-equal">
> > > > > > <SubjectAttributeDesignatorWhere
> > > > > > AttributeId="urn:...:policy-number" DataType
="xsi:string"/>
> > > > > > <AttributeSelector RequestContextPath="/ctx:Request/ ...
> > > > > > /md:policyNumber"
> > > > > > DataType="xsi:string"/>
> > > > > > </Condition>
> > > > > >
> > > > > > [should be]
> > > > > >
> > > > > > <Condition FunctionId="function:general-string-equal">
> > > > > > <SubjectAttributeDesignatorWhere
> > > > > > AttributeId="urn:...:policy-number" DataType
="xsi:string"/>
> > > > > > <AttributeSelector RequestContextPath="/ctx:Request/ ...
> > > > > > /md:policyNumber"
> > > > > > DataType="xsi:string"/>
> > > > > > </Condition>
> > > > > >
> > > > > > Michiharu Kudo
> > > > > >
> > > > > > IBM Tokyo Research Laboratory, Internet Technology
> > > > > > Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Polar Humenn
> > > > > > <polar@syr.edu> To:
> Michiharu
> > > > > Kudoh/Japan/IBM@IBMJP
> > > > > > cc:
> > > > > <xacml@lists.oasis-open.org>
> > > > > > 2002/08/30 03:27 Subject: Re:
> > > [xacml]
> > > > [CR]
> > > > > AttributeSelectorIndirect
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Michiharu,
> > > > > >
> > > > > > Is there a use case or example for this type of attribute
> > > selector?
> > > > > >
> > > > > > Cheers,
> > > > > > -Polar
> > > > > >
> > > > > > On Thu, 29 Aug 2002, Michiharu Kudoh wrote:
> > > > > >
> > > > > > > Based on the discussion on Monday call, Simon and I agreed to
> > > > changing
> > > > > > the
> > > > > > > schema to support an AttributeSelectorIndirect element to
> > > retrieve
> > > a
> > > > > > XPath
> > > > > > > expression from the context. I wonder whether the name of
this
> > > > element
> > > > > is
> > > > > > > appropriate or not.
> > > > > > >
> > > > > > > <xs:complexType name="AttributeSelectorBaseType">
> > > > > > > <xs:element ref="xacml:XPathNamespace" minOccurs="0"
> maxOccurs
> > > > > > > ="unbounded"/>
> > > > > > > <xs:attribute name="DataType" type="xs:anyURI"
> > > use="optional"/>
> > > > > > > <xs:attribute name="XPathVersion" type="xs:anyURI"
> > > use="optional"
> > > > > > default
> > > > > > > ="http://www.w3.org/TR/1999/Rec-xpath-19991116"/>
> > > > > > > </xs:complexType>
> > > > > > >
> > > > > > > <xs:complexType name="AttributeSelectorType">
> > > > > > > <xs:complexContent>
> > > > > > > <xs:extension base="AttributeSelectorBaseType">
> > > > > > > <xs:attribute name="RequestContextPath" type
="xs:string"
> > > use
> > > > > > > ="required"/>
> > > > > > > </xs:extension>
> > > > > > > </xs:complexContent>
> > > > > > > </xs:complexType>
> > > > > > >
> > > > > > > <xs:complexType name="AttributeSelectorIndirectType">
> > > > > > > <xs:extension base="AttributeSelectorBaseType">
> > > > > > > <xs:choice>
> > > > > > > <xs:element ref="xacml:SubjectAttributeDesignator"/>
> > > > > > > <xs:element ref="xacml:ResourceAttributeDesignator"/>
> > > > > > > <xs:element ref="xacml:ActionAttributeDesignator"/>
> > > > > > > <xs:element ref
="xacml:EnvironmentAttributeDesignator"/>
> > > > > > > </xs:choice>
> > > > > > > </xs:extension>
> > > > > > > </xs:complexType>
> > > > > > >
> > > > > > > <xs:element name="AttributeSelector"
> > > type="AttributeSelectorType"/>
> > > > > > > <xs:element name="AttributeSelectorIndirect" type
> > > > > > > ="AttributeSelectorIndirectType"/>
> > > > > > >
> > > > > > > <xs:element name="XPathNamespace"
> > > type="xacml:XPathNamespaceType"
> > > > > > > substitutionGroup="xacml:AbstractDefaults"/>
> > > > > > > <xs:complexType name="XPathNamespaceType">
> > > > > > > <xs:attribute name="NamespaceURI" type="xs:anyURI"/>
> > > > > > > <xs:attribute name="Prefix" type="xs:string" use
="optional"/>
> > > > > > > </xs:complexType>
> > > > > > >
> > > > > > >
> > > > > > > Sample text for this element:
> > > > > > >
> > > > > > > 5.28. Element <AttributeSelectorIndirect>
> > > > > > >
> > > > > > > The <AttributeSelectorIndirect> element is a free-form
pointing
> > > > device
> > > > > > into
> > > > > > > the <xacml-context:Request> element using an attribute
> > > designator.
> > > > The
> > > > > > > actual xpath expression is retrieved from the context pointed
> by
> > > that
> > > > > > > attribute designator. Other than that, the semantics is the
> same
> > > with
> > > > > > > <AttributeSelector> element. Support for the
> > > > > <AttributeSelectorIndirect>
> > > > > > > element is OPTIONAL.
> > > > > > >
> > > > > > > The <AttributeSelectorIndirect> element is of
> > > > > > AttributeSelectorIndirectType
> > > > > > > complex type.
> > > > > > > The <AttributeSelectorIndirect> element has either one of the
> > > > following
> > > > > > > elements:
> > > > > > >
> > > > > > > SubjectAttributeDesignator
> > > > > > > ResourceAttributeDesignator
> > > > > > > ActionAttributeDesignator
> > > > > > > EnvironmentAttributeDesignator
> > > > > > >
> > > > > > > Michiharu
> > > > > > >
> > > > > > > IBM Tokyo Research Laboratory, Internet Technology
> > > > > > > Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> ----------------------------------------------------------------
> > > > > > > To subscribe or unsubscribe from this elist use the
> subscription
> > > > > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
----------------------------------------------------------------
> > > > > > To subscribe or unsubscribe from this elist use the
subscription
> > > > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > To subscribe or unsubscribe from this elist use the subscription
> > > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > > >
> > > >
> > > >
> > > > ----------------------------------------------------------------
> > > > To subscribe or unsubscribe from this elist use the subscription
> > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ----------------------------------------------------------------
> > > > To subscribe or unsubscribe from this elist use the subscription
> > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> >
> >
> >
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
>
>
>
>
>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC