RE: [xacml] Hierarchical Profile and the URI

["Hal Lockhart" <hal.lockhart@oracle.com>]

Well as I said, I don't feel too strongly about this, but the 2.0 profile requires you do both, so apparently some folks thought that there might be a need to do not merely matching, but also parsing of the URI even when the ancestor attributes have been provided.

Hal

> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com]
> Sent: Tuesday, March 10, 2009 10:35 AM
> To: hal.lockhart@oracle.com
> Cc: Rich.Levinson; xacml@lists.oasis-open.org
> Subject: Re: [xacml] Hierarchical Profile and the URI
> 
> Hi Hal,
> 
> I think the point with the "URI matching" method is to gain a
> performance and implementation simplicity advantage by not having to
> provide the ancestor attributes. If we would require the ancestor
> attributes as well for the URI matching method, then the URI matching
> method becomes somewhat meaningless.
> 
> Best regards,
> Erik
> 
> Hal Lockhart wrote:
> > I did understand what you meant. What I was trying to get at is I
> believe the 2.0 Profile requires hierarchical URIs and the ancestor stuff.
> In this case, the hierarchical URIs can be operated on by any of the URI
> type functions.
> >
> > As I said in the first msg after the call, the only drawback I see to
> this is that the ancestor information and the URI form might be
> inconsistent with each other. As I also said, there are lots of other ways
> that the Request Context can contain inconsistent information, which we do
> not prohibit, so this does not seem like a serious issue.
> >
> > If we split these two approaches, rather than leaving them merged, then
> we will only avoid inconsistencies by requiring that when Ancestor
> information is provided, it is prohibited to name the resource and its
> ancestors using a hierarchical URI. This seems too extreme. It seems to me
> to be desirable to let users name their resources in the most natural way
> for their environment.
> >
> > I don't feel that strongly about this, so if the TC wants to change the
> Profile to say that in the non-XML case you can either provide a bunch of
> hierarchical names OR provide a bunch of non-hierarchically named
> ancestors, them I will go along with it.
> >
> > Hal
> >
> >
> >> -----Original Message-----
> >> From: Erik Rissanen [mailto:erik@axiomatics.com]
> >> Sent: Tuesday, March 10, 2009 10:02 AM
> >> To: hal.lockhart@oracle.com
> >> Cc: Rich.Levinson; xacml@lists.oasis-open.org
> >> Subject: Re: [xacml] Hierarchical Profile and the URI
> >>
> >> Hi Hal,
> >>
> >> I think I have used the term "URI scheme" in a sloppy manner, and I can
> >> see that I have confused you. :-)
> >>
> >> One meaning of "URI scheme" is the manner in which we restrict the
> >> allowed forms of the URI, which I think you are thinking about here.
> >>
> >> I have used "URI scheme"  in the meaning of a third way to do
> >> hierarchical access control. The first is the 2.0 profile "nodes in XML
> >> documents". The second is the 2.0 profile "nodes in resources that are
> >> not XML documents".
> >>
> >> The third variant, which I have called "the URI scheme", is another,
> >> entirely different way of doing hierarchical access control which Rich
> >> has proposed: to use regular expression matching on a URI. In this case
> >> the ancestor are not listed as separate attributes in the request
> context.
> >>
> >> For clarity, I think we should have a name for the third method. What
> >> about "nodes in resources which are hierarchical URIs". Maybe "URI
> >> matching" for short? Anyone have a better name?
> >>
> >> Best regards,
> >> Erik
> >>
> >> Hal Lockhart wrote:
> >>
> >>> My reading of the 2.0 Profile is that you MUST use a file: scheme URI
> >>> (or other hierarchical URI scheme, modulo some sloppy wording) to name
> >>> the Parents and Ancestors as well as the Resource and that Parents and
> >>> Ancestors MUST be provided in order to comply with the Profile.
> >>>
> >>>
> >>>
> >>> Out of a desire to retain as much compatibility with 2.0 as possible,
> >>> I was proposing only the parts needed to meet various requirements and
> >>> concerns be changed. To me the minimum change seems to be to keep the
> >>> URI scheme largely the same and allow the possibility of non-URI
> >>> identifiers.
> >>>
> >>>
> >>>
> >>> Hal
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ----------------------------------------------------------------------
> --
> >>>
> >>> *From:* Rich.Levinson [mailto:rich.levinson@oracle.com]
> >>> *Sent:* Tuesday, March 10, 2009 9:27 AM
> >>> *To:* Erik Rissanen
> >>> *Cc:* hal.lockhart@oracle.com; xacml@lists.oasis-open.org
> >>> *Subject:* Re: [xacml] Hierarchical Profile and the URI
> >>>
> >>>
> >>>
> >>> Hi Erik and Hal,
> >>>
> >>> Erik is correct. The scheme in 3.2.2.1 of the proposed v5-02 is based
> >>> on the assumption that URIs are in the form prescribed in section 2.2.
> >>>
> >>> As to accuracy of the "form" in section 2.2, the only real problem I
> >>> see is that the ":" should be fixed to be "://". I believe this was an
> >>> oversight in the original.
> >>>
> >>> As to the inclusion of the "/" after the "<authority>", this is
> >>> because the <authority> in the notes following is assumed to be always
> >>> present, which means according to RFC 2396 that a "/" will, at minimum
> >>> follow.
> >>>
> >>> The "<path>" is then prescribed to be <root name> [ "/" <node name> ]
> >>> * , which is a perfectly legal URI.
> >>>
> >>> As to the intention of this section being simply a faulty summary of
> >>> the RFC 2396 spec vs a "prescription" recommended URI, I would cite
> >>> the original email and spec where this data appeared:
> >>> http://lists.oasis-open.org/archives/xacml/200405/msg00104.html
> >>>
> >>> which says:
> >>>
> >>> "The revision has the following significant changes:
> >>>
> >>> 1) Proposes a standard URI representation for hierarchical resources
> >>> that are not XML documents. This representation allows use of the
> >>> anyURI-equal and anyURI-match functions where the path to a requested
> >>> node is important. This representation may be overridden by a
> >>> resource-specific Profile. ..."
> >>>
> >>> This appears to fairly unambiguously state that it is a prescription
> >>> specially defined to ensure that it would work with the anyURI
> functions.
> >>>
> >>> Furthermore, the whole section in the actual text of that revision
> >>> (attached to the email ref) was prefaced by this sentence:
> >>>
> >>> "Unless otherwise specified by a resource-specific Profile, the
> >>> identity of a node in a resource that is not an XML document SHALL be
> >>> in the form specified the remainder of this Section."
> >>>
> >>> This sentence appears to have been dropped in some rearrangement of
> >>> the next version:
> >>> http://lists.oasis-open.org/archives/xacml/200406/msg00008.html
> >>> http://lists.oasis-open.org/archives/xacml/200406/msg00009.html
> >>>
> >>> where the first email describes the release, which was only breaking
> >>> up the previous version into the multi and hier profiles, and
> >>> specifically says that it "contains the same hierarchical resources
> >>> content" as the previous version. Point being any info conveyed in
> >>> above sentence was not intentionally dropped as indication of change
> >>> of purpose.
> >>>
> >>> Bottom line on URI section 2.2, is that I think it is fine except for
> >>> above typo of "://" and there might be some slight grammatical
> >>> corrections needed.
> >>>
> >>> Any other prescription for URI forms or other node identity
> >>> representations that people might want, I suggest be put in another
> >>> section.
> >>>
> >>> One final note is that it is interesting to follow the evolution of
> >>> what was to become the final 3.2 algorithms for ancestor selection in
> >>> these early drafts. It is pretty clear that the original hierarchies
> >>> were regarded as a forest and there was no explicit intention to
> >>> transform these into a DAG, which is the unfortunate result of the
> >>> subsequent changes that were made to these algorithms, which in
> >>> seemingly innocent identification of ancestors to be collected
> >>> apparently inadvertently created the implied condition that the
> >>> collection became transformed to a DAG.
> >>>
> >>> Again, I do not recommend removing the DAG transformation and keep it
> >>> in the v5-02 section 3.2.1, however, we do need to include the option
> >>> for the forest representation, which is covered in v5-02 section
> >>> 3.2.2. Finally, the 2.2 URI section is picked up as the concrete
> >>> forest "implmentation" in section 3.2.2.1.
> >>>
> >>>     Thanks,
> >>>     Rich
> >>>
> >>>
> >>>
> >>> Erik Rissanen wrote:
> >>>
> >>> Thanks Hal for the clarifications.
> >>>
> >>> For the URI based scheme which Rich is proposing, we would require
> >>> that the data type is a URI. It's an alternative form of
> >>> requests/policies for hierarchical resources, which is independent of
> >>> and not used in combination with the ancestor scheme. (Or at least
> >>> that I was I think. Rich, please correct me if I am mistaken.)
> >>>
> >>> I'm not sure what to do with the actual form of the URI. Should we
> >>> mandate a subset of the URI space? Or do we leave it as something to
> >>> be agreed between the PEP and PDP/Policies?
> >>>
> >>> Best regards,
> >>> Erik
> >>>
> >>> Hal Lockhart wrote:
> >>>
> >>> In addition to previously discussed issues, I would like to fix the
> >>> sections in the hierarchical profile on using URIs.
> >>>
> >>> In section 2.2 the profile says:
> >>>
> >>> ----
> >>> The identity of a node in a hierarchical resource that is not
> >>> represented as an XML document instance SHALL be represented as a URI
> >>> that conforms to [RFC2396]. Such URIs are of the following form.
> >>>     <scheme> ":" <authority> "/" <pathname> ----
> >>>
> >>> This is not true and it is not what RFC 2396 says. In section 3, it
> >>>
> >> says:
> >>
> >>> ---
> >>> The URI syntax is dependent upon the scheme.  In general, absolute
> >>>    URI are written as follows:
> >>>
> >>>       <scheme>:<scheme-specific-part>
> >>>
> >>>    An absolute URI contains the name of the scheme being used
> (<scheme>)
> >>>    followed by a colon (":") and then a string (the <scheme-specific-
> >>>    part>) whose interpretation depends on the scheme.
> >>>
> >>>    The URI syntax does not require that the scheme-specific-part have
> >>>    any general structure or set of semantics which is common among all
> >>>    URI.  However, a subset of URI do share a common syntax for
> >>>    representing hierarchical relationships within the namespace.  This
> >>>    "generic URI" syntax consists of a sequence of four main
> components:
> >>>
> >>>       <scheme>://<authority><path>?<query>
> >>>
> >>>    each of which, except <scheme>, may be absent from a particular URI.
> >>>    For example, some URI schemes do not allow an <authority> component,
> >>>    and others do not use a <query> component.
> >>> ----
> >>>
> >>> Some URI schemes use a hierarchical path component with segments
> >>> separated by "/" and others do not. This is not mere nitpicking as the
> >>> XML Schema AnyURI type is defined as containing "a URI as defined by
> >>> RFC 2396. This means a valid type checked element of type AnyURI can
> >>> contain something like email:john@example.com
> >>> <mailto:email:john@example.com> or
> >>> http://www.example.com/main/index.html.
> >>>
> >>> It seems to me that we should recommend as a matter of best practice
> >>> that policies first check the scheme name using the uri-starts-with
> >>> function before using any regex functions to pick the hierarchical
> >>> portion apart.
> >>>
> >>> This brings us the question of what type of URI to allow or permit to
> >>> be used to represent a hierarchical resource on the non-XML type.
> >>> Obviously since we decided to allow any data type, we can no longer
> >>> require that a URI be used at all. However, I suggest we follow the
> >>> existing profile and say that if a URI is used, then if the resource
> >>> already is named using a registered scheme OF THE HIERARCHICAL TYPE,
> >>> then that should be used, otherwise a "file" scheme URI should be
> >>> constructed as described in the current (2.0) profile.
> >>>
> >>> Hal
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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:
> >>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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:
> >>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> 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:
> >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >>
> >>
> >
> >
> 
> 
> ---------------------------------------------------------------------
> 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:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>