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] 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
>>
>>     
>
>   



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