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: RE: XACML TC Charter Revision - Strawman


As I understand it, SAML currently has Subject X Object with various
subcomponents under each. The most important thing is for XACML NOT to use
Subject as in the first draft (Policy Subject). That would be extremely
confusing. 

I am happy with Target or Resource and could even live with Object. Target
seems a little more general and abstract, and is therefore is my preference.
For example, consider a QoS scenario. The thing being protected is not so
much the resource, as the attributes of its use.

I have argued in another message that I think the two high level categories
are not Subject and Object, but Evidence (the inputs to policy evaluation)
and Resource (Target). I see Subject as one (very important) kind of
evidence, rather than a fundamental category. Similarly, Target is likely to
have sub components, such as Object, Action, Signature, Inputs, etc.

I agree that we will have to define some kind of superset policy model that
covers not necessarily all theoretically possible models, but all models of
practical interest to the constituencies we represent.

Hal

> -----Original Message-----
> From: Pilz, Gilbert [mailto:gpilz@jamcracker.com]
> Sent: Thursday, June 07, 2001 9: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