[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: new OASIS discussion list : XACML
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC