[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: FW: XACML TC Charter Revision - Strawman
-----Original Message----- From: Simon Y. Blackwell Sent: Friday, June 08, 2001 8:52 PM To: 'Pilz, Gilbert' Subject: RE: XACML TC Charter Revision - Strawman I agree with Gilbert. We need to do some use case work. There is nothing to prevent us from tweaking the charter at a later time. Also is the term "subject" defined in the glossary? If not, perhaps it should be. > -----Original Message----- > From: Pilz, Gilbert [mailto:gpilz@jamcracker.com] > Sent: Thursday, June 07, 2001 6:22 PM > To: 'xacml@lists.oasis-open.org' > Subject: RE: XACML TC Charter Revision - Strawman > > > On the whole I agree with you, but I would argue that SAML > shouldn't make > any assumptions about the policy space. To the extent that > SAML may or may > not be assuming a (Subject X Object X Resource X Action) > policy space it is > assuming some aspects of the authorization model. > > This is something I got into for a bit when the XACML effort was being > proposed. I think the first and most important issue that we > have to resolve > is: "Is it possible to define a language/schema for > expressing authorization > policy without also defining an authorization model?". I would say the > answer is "no", but I think others would disagree with me. > > I think we need to 'fess up to the fact that we are going to > end up (one way > or another) defining an authorization model. I know that, in > the past, many > good efforts have crashed on the rocks of a "common > authorization model", > but I just can't see how we can define a language for > expressing policies > outside of some framework for interpreting that language > (Someone once asked > me to analyze the performance characteristics of a body of C code > "irrespective of the target architecture". Being young and > foolish, I worked > on the problem for 2 or 3 days before I realized it was a meaningless > question.) > > I think the best way to proceed is to first agree on our Use > Cases, and then > define a minimally constraining authorization model that > meets the needs of > those Use Cases. From there we can work on the specifics of the policy > language . . . > > -----Original Message----- > From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com] > Sent: Thursday, June 07, 2001 4:33 PM > To: 'Pilz, Gilbert'; 'xacml@lists.oasis-open.org' > Subject: RE: XACML TC Charter Revision - Strawman > > > Gilbert, > > Good point. SAML is likely using "object" to mean the same > thing as our > "target." This is because SAML is assuming a (Subject X > Object X Resource X > Action) > space [1]. If we were to use the same space, we could use "object." > > On the other hand, when we get closer to "target specification," > we would know exactly whether "target" is the same as "object." > E.g., XACML might specify a "target" can have a "Role." > In SAML, now only "Subject" has a "Role." > > In brief, XACML "target" has the potential not to mean the > same as "object" > in SAML, and because of that we can use the term "target" without > conflict with SAML specs. Sound right? > > [1] > http://www.oasis-open.org/committees/security/docs/draft-sstc- > saml-spec-00.P > DF > > -Suresh > > -----Original Message----- > From: Pilz, Gilbert [mailto:gpilz@jamcracker.com] > Sent: Thursday, June 07, 2001 4:41 PM > To: 'xacml@lists.oasis-open.org' > Subject: RE: XACML TC Charter Revision - Strawman > > > Suresh, > > I think that, before we change the terminology from "subject" > to "target" we > should see if we can get the SAML folks to agree to this > change. According > to the "XACML statement of purpose": > > Related Work: To ensure work is not duplicated and standards > adoption is as > simple as possible, XACML shall adopt as baseline documents the work > products of the Security Services TC including but not > limited to a Domain > Model and Glossary. Furthermore, Use Cases and Requirements > documents will > share content that is common through normative references. > The XACML TC > shall keep its work consistent with the work of the Security > Services TC by > requesting enhancements to, modifications of, and > cross-references from > Security Services TC documents through a formal liaison with > the Security > Services TC. This liaison will include the regular sharing of > deliverables > and > status reports during teleconferences or at face-to-face meetings. > > -----Original Message----- > From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com] > Sent: Wednesday, June 06, 2001 4:45 PM > To: 'xacml@lists.oasis-open.org' > Subject: RE: XACML TC Charter Revision - Strawman > > > > Here is the revised TC Charter - from the lack of email on this thread > in the past few days, I am assuming that all the comments are > already in. > > Notes: > 1. Changes from previous version: > a) "subject" has been replaced by "target" > b) "CORBA CSIv2" replaced by "LDAP" > 2. Charter is silent on the mechanisms for executing the > policy (PDP and > PEP). > 3. Non-goals of XACML are missing (if any of you want to > take a stab at it, > please do) > > Please send your comments. > > -------------------------------------------------------------- > -------------- > --------------- > > Product of TC > XACML TC will define a core XML schema for representing > entitlement policies, also called XACML > > Policy Target > The target of a policy (hereafter referred to as "target") > can be any object > that can be referenced in XML. > > Protocols and bindings > XACML TC will define new protocols or identify bindings > to existing protocols (e.g., XPath, LDAP) intended as means > of accessing and > communicating the policies > > Scope > XACML is expected to address fine grained control of > authorized activities, the effect of characteristics of > the access requestor, the authorization protocol over > which the request is made, authorization based on classes > of activities, and content introspection (i.e. authorization > based on both the requestor and potentially attribute > values within the target where the values of > the attributes may not be known to the policy writer) > > Extensibility > XACML core schema is extensible for as yet unknown features > > Interoperability > > XACML TC will define interoperability of XACML core schema > with other standards. > > > Simon Blackwell > Suresh Damodaran > Fred Moses >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC