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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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