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


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