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 . . .