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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: RE: Resource sets and resource string semantics


Folks-- Be aware that Hal Lockhart has been having email trouble.  I've 
copied him above in the hope that this message will slip in to his system, 
but he's been kicked off the security-services list because of bounces, and 
I don't think most people have seen his post quoted below.  (I didn't 
receive it from the sec-svcs list; I imagine Simon saw it because he was 
explicitly copied.)

         Eve

At 08:33 AM 5/15/01 -0700, Simon Y. Blackwell wrote:
>Re: "3. Its important to keep XACML separate. Since XACML is for policy
>exchange,it will need the richest possible language to express policy
>assertions. As I understand the current charter, it must be able to
>represent any possible resource name that can be expressed in XML (I don't
>think that excludes anything) and is not limited to XML documents."
>
>Correct ... now if we can just manage to do it.
>
>-----Original Message-----
>From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
>Sent: Tuesday, May 15, 2001 7:26 AM
>To: 'Phillip Hallam-Baker'; 'Simon Y. Blackwell';
>'xacml@lists.oasis-open.org'; 'security-services@lists.oasis-open.org'
>Subject: RE: Resource sets and resource string semantics
>
>
>This raises a number of issues.
>
>1. On the understanding that in SAML returning a wild carded decision
>assertion is purely an optimization that must be explicitly asked for by the
>requestor, I withdraw my objections. I still think this optimization is
>unlikely to be useful in practice, but if others disagree, I am willing to
>go along with it. Is the wildcard constrained to encompass the resource in
>the orginal request?
>
>2. In a modern web environment, the existence of
>
>http://www.mumble.com/x/y/z/a
>and
>http://www.mumble.com/x/y/z/b
>
>by no means implies that
>
>http://www.mumble.com/x/y/z
>
>is a directory. This may have been true in the mid 90's, but it is not true
>today. More likely all three resolve to distinct, dynamic pages. SAML
>functionality based on the premise that the path syntax represents a
>directory heirarchy, rather that merely an heirachical namespace would be an
>unreasonable constraint on local implementation. I am not saying the current
>proposal does this, I am just warning about going in that direction.
>
>3. Its important to keep XACML separate. Since XACML is for policy exchange,
>it will need the richest possible language to express policy assertions. As
>I understand the current charter, it must be able to represent any possible
>resource name that can be expressed in XML (I don't think that excludes
>anything) and is not limited to XML documents.
>
>4. According to RFC 2396, http:\\...\document.html\Body\H1 is not a legal
>URI. I am aware that Microsoft is under the opposite impression, but I
>thought this was a open standards activity. At the least, if we are going to
>use "URI" we should identify the document defining it, if it is not RFC
>2396.
>
>Hal
...
--
Eve Maler                                             +1 781 442 3190
Sun Microsystems XML Technology Development  eve.maler @ east.sun.com



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


Powered by eList eXpress LLC