RE: XACML & Digital Rights

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

 Dave,

I am very grateful I am for your input to the XACML process. I think you and
I are in exactly the same camp. Much of what I said is in the nature of
observation about what I see folks doing and publishing rather than what I
think should be the case. I think one of the major problems we are all
facing is that access control, DRM, policy, etc. are all loaded terms.

To answer your question, I do think that access control could be a subset of
a complete DRM solution. 

I'm actually on vacation, so that's all for now...

Simon 

-----Original Message-----
From: David.Parrott@reuters.com
To: 'xacml@lists.oasis-open.org'
Sent: 7/5/01 6:58 AM
Subject: Re: XACML & Digital Rights


On 04/07/2001 17:15:40 "Simon Y. Blackwell" wrote:
> During the conference call last week there was some discussion of the
> distinctions between what we are doing with XACML and digital rights.
> Several folks see them as very distinct, others see them as quite
similar.

I'll declare my hand and say that I'm in the latter camp
(that'll become obvious anyway :-)

> Here are some comments to get discussion rolling.
> Consider the two expressions below:
> 1. If <conditions> then <grant rights>
> 2. If <exercise rights> then <do transaction>
> It seems that 1 is squarely in the realm of XACML; whereas 2 might not
be. I
> also seems that both 1 and 2 are relevant to DRM.

Does this mean that the aims of XACML can be achieved with a
well-defined, self-contained subset of a DRM markup language?
I would hope so, because one of my goals for the likes of
MPEG-21's rights markup language is to be able to use it as a
policy language for driving the permissioning and access control
settings of an endless variety of enforcement mechanisms.  As I
see it, the access control layers on RDBMSs, subscription Web
sites, file systems, VPNs, workflow systems, document management
systems, directories, etc, etc can all be considered implementations
of rights enforcement engines.

> A more general expression:
> 3. If <conditions> then <do action>
> is probably required for QOS representation.
> Note however, XACL (not a typo) provides for arbitrary transactions as
a
> side effect of evaluation or as a result of exercising a right.

I've included all the above in requirements for various DRM languages.


> It also seems that XACML may have extensive focus on conditions and
> granularity; limited but perhaps extensible rights, e.g. read, write,
> execute; a focus on digital works and services and perhaps even
non-digital
> entities.

Sure.  And so should any half-decent DRM language.


> Whereas, DRM seems to have a limited focus on conditions and
granularity;
> extensive focus on rights, e.g. read, write, play/render, transfer,
> transport, modify rights; a primary focus on digital works; and rights
> provision at time of creation or publication, i.e. more static than
XACML.

No.  There is no suggestion that DRM languages imply static mappings
One of my contributions to the MPEG requirements states explicitly that
DRM languages must be able to support dynamic expressions which
can be instantiated at access time, not publication or creation time.
Moreover, it is important that the details of expressions can be hidden
from the user (because they may contain sensitive information).
Therefore
it must be possible for access controls to be determined dynamically by,
for example, Web services.  The DRM language expression feeds directly
into the dynamic service (or can be fetched by the service)
independently
of the content/electronic interface and its user.

Additionally, even if expressions are issued in a static manner, there
is
a requirement for them to be validated dynamically and updated
dynamically.
DRM is in no way a static domain.

I'm not sure I understand the granularity argument.  In a DRM system, I
would want to be able to express controls over any level of granularity
demanded by my application.  If that means controlling access over
individual bits, or tiny fragments of a transactional workflow, then the
DRM language should make provision for that.  As for limited focus on
conditions; again I'm not sure I get the argument.  Does anyone have
any concrete examples for a condition that a DRM language would not
want to represent but which XACML would?

/Dave.
_ ______________________________________________________________
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
       Email: David.Parrott@reuters.com, dparrott@acm.org





-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

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.