[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