RE: new OASIS discussion list : XACML

[Hal Lockhart <hal.lockhart@entegrity.com>]

I agree with Nigel. The only differences I can see is the granularity of the
resource being protected and the maturity of the problem space.

I would prefer to see a single scheme to cover all requirements. If two
schemes are required then a single effort which clearly defines when each
should be used is surely preferable to two efforts which overlap.

Hal
=======================================================
Harold W. Lockhart            Entegrity Solutions
2 Mount Royal Avenue          Marlborough, MA 01752 USA
V: 1-508-624-9600 x 260       hal.lockhart@entegrity.com
F: 1-508-229-0338             www.entegrity.com
=======================================================



> -----Original Message-----
> From: Edwards, Nigel [mailto:Nigel_Edwards@hp.com]
> Sent: Monday, February 26, 2001 1:14 PM
> To: 'George_Robert_Blakley_III@tivoli.com'
> Cc: security-services@lists.oasis-open.org
> Subject: RE: new OASIS discussion list : XACML
> 
> 
> > Nigel,
> > 
> >> I do not see how to separate "an XML framework for exchanging
> >> authentication and authorization information (SAML)" and "the
> >> representation of access control policies as XML". It 
> seems to me that
> >> the later is a subset of the former.
> > 
> > I disagree.  I think security assertions are (in the language of ISO
> > 10181-3)
> > subject control attributes, where as access control 
> policies are just that
> > --
> > access control policies.  There is also such a thing as a 
> target control
> > attribute
> > (e.g. a sensitivity label).  I don't think that any input 
> document to
> > SAML defines either access control policies or target 
> control attributes,
> > and I don't think that the document we finally produce SHOULD define
> either
> > of these.
> > 
> > I can imagine a spec. which would define either or both of 
> these other
> > things,
> > and I think that XACML is targeted at defining an XML 
> format for access
> > control
> > policies together with a way to associate them with the 
> documents they
> > govern.
> > 
> 
> Bob,
> This is largely a question of viewpoint. However, from my viewpoint
> the distinctions are not as clear as you suggest.
> 
> On the table we have S2ML which contains a mechanism to issue
> authorization requests and responses for controlling access to
> resources on a web server (statements of the form (verb,URI)). It is
> not clear that authorization model that we will end up with. If
> somebody proposes a more general model, will it be ruled out of scope?
> 
> Even what we have now in S2ML may be sufficient to provide some access
> control policy information for XML documents.  Suppose the web
> server in question is serving XML documents. It seems to me that what
> is in S2ML would be sufficient to express some access control policy
> information on those XML documents.
> 
> In the above you say that none of the current submissions define
> access control policies, by this I assume you mean a framework for
> expressing access control policies. I don't know exactly what you mean
> by Access Control Policy. However, our own draft definition says "The
> set of rules that define the conditions under which an access may take
> place." It seems to me you could use S2ML to express a set of such
> rules.
> 
> You also seem to be suggesting a split on subject versus target (or
> security-object?) assertions. If the target is an active entity such
> as a server, then assertions can be made about it using the proposals
> that have been made to the Security Services TC. If the target is
> passive (such as an XML document), then things are less clear. However
> from my viewpoint, it would not be a massive extension to some of the
> proposals to allow the subject of an assertion to be a hash (e.g. of
> an XML document). This is a natural extension if you are familiar with
> SPKI [RFC 2692, RFC 2693] which blurs these distinctions and allows
> what I have described. Hence it's a question of viewpoint.
> 
> Nigel.
>  
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: 
> security-services-request@lists.oasis-open.org
>