MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [xacml] Observation on "context"
Tim,
I am not all that familiar with the intricacies of XPATH. However,
something has been bothering me for quite sometime. It appears that XPATH
can only get you the information at a particular node of a document
downwards, and any upwards information about how you got there is gone,
correct?
For example, suppose there were more than one particular thing referenced
by a prefix of an XPATH expression. Just for fun, let's say we have
multiple resources, If you ask for an attribute of:
<equals>
<RequestContext/Resources/ResourceAttribute[@AttributeName="Forest"]/AttributeValue>
<AttributeValue>
Sherwood
</AttributeValue>
</equals>
You kind of loose the thing of which had the "Forest" attribute of
"Sherwood", and the only thing at your disposal is
<AttributeValue>Sherwood</AttributeValue>
Cheers,
-Polar
On Mon, 3 Jun 2002, Tim Moses wrote:
> Anne - I think I am starting to "get the picture". Forgive me for being
> slow on the uptake. Would this be another way of putting it ? ...
>
> The basic entities are universal, regardless of the application domain.
> They are the subject, resource and action. The SAML data models for these
> entities are inadequate. There are some universal aspects to these data
> models (subjects have attributes, for instance). But, some elements differ
> between application domains and (in addition) we cannot anticipate how
> domains may need to extend these data models. This sounds like a job for
> XML, because it can express arbitrarily-complex data models and is
> extensible.
>
> If this is the case, I might want to rethink my view that XPATH is not the
> right way to identify context elements. If we are deliberately choosing an
> extensible mark-up language to model the context, then perhaps all the tools
> associated with that language should be available to us to manipulate an
> instance of it. An XPATH expression would be a convenient way to identify
> an element such as: 'the role attribute of the subject whose name is
> "codesigner"'. For sure, we don't need the full complexity of XPATH, but
> perhaps we could define a small subset.
>
> Thoughts any one?
>
> All the best. Tim.
>
> -----------------------------------------
> Tim Moses
> Tel: 613.270.3183
>
>
> -----Original Message-----
> From: Anne Anderson [mailto:Anne.Anderson@Sun.com]
> Sent: Thursday, May 30, 2002 2:58 PM
> To: XACML TC
> Subject: Re: [xacml] Observation on "context"
>
>
> On 30 May, Tim Moses writes: [xacml] Observation on "context"
> > For instance, we could define a name tree that includes:
> >
> > xacml/context/input/principal/codeSigner/name
> >
> > to indicate the name of the code-signer principal in the input context.
> > This idea doesn't conflict with the excellent idea of a "context". It
> > merely gets away from thinking of it as an XML document. You could think
> of
> > it as equivalent to an XML document in which attributes are not allowed,
> if
> > you like.
>
> I think the problem here is that XACML would need to define a
> "standard" set of names like "codeSigner", "requestingUser",
> "executingMachine", "delegatingUser", etc.
>
> By using an XML attribute, XACML can define a default
> "requestingUser" value, and let others be URLs that specific user
> communities define.
>
> Anne
> --
> Anne H. Anderson Email: Anne.Anderson@Sun.COM
> Sun Microsystems Laboratories
> 1 Network Drive,UBUR02-311 Tel: 781/442-0928
> Burlington, MA 01803-0902 USA Fax: 781/442-1692
>
>
> ----------------------------------------------------------------
> 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