[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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, firstname.lastname@example.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.
Powered by eList eXpress LLC