[Odrl-version2] RE: ODRL-Version2 Digest, Vol 10, Issue 2

[Vicky Weissman]

Hi all, 

Just a quick note in response to Alapan's.  Alapan writes: From an
implementation point of view, surely the value of no_copies [an environment
fact] is known to the DRM controller (as it is a required function of a
controller to keep track of state), and if it is not known (maybe because
this is the first time the license has been used for example), then a default
value (0 in this case) should be used?

In response, I don't know what the design criteria is for the DRM controller.
Is this written somewhere and, if so, could you point me to it?  If the
controller really does keep track of the entire state, then we should be able
to assume that the environment is known and a fairly naïve algorithm should
be sufficient to evaluate queries, such as may Alice copy file f.  Put
another way, how I would recommend we evaluate queries, such as may Alice
copy file f, depends on whether we assume the complete state is known (or, at
least, all relevant facts about the state).  So could someone tell me
definitively if we're making this assumption?  

I can't speak with confidence on whether the assumption should be made but,
for what its worth, here are the pros/cons that I see.  A benefit of having
the entire state accessible to the controller is, as I've already mentioned,
that it substantially simplifies the task of answering queries.  One
disadvantage is that the controller has to keep track of the state, which
increases its overhead.  We could address this issue by having the user
submit a request along with all relevant facts needed to get the permission
(think SPKI/SDSI).  This is good, because the controller doesn't have to
store the information, and this is bad because the user needs to know which
documents to submit, the user needs to have these documents (possibly getting
them from third parties, there could be privacy issues here), and there might
be more of a chance for forgery if the user holds the credentials.  This
approach also restricts us to a world where a fact about the environment can
only add to a users set of permissions.  For example, few people will submit
a credential saying "I have a history of not paying my bill".  Obviously, we
could have a split approach where the user keeps some facts as credentials
and others are stored with the controller; thereby, reducing, though not
eliminating, the overhead.   

Another concern has to do with the robustness of the system.  Suppose the
controller is keeping track of the state,  but for some reason this
information is unavailable at the time a request is made (maybe the network
is sluggish, maybe there's a denial of service attack under way, maybe
there's a reason to believe part of the database has been corrupted,...),
then we'd like the controller to function as well as possible.  A similar
argument holds for the poor customer whose system is infected with a nasty
virus that destroys some of her credentials.  Now, if we don't depend on the
state being available, the controller might work better (and, at least, will
not work less well) in these, hopefully atypical, circumstances.  Of course,
it's not clear how much better, so maybe this shouldn't be a significant
concern.

-Vicky