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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: Re: [xacml] Revised proposal for issue #11, using XPath/URI pathexpressions

Hi Erik,

One question that occurred to me during this discussion, is that when using AttributeSelectors, there doesn't appear to be any direct way to obtain the base URI of the XML document that gets placed in the Attributes/Content element, which may account for at least part of the difference of the URI proposal where resource-id may be

  • <uri>#/<fragment-id>  or
  • <uri>#/xpointer(<fragment-id>) depending on where that discussion (in emails w Paul inserted below) ends up.
vs the XPath scheme where resource-id is:
  • <fragment-id>
where <fragment-id> as defined in previous emails is the relative XPath from the document element to the node or nodes that are being requested.

The point I am trying to get at is: it appears to me that the <uri> of the actual document/file that contains the xml that is placed in the Attributes/Content is not included anywhere in the request, unless, of course, it was provided in a separate Attribute element. Is that correct, and if so, is it something that might need to be addressed with some explanatory text?


Erik Rissanen wrote:
4B0D250E.2020402@axiomatics.com" type="cite">Hi Rich,

Thanks for the clarification. I thought you said that the same attribute values (and thus the same request) could be used directly for both schemes without modification.

But what you actually say is that the same fragment can be reused as a piece to implement either scheme, though separately. I would agree with that.

Best regards,

-------- Original Message --------
Subject: Re: [xacml] Revised proposal for issue #11, using XPath/URI path expressions
Date: Wed, 25 Nov 2009 13:22:09 -0500
From: Rich.Levinson <rich.levinson@oracle.com>
To: Tyson, Paul H <PTyson@bellhelicopter.textron.com>
CC: Erik Rissanen <erik@axiomatics.com>, xacml <xacml@lists.oasis-open.org>
References: 4B09DAA8.8010601@oracle.com"><4B09DAA8.8010601@oracle.com> 4B0A87B4.6000103@axiomatics.com"><4B0A87B4.6000103@axiomatics.com> 4B0B289E.3080907@oracle.com"><4B0B289E.3080907@oracle.com> 4B0B9B24.8030804@axiomatics.com"><4B0B9B24.8030804@axiomatics.com> 4B0CE0CD.60303@oracle.com"><4B0CE0CD.60303@oracle.com> 3898C40CCD069D4F91FCD69C9EFBF096040BFE5E@txamashur004.ent.textron.com"><3898C40CCD069D4F91FCD69C9EFBF096040BFE5E@txamashur004.ent.textron.com>

Hi Paul,

That's an interesting suggestion about XPointer. I had looked at it earlier and become somewhat discouraged because of both my personal experience with it in the context of XML Signature and the fact that the specs never seemed to me to have a clear focus, and appear to be left in a somewhat unfinished state (for example: http://www.w3.org/TR/xptr-xpointer/).

That being said, it is probably worth revisiting in the current discussion. XPointer did appear in XACML 2.0 example: lines 1063-1065:
1063 [a184]     //med.example.com/records/bart-simpson.xml#
1064 [a185]     xmlns(md=:Resource/ResourceContent/xpointer
1065 [a186]     (/md:record/md:patient/md:patientDoB)
which we decided to remove, because it appears syntactically incorrect and we weren't sure exactly what it was trying to say.

However, (considering http://www.w3.org/TR/xptr-xmlns/) it does seem to me that the following syntax might be correct:
However, I think the syntax we have developed in the emails over the last couple of days can also be used here, with the advantage that it makes the "prefix problem" go away, in which case, the above example could be alternatively represented as:
The above syntax removes the random "md", which is a problem for regular expression matching, because what is needed is the value the prefix represents, which is a well defined string, as opposed to the prefix which can be a randomly set string which cannot be relied upon for regexp matching. (Note: I am not sure if the Resource/ResourceContent is actually required, but if it is, then each of those elements will require a namespace-uri() predicate as well, because they use the default namespace as opposed to no namespace.)

Assuming that the above is correct, I am attaching a slightly modified proposal
(see msg: http://lists.oasis-open.org/archives/xacml/200911/msg00068.html or direct to doc: http://lists.oasis-open.org/archives/xacml/200911/doc00004.doc)
to incorporate your suggestion, which defines the fragment as follows:
<fragment> = "xpointer(/"  <fragment-id>  ")"
which should allow the <fragment-id> to be a relative XPath path expression that can be used wrt to the Context element for data-type:xpathExpression and/or the ResourceContextPath attribute. Also, in the intended usage, the "xpointer()" function itself will never need to be actually executed, as its purpose is to only conform to the XPointer framework syntax.


Tyson, Paul H wrote:
3898C40CCD069D4F91FCD69C9EFBF096040BFE5E@txamashur004.ent.textron.com" type="cite">
Did you consider whether the XPointer framework would work for the fragment part of the URI?
It provides for namespace binding, and a few different schemes for locating elements within an xml resource.

4B0D250E.2020402@axiomatics.com" type="cite">
Rich.Levinson wrote:
Hi Erik,

Let me try to explain with a very simple example just to show the flow.

   * Say we have an xml document foo.xml w content:
     located at <uri> = http://ex.com/foo.xml.
   * For simplicity, assume the caller knows nothing of the files or
     xml, but that the pep somehow knows the user needs to access the
     content of /A/B in order to be granted access.
   * Also to simplify discussion, assume there is another clause in the
     proposal that says:
     <fragment> = "/" <fragment-id>
     so the discussion following without losing generality will focus
     on <fragment-id>, which consists of everything on line 254 of
     proposal except for the leading slash.
   * According to the proposal, the <fragment-id> that would be created
     to access  /A/B, would be:
     <fragment-id> = *:A[namespace-uri()=""][1]/*:B[namespace-uri()=""][1]
     which, because of the empty namespace-uri value, would reduce to:
     <fragment-id> = A[1]/B[1]
   * Now, using core Example 2: request context section 4.2.2 and rule
     2, section as a guide, for the request context, we could
     include an Attribute as follows:
     <Attribute AttributeId="...resource:resource-id">        <AttributeValue
     where we just insert <fragment-id> as the AttributeValue.
   * Similarly, the policy, like lines g64-g75 would say:
     <Match MatchId="...function:xpath-node-match">
       <AttributeDesignator MustBePresent="false"
   * By comparison, with the URI method, one would submit a resource-id of:
     and use regular expression matching as we've discussed.

The point is that the same automatically constructed string, <fragment-id> could be used by both methods. And, the reason I am suggesting it, is that for the multiple resource profile, for both the xml and non-xml use cases there is a need for constructing resource-id's, which are capable of individually addressing every node in an XML document. It seems to me that this technique, which I believe enables the URI approach to encompass both non-XML and XML resources, can be used with the XPath-oriented method as well.


Erik Rissanen wrote:
Hi Rich,

No, I still don't understand how the identifiers could be used as xpaths in policies.

I can understand the regexp case. For instance, assume that the request contains

<Attributes Category="resource">
 <Attribute AttributeId="resource-id">
   <AttributeValue Datatype="anyURI">http://example.com/foo#*:bar[namespace-uri='example.com/ns1']</AttributeValue>

then one could do something like this in a policy:

<Match MatchId="urn:....:anyURI-regexp-match">
 <AttributeValue Datatype="string">...some regexp here...</AttributeValue>
 <AttributeDesignator AttributeId="resource-id" Datatype="anyURI"/>

But how would you use the resource-id as an xpath expression? Where would you put it in the policy and using what construct?

Best regards,

Rich.Levinson wrote:
Hi Erik,

You were right about the syntax, there needs to be a leading "*" in order to collect "all" the child nodes and then discriminate based on local-name() and namespace-uri(). However, I did find the "*:<local-name-literal> works as well, so I modified the spec (attached) to include a leading "*:" (star-colon) before the local-name-literals. I also added a couple of notes to indicate that, as well as pointing out that the strings

   * /*:abc[namespace-uri()=""]
   * /abc

are equivalent, so that for the no-namespace use cases, there is no need for the prefix and predicate.

On the issue of how xacml treats the identifier, I finessed that a bit as follows: it is the <fragment> item that is serving as the identifier within the XML document itself. So, as specified, it should work as an xpathExpression, possibly without the leading "/", in an AttributeSelector. The proposed specification says that the expressions that conform to the proposed <fragment> layout only need to be percent-encoded when put within a URI. So, for example, if one wanted to use it as the AttributeValue for a resource-id Attribute, there is no technical reason why it needs to be percent-encoded.

Regarding issue 11, the problem was to pin down a consistent syntax so that regular expression matching rules could be specified. The original proposal I submitted addressed this issue by providing a non-xpath syntax in the hierarchical URI scheme, which provided an "alternative" representation for identifying the nodes in an XML document.

Further analysis of the problem, and especially Paul's raising the issue of resource-id's caused me to consider the present proposal, which I consider superior to the original proposal because it serves to layout a method by which identifiers can be automatically produced that can be used by both the XPath representation and the URI representation, which potentially provides a clean break between the naming of the node and the accessing of the node. The particular XPath syntax proposed appears to enable the separation of these two operations so that the literal XPath expressions can be used either as literal identifiers or operational language statements, that "identify" the node in the former case and "access" the node in the latter case..

Hopefully, the above comments address the concerns you raised.


Erik Rissanen wrote:

You say that the identifier serves as"an executable expression that can be applied to an XML document". That is true from a threoretical point of view, but there are currently no XACML functions which can operate on an URI like this. The URI needs to be resolved and then the path needs to be extracted before it can be applied as an XPath expressions. So it is a fundamentally new scheme, not a modification to the XPath scheme which started issue #11.

BTW, did you check the XPath syntax? If I recall correctly from the past, foo[namespace-uri="bar"] does not work. I think I had to do *[localname='foo'][namespace-uri='bar']. I could be wrong though...

Best regards,

Rich.Levinson wrote:
To TC:

As described in previous email:
I have revised the original proposal submitted for issue 11.

This proposal is intended to address the same problems as the previous proposal, and it also provides a format which can potentially be used to address the resource-id naming issue raised by Paul Tyson:

A summary of expected benefits from this proposal includes the following:

    * The proposal provides an automatic naming method for any node in
      an XML document, in the form of an XPath path expression, that
      may also be used to retrieve the actual node identified.
    * The proposal shows how to map this expression into standard URI
      format by percent encoding each XPath step component that
      follows a URI fragment slash "/".
    * An XPath step in the proposal is represented by the
      concatenation of 3 strings as a local-name plus two optional
      predicates, each of which is immediately determinable when in
      the XPath context of the document using standard XPath
      functions: local-name(), namespace-uri(), and position() and the
      full set of steps in the expression can be used to obtain the
      single node addressed from any XPath context because the path is
    * The unencoded XPath path expression can be used as the identity
      of a node in an XML document as described in section 2.1 of the
      hierarchical profile.
    * The unencoded XPath expression can be used as the resource-id as
      described in section 2.2.3 of the Multiple Resource Profile.
    * The XPath path expression can be used with or without the
      associated XML document. i.e. the expression serves as BOTH an
      executable expression that can be applied to an XML document AND
      a literal identifier that can be used by regular expression
      matching type operations.
    * Percent-encoding of the XPath path expression is only required
      when the expression is used as an actual URI, such as when
      extending the URI mechanism into XML documents to identify
      entities within the document, or when used as an identifier that
      requires URI syntax such as an XML AttributeId attribute.
    * In general, because the XPath path expression can operate as a
      literal identifier, it enables policies to be written against
      resources within XML documents which enable policy evaluation
      before the document is accessed.

I will try to prepare a slide presentation prior to the F2F. In the meantime, hopefully, the information is intended to be self-explanatory.

Comments and suggestions welcome.



To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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