[rights-requirements] Summary of conference call on expressiveness ofXrM

Folks,

Deirdre Mulligan, Dean Rowan, Aaron Burstein, John Erickson and I held a conference call last Friday to discuss further the issues we had raised during the Requirements SC conference call about the mathematical expressiveness of XrML. This mail contains a summary of that call and two recommendations resulting from it that I wish to present to the Requirements SC.

We began the call by describing our approaches to creating security standards. I said that in the past when I have worked on security standards that have both common and domain-specific elements I tend to start with a mathematical model for the underlying system, define an expression of that model in some serialization format (call this the "base language"), and then use that base language to write domain-specific expressions. There's a feedback process whereby the ability (or lack thereof) to express something in a particular domain may indicate changes need to be made in the base mathematical model & expression language (one domain may raise an issue, and if it is applicable to many domains then you’d solve the issue by making changes to the base, otherwise you might address the issue only in the relevant domains), but that base language is always kept in sync with the underlying mathematical model.

Deirdre said that she tends to approach these problems in the other direction; namely starting with a series of (domain-specific) use cases, modeling these particular use cases in a language, and then generalizing from those domain-specific expressions into a generalized form. There's feedback in this approach, too -- when creating the generalized form, the generalization will often lead to changes in the domain-specific solutions.

We agreed that both approach have merit and that the RTLC would benefit from work in "both directions" simultaneously. That is, we see value in validating the expressiveness of XrML using both mathematical models as well as domain-specific use cases as bases, with feedback going in both directions.

As an example of the usefulness of the use case approach, Deirdre, Aaron & Dean sent me the attached document describing what they saw as a flaw in the current specification regarding revocation. As you can see, based on their use case analysis of a demo "first sale doctrine" scenario, it appears that the specification that a license issuer always holds implicit revocation rights over issued licenses conflicts with the expression of "first sale doctrine" rules. I believe that the doc is correct: there is indeed a need for clarification in the spec regarding the specification of revocation rights, but I think that can be fixed pretty easily. I think the intent of the language was to say something along the lines of, "Absent an expressed grant of revocation rights from the issuer, the issuer is the only party with even the capability to revoke a license." In my opinion, what we need to do is make clear that a license issuer must take some action at license issuance time to indicate that he wishes to reserve revocation rights over the license. That is, an issuer needs to do something like (a) populate a field in the license with revocation-related data, or (b) put some sort of condition or other data in the license to indicate that the license is subject to possible revocation. Absent this statement/information the license would be irrevocable. (I further believe that it'll be sufficient to say that the Issuer/details/revocationMechanism element is populated in order to indicate the reservation of revocation rights, but that's something we'll address as a change request through the normal TC process.)

Beyond this particular example, Deirdre and I both believe that as part of the RLTC's output we need to provide guidance to extension authors and implementers of the RLTC specification regarding how to build RLTC-based system that properly consider the rights of all parties in a transaction. For example, we agree that in a DRM-type system there needs to be representation of rights/authorizations that a content owner is automatically granted by law, such as "fair use" & "first sale doctrine" rights. Deirdre & I believe that because "fair use" itself is a fuzzy term in copyright law it's not possible to model "fair use" with 100% accuracy in any expression language, but we think that it would be possible to model a worthwhile percentage of "fair use" rights and create what I'd call a "first-order approximation" to "fair use". Obviously this is a domain-specific task, but the RLTC needs to point out this issue to folks who will build on top of our spec and provide guidance.

I believe that the way to provide this guidance on the need to consider all parties in a transaction in the RLTC is to make it part of the output of the Extensions & Process SC. The documents produced by the Extensions & Process SC should include a section (or an entire doc) that provides guidance and direction on how to think about modeling these sorts of real-world processes to implementers.

So, there are two action items I recommend to the group:

1) We need a change request to clarify the language in the spec around revocation. I will take the action item to author this.

2) We need to direct the Extensions & Process SC to include in their output the guidance described above.

--bal

rights-requirements message