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)
