OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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)



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC