Re: [rights] Clarification...

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

Hal writes:
> I have been struggling for weeks now it find some
> distinction (ed: between DRM and access control). First
> of all, consider that unless some work is explicitly
> in the public domain, the act of publication creates
> an implied copyright...

JSE: I think that "implied" is not quite the correct term. For example, under
most law, any fixed creative work (published or not) *is* copyrighted, with
various rights (specified by region) reserved to the creator, unless explicitly
waived....

> ...Therefore, with rare exceptions all content on the WWW,
> for example, is legally a "digital work." Now if I charge
> a subscription to access some data, limit access to people
> who have joined my club, limit access to customers who have
> bought a widget from me, employees who work for me or restrict
> access for any other motive, I do not see the distinction.
> Essentially it boils down to money...

JSE: First, I very much agree with the "digital work" assertion. Now, regarding
what your hypothetical copyright holder is trying to do: It all comes down to
policy expression.

For example, one can think of the attributes that represent the user's
(principal's) status of payment merely as an attribute that distinguishes a
"role," HOWEVER one might wish to overload that term: for example, "member of
the group of people who have paid," "member of an organization which has a
subscription," etc. Any policy enforcement mechanism that has the job of
enforcing access control policies to the object behaviors should NOT (or be able
to...) care whether the applicable policy is payment related, membership-related
or some other role-attribute (and/or environment-attribute) related; it just
needs to know how the policy evaluates. The same holds for the component that
evaluates the policy (which could be part of the same component). Indeed, the
only participant who "knows" is (perhaps) the author of the policy and
(certainly) the authority issuing the attribute, who in the case of
payment-based access would be in cahoots with a transaction system....

BTW (and as an aside) I think it is unnecessary to draw any distinction between
local vs. remote resources, and "information resources" vs. web services...But
that's another thread...8^)

> ...Maybe somebody else can help me here, but the similarity of
> concepts, the form of the language, the stated requiremets
> leave me at a loss as how to draw a line. Are we going to
> say that the distinction arises from the mental state of
> the person creating the policy (license)? This seems unworkable to
> me...

JSE: Given what I just wrote, I can hardly disagree!

EXCEPT for the fact that two "languages" that might APPEAR to occupy the same
space --- i.e., might APPEAR to overlap --- might actually not. If the
distinction was simply a case of vocabulary, one could find equivalence
transforms between the two schema. But it is possible for a given language to
carry complex, typically domain-specific semantics that might not "normalize"
well and accomodate an equivalence transformation...

For example, consider a slightly different (perhaps...) example of an early
rights language, described in April 1993 by Henry Perritt [c.f. Henry H.
Perritt, Jr., "Knowbots, Permissions Headers and Contract Law," presented in
April 1993]. In the pre-dawn of the DRM industry, Prof. Perritt discussed his
concept of "permissions headers," in which rights data structures would be
associated with works distributed in digital form, esp. across networks. His
idea was to attach to every digital work a structure containing the terms under
which the copyright owner made the work available; the document
retrieval/rendering mechanism would then evaluate attributes of the client's
request against the terms of usage as expressed in the "header," subsequently
granting the requested access to the work if appropriate (i.e if there is a
"match").

Perritt definitely saw the header as being attached to and distributed with the
digital work, as part of its structure. He suggested that the structure would
specify to the use-requesting system such permissions as:

(a) an outright transfer of rights,
(b) use privilege: restricted or unrestricted (includes display and
presentation)
(c) copying: unlimited or subject to restrictions, like quantitative limits
(d) distribution: unlimited or subject to restrictions, like geographic ones or
market limitations
(e) preparation of digital works

The structure could be in binary form, like some of the profiles we have
described, but he felt this would be too limiting; rather, he preferred a richer
form of expression that could contain restrictions, pricing information, etc.,
with enough flexibility to accomodate multiple suppliers for the work. Finally,
Perritt's rights expression would contain "pricing terms" --- essentially, the
various acceptable definitions of payment.

Perritt is clearly saw a permissions header as functioning like an "offer," in
the contract sense, travelling with the work. It supplied the policy; it was the
job of some VM on the client machine to evaluate this policy.

My point in describing this in length is to note that a language operating at
this level might require another level of finer-grained policy expression, and
certainly would require a transaction or messaging protocol as well as some
"binding" or enforcement layer. Note that the latter might be come "for free" of
a lower-level policy expression layer was adopted, to "implement" the
higher-level semantic...

> ...Another point made much of in the ContentGuard patents is
> the notion that the usage rights are "attached" to the digital
> work. I understand what it means to attach a handle to a door,
> but what the word "attached" means in this context escapes
> me...

JSE: I will refrain from commenting on specific patent claims --- this is very
dangerous.

It is probably more useful to point out what "attach" commonly means in the DRM
literature. For example, a usage control (UCON) or DRM taxonomy [c.f. Jaehong
Park and Ravi Sandhu, "Security Architectures for Controlled Digital Information
Dissemination"] clearly distinguishes differences in DRM architectures based
upon whether their "control set" is (a) built-in to the DRM VM, (b) *attached*
to the digital work, or (c) issued separately from the work (further distinction
can be made based upon whether a work is received via simple file transfer or
through server-controlled means, such as streaming). We see examples of any and
all of these in DRM today; obviously, not branches of the DRM taxonomy are
suitable for widespread use. How the control set is distributed directly
determines the ability of the "originator" to control usage. Modern DRM
architectures use the detached form to provide maximum flexiblity, including
regular distribution of revocation lists (for usage rights as well as rendering
components), etc.

The point is that there is a distinct branch of the DRM taxonomy in which the
control set --- the usage rules --- are attached to the work (whether downloaded
or streamed), and a separate branch where the control set is shipped separately.
In collecting our requirements, we will need to distinguish what branches of the
DRM our specification should accomodate.

> ...Does it mean they are on the same system? in the same file?
> that the right "names" the work? that they cryptographically
> bound together? that the rights move around the network with
> the work?

JSE: Again, commenting *only* on the DRM taxonomy, "attached" means part of the
structure, regardless of the format of that attachment. The case in which the
control set is separately issued --- the common model by today's commercial
standards (See Rosenblatt) --- is a different branch.

I should mention in passing that this does not preclude the case of a
separately-issued rights specification overriding previously attached rights ---
this is a case I wrote about in 1994-95, where "minimum permissions" (e.g. "read
only") might be shipped *with* the work, giving limited usage, and "auxiliary
permissions" ("print") could be requested/transacted by individual users.

> ...The last seems like a possible distinction, but merely an
> implementation optimization...

JSE: If you mean "DRM can be distinguished by rights being attached to the
work," then *no*, this is not acceptable. But I should let you continue...8^)

> ...It seems hard to credit that if I were to send the rights
> (policies) in a different message from the work (content)
> that I would be doing access control, whereas if I sent them
> in the same message I am doing DRM. Makes me think of the Kosher
> practice of never letting the milk touch the meat...

JSE: Right --- this is a poor way to distinguish between DRM and access control!

The term "digital rights management" was coined by the emergent industry in the
late 1990's because the language that most of us used in the mid-90's to
discribe what we were using was painful and cumbersome: terms like "networked
copyright management," etc. What we old DRM farts *meant* was one or more of (a)
providing general copyright information, (b) providing specific T&C information
for a particular use or set of uses, (c) providing mechanisms for usage-based
rights acquisition, and (d) providing access control to certain and specific
usages.

BTW, not all writers have adopted the term; arguably, for good reason, because
it can represent so many things...

> ...It appears to me that access control and DRM are simply two
> historically distinct (and actually very similar) ways of
> looking at the same problem...

JSE: Arguably, DRM never would have emerged as a distinct "field" had certain
distributed object models (e.g. OpenDoc, perhaps CORBA) become more widely
adopted (and the mechanisms naturally built-in). But they didn't; flat content
prevailed, and thus it was necessary to figure out a way to provide fine-grained
control access to the content, independently of both the (a) system, and (b)
client software.

Policy enforcement for content usage is different, even though the policy
expression, management and decision process SHOULD be the same...

> Can anyone draw a sharp distinction between these two?

JSE: Hopefully I've done *something*, one way or the other...

> I am going to submit the XACML usecases and requirements to the
> Requirements SC. Perhaps someone will be able to tell me which
> requirements do not apply and why.

JSE: That would be useful...

| John S. Erickson, Ph.D.
| Hewlett-Packard Laboratories
| PO Box 1158, Norwich, Vermont USA 05055
| 802-649-1683 (vox) 802-371-9796 (cell) 802-649-1695 (fax)
| john_erickson@hpl.hp.com         AIM/YIM/MSN: olyerickson