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

[John Erickson <john_erickson@hplb.hpl.hp.com>]

Hal asks:

> 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?

JSE: See http://www.w3.org/2000/12/drm-ws/pp/hp-erickson.html

John Erickson et.al., "Principles for Standardization and Interoperability in
Web-based Digital Rights Management." Position Paper for the 2001 W3C Digital
Rights Management Workshop, Sophia Antipolis, France (January 2001).

Note that my mates and I tried to do a lot with that document, perhaps too much
for a single document. We used as a focus of discussion something I coined
"PREP" (Policy and Rights Expression Platform), which was meant to be analogous
to (the original proposal for) P3P. It was an attempt to push forward a model
for DRM standardization while being consistent with the stated design goals of
the web. Not easy, but also not impossible...

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

Certainly. Which is all the more reason that there is a strong basis to talk
about a multi-leveled DRM standardization framework...

> (Good PEP, PDP and PAP stuff deleted)...

>> 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.

JSE: That's doesn't mean that it shouldn't be there...

> > * 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?

JSE: Probably not, but we should and will...

> > * 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...

JSE: I agree that e-Contracts are out-of-scope --- I went on to say this!

I disagree that the "current scope" of the rights language needs to be a
"take-it-or-leave-it" expression of 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.

JSE: We pretty-much agree to this in the charter...

>> 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...

JSE: Nothing...I mis-spoke above...

>> 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.

JSE: We aren't talking about XrML --- we are talking about the work product of
the RLTC. The design goals and scope might be somewhat different...

>> 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?

JSE: For one thing, as far is DRM is concerned, "code is law." Which is the
concern! Without *explicit* recognition of and provisions for what the law
provides, it is not a given that the user will be able to enjoy what the law
provides them.

In the case of something like fair use, some scholars have pondered a compromise
that includes requests --- claims, really --- being made to (and usage rights
being issued by) an independent rights escrow service. This will require a much
more expressive rights language than currently proposed with XrML 2.1, in
particular to communicate (probably) details of intended use --- rich context.
And that rich context might include legal context....

>> 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?

By "system" I really meant the assumed DRM reference model. What I was getting
at was that, in the abstract, there must be a messaging protocol; messages that
(in part) define that protocol include declarations based upon the rights
expression language. Today, such protocols are proprietary --- in some cases,
they consist of proprietary message formats carried by standardized web service
protocols; in other cases these protocols are totally proprietary.

Currently our RL discussion has not included all of the vocabularies that may be
required for other messages within rights transactions, including rich rights
requests.

John