RE: new OASIS discussion list : XACML

["Simon Y. Blackwell" <sblackwell@psoom.com>]

Although the task of the preliminary XACML discussion is to frame the
context of XACML, I think it safe to say:

1. The XACML folks would agree with Bob about what XACML is and isn't with
respect to subject control.
2. The XACML folks are just as concerned with fragmentation of efforts as
both Bob and Nigel. It is just that we need to move forward more rapidly in
the area that SAML is not currently focussed on. I can imagine the converse
conversation to that we are having if XACML had started first. I do not see
any logical dependencies that require doing one before the other. The
current objections seem to be primarily resource driven. Those folks
interested in XACML or SAML-AC, if you like, will have to make time for both
or trust that there are equally capable folks working both sides of the
issue. Remember we do intend to reconvene with the security services TC
prior to making a decision about creating an XACML TC.
3. We will make sure that whatever work XACML does independent of SAML is
consistent with SAML. I really dislike name and semantic space divergence.
Although mappings are frequently possible between separate XML initiatives,
in my opinion, divergence severley hampers adoption, interoperability with
yet other standards, increases opportunity for buggy software, etc. In
short, divergent efforts are economically a bad idea.

-----Original Message-----
From: George_Robert_Blakley_III@tivoli.com
[mailto:George_Robert_Blakley_III@tivoli.com]
Sent: Friday, February 23, 2001 3:05 PM
To: Edwards, Nigel
Cc: security-services@lists.oasis-open.org
Subject: RE: new OASIS discussion list : XACML


Nigel,

>I do not see how to separate "an XML framework for exchanging
>authentication and authorization information (SAML)" and "the
>representation of access control policies as XML". It seems to me that
>the later is a subset of the former.

I disagree.  I think security assertions are (in the language of ISO
10181-3)
subject control attributes, where as access control policies are just that
--
access control policies.  There is also such a thing as a target control
attribute
(e.g. a sensitivity label).  I don't think that any input document to
SAML defines either access control policies or target control attributes,
and I don't think that the document we finally produce SHOULD define either
of these.

I can imagine a spec. which would define either or both of these other
things,
and I think that XACML is targeted at defining an XML format for access
control
policies together with a way to associate them with the documents they
govern.

>Whilst I think it is important to have a way to represent access
>control policies as XML, I do not see that separating out the latter
>effort from SAML will benefit either the industry or the wider
>community.  It will make coordination of the work harder and further
>stretch the people working in the area. Many of the people working on
>SAML would want to be involved and have much relevant technical and
>business experience to offer. Conducting the efforts in parallel will
>make it difficult for these people to participate in both efforts
>adequately.  This increases the probability of inconsistencies between
>the two efforts.

I agree with this as I said on the phone.

>I also believe having two specifications which are closely related
>will increase the probability of confusion in the minds of the
>specification consumer (which one do they use for what). This is
>likely to cause fragmentation which will reduce the adoption and
>ultimate impact of both efforts.

I don't really have an opinion on this.  The average specification consumer
is a fairly senior software designer or programmer, and shouldn't be easily
confused.

--bob

Bob Blakley
Chief Scientist
Enterprise Solutions Unit
Tivoli Systems, Inc. (an IBM Company)


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: security-services-request@lists.oasis-open.org