[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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