RE: XACML - Extensible Access Control Markup Language]

Larry makes some very interesting points.  On the subject of any
distinction between XACML and other rights management initiatives in
terms of scope and applicability I would say the following.  A good
number of companies have for many years been in the business of
defining access controls, contractual relationships, intellectual
property boundaries, security mechanisms for distribution channels
(legal and technical), and so on.  The current, fairly widely scoped
aims of certain rights and obligations management initiatives gives us
the opportunity to unite these activities in a mutually compatible set
of machine-processable languages.  The benefits of doing so are
enormous.  If, at this stage, we allow mutual incompatibilities
between standards to evolve, because they are operating in slightly
different, but overlapping spaces then the opportunity is lost.  One
way to achieve compatibility is to encourage cross-standards
participation, awareness, and discussion.  Only time will tell whether
this is achievable.

_ ______________________________________________________________
Dr David J. Parrott (Chartered Engineer) Chief Technology Office
     Reuters Limited, 85 Fleet Street, London EC4P 4AJ, UK.
   Direct Line: +44 (0)20 7542 9830, Fax: +44 (0)20 7542 8314

On 25/04/2001 23:17:45 Rigo Wenning wrote:
> ----- Forwarded message from Larry Gussin <> -----
> Date: Wed, 25 Apr 2001 13:05:50 -0400 (EDT)
> Message-ID: <007501c0cdaa$4991cc00$>
> From: "Larry Gussin" <>
> To: <>
> Subject: [Moderator Action] RE: XACML - Extensible Access Control Markup
> Language
> Hi,
> I believe several worlds are colliding here.
> The XACML press release equates "access control" with "rights management", but

> in scanning the XACML discussions over the last few months
>, I find no mention of
> rights management among over 100 messages - except a brief mid-February query
> about and dismissal of the importance of XRML and Contentguard to what they
> were doing. Nor anything about W3C DRM or MPEG 21. Likewise no mention of
> among W3C DRM folks. (Nevertheless, XACML grows out of IBM, which as a
> corporate entity has been involved in DRM for many years; while Reuters also
> keeping a hand in both places.)
> I'll suggest this distinction, hoping to learn from criticism:
> XACML grows out of an effort to use XML to incrementally extend enterprise
> access control capabilities - primarily server session based - to the current
> Web. It is a response to strong current enterprise markets demand. Its frame
> reference is other XML-based efforts aimed at helping enterprises build out
> their extranets, in part through interoperability.
> (Here, as evidence, is from a Feb. 21 announcement of the XACML discussion
> "The
> scope of discussion is eXtensible Access Control Markup Language (XACML),
> addresses security related specifications orthogonal to the efforts of the
> existing Security Services OASIS TC. Whereas the Security Services TC exists
> define an XML framework for exchanging authentication and authorization
> information, XACML is concerned with the representation of access control
> policies as XML and the application of these policies to XML documents. The
> people requesting the creation of this discussion list have discussed this
> effort with the existing Security Services TC, and that TC agreed that this
> work is best carried out as a separate, though coordinated, effort rather than

> as a part of the Security Services TC.")
> DRM, on the other hand, is accruing a community (eg., AAP, MPEG) intent on
> building pervasive rights management support into an envisioned future Web. It

> is far more philisophical and - in terms of conceived applications - for more
> comprehensive, but it is less tied to existing markets, and therefore perhaps
> less embedded in reality. By reality I would mean: what will be the
> equivalences between addressing logical complexities and addressing real world

> problems?
> Comments?
> Larry Gussin
> ----- End forwarded message -----

        Visit our Internet site at

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

Received on Thursday, 26 April 2001 07:46:21 UTC