RE: [rights-requirements] FW: Rights Requirements Submission

[Hal Lockhart <hal.lockhart@entegrity.com>]

Title: RE: [rights-requirements] FW: Rights Requirements Submission

> John Erickson wrote:

> As I pointed out at the W3C workshop, we should assume a
> context or general DRM
> reference model that would define open interfaces between
> three architectural
> levels of abstraction: rights expression languages, rights
> messaging protocols
> and mechanisms for policy enforcement and compliance.

I am not a member of the W3C. Is the material from this workshop publically available somewhere? If not, could you at least post your paper to one of the OASIS lists?

Your reference model is in complete accord with the SAML/XACML Domain Model (which we stole from the IETF and ISO).

A Policy Enforcement Point (PEP) is responsible for enforcing Authorization policy decisions.

A Policy Decision Point (PDP) is responsible for understanding and evaluating some expression of Authorization Policy (Digital Rights in this case).

A Policy Administration Point (PAP) is responsible for creating expressions of Authorization policy.

(Don't blame me for the terms, I didn't make them up ;-)

A variety of means, both in band (with the data) and out of band (private channel) can be used to communicate policy expressions from a PAP to a PDP and policy decisions from a PDP to a PEP. In addition, these entities can be implemented as closely coupled entities, however in this case the issue of standardization may not arise.

> Within that context, rights expression languages should
> provide the basis for
> expressing rights information and policies, and as such are
> useful for a variety
> of rights messaging applications including
>
> * Rights information discovery

I don't see any support for this in XrML.

> * Simple policy expression
> * Rights negotiation and trading --- offer discovery, presentation and
> acceptance (AKA making a rights request)

Nor for this one. Did I miss something? Do we have usecases and requirments covering these?

> * The expression of rights agreements and electronic
> contracts (e-Contracts)

I don't know enough about e-Contracts to agree or disagree, but my impression is that this is a much larger scope than the submission we are working from. As I understand it, the current scope is pretty much a take it or leave it policy.

 
> Minimally, a rights language must provide the vocabulary and
> syntax for the
> declarative expression of rights and rights restrictions. In
> order to guarantee
> interoperability and evolvability, we would also expect a
> rights language to be
> inherently extensible: it must provide an open-ended way to
> express rights not
> anticipated by the language "core." Such extensions might
> include new operations
> on content or new contextual constraints...

Can't disagree with any of this.
 
> Clearly, rights languages should not be thought of as
> e-Contract languages.

Hold on a minute. Aren't you contradicting what you said above? Tell me what I am missing.

> First, this is obvious because the domain of a rights
> language should also
> include the vocabulary for expressing offers and requests.

I don't think you should assume any aspect of this is obvious to me ;-). However, as noted this does not seem to be part of XrML, so I feel vindicated in my confusion.

 
> Secondly, the rights
> specifications contained within rights packages are not
> e-Contracts! It is clear
> that one possible use of a rights language is to express the
> parties, terms,
> rights and obligations typically enumerated in e-Contracts.
> [c.f. FIRM] However,
> e-Contracts go beyond the immediate scope of rights languages
> (and, arguable,
> DRM in general) since they require complex, dynamic behavior, not just
> declarative expression of state.

A couple of examples would help here.

> Note: The rights specification created by a rights expression
> language and
> contained within in a license package can be thought of as a
> manifestation of an
> e-Contract, held and maintained by some license server and
> generated based upon
> a specific context of use. Such e-Contracts are reifications
> of usage licenses.

If you are saying that a contract must consist of offer and acceptance, I am with you, but you mean more than that I could use some concrete examples.

> On the issue of representing principles of copyright law
> (e.g. fair use), I
> believe that this *does* belong in the domain of the rights
> language. As I
> suggested in last week's call, this is part of the context of
> the rights *claim"
> that the user is making when they make a so-called "rights
> request," and this is
> precisely at the semantic level of the rights expression language.

See my other email to Patrick Durusau. Why does the language have to express things that are always true? Or are there cases when they are not?

> It also impacts on the so-called "system," because we also
> require an extensible
> rights messaging protocol to enable this level of expressiveness...

Lost me here. What do you mean by "system". PEP + PDP? Language syntax and semantics?

Hal