RE: [rights-examples] ln00x use case discussion

["DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>]

Title: RE: [rights-examples] ln00x use case discussion

Something you said (about not being interested in assigning people to classes) made me wonder if we each are talking about the same thing when we say principalClass.  There are at least two kinds of principal classes I can envision.  One I will call a principal "role"; the other, a principal "assignment".  I don't really want to debate the terms "role" and "assignment" (and if they get in the way, lets use "foo" and "bar"), but my goal is to provide a framework for distinguishing between at least two of the interpretations I have in my head for "class".

Lets take principal "role" first.  This is something that "falls out" from principal interaction rather than being something written down.  For instance, I am a speaker when I speak, a writer when I write, a consumer when I consume, and a distributor when I distribute.

Principal "assignment", on the other hand, is something that is "assigned" to some principal by some other principal for some (possibly arbitrary) reason.  For instance, when I see a farmer farm, I may assign him to the group of "farmers".  Another person may assign people to the group of "farmers" based upon seeing a title showing the person's ownership of farm land.  A person may get the assignment "author of Great Expectations" by showing the same to a publisher who trusts him and getting his name on it during publication.  A person may get the assignment "sir" by being bestowed it by some royalty.  Numerous other assignments are possible: subscriber, employee, student, "platinum club member", "economy class", adult, "legal consumer", individual, business, citizen, and so on.

Now lets analyze the reason I make this distinction.  If http://www.lexisnexis.com/whatever/c10012 is a principal "role" (as defined above), for, say, consumer, then it means "any principal who consumes".  Suppose we have a way to say this, then a pseudo-grant might look like this:

<grant>
        <any principal who consumes/>
        <consume/>
        <theText/>
</grant>

(any principal who consumes can consume the text) which is actually the same as this:

<grant>
        <any principal/>
        <consume/>
        <theText/>
</grant>

(any principal can consume the text).  In other words, because "roles", by definition, "fall out" of interactions, we need only specify the rights to be given.  For instance:

<grant>
        <distributor/>
        <issue/>
        <grant>
                <any principal/>
                <consume/>
                <theText/>
        </grant>
</grant>

can equally well be read as "the distributor can issue a grant saying anyone can consume the text" or "the distributor can issue a grant saying any consumer can consume the text" because, by definition, any principal exercising the consume right will be in the consumer principal "role".

On the other hand, lets us investigate principal "assignments".  To be parallel with the preceeding example, think of "authorized consumer" or "platinum member".  In the case of principal "assignments" there is a very big difference between saying

<grant>
        <any principal/>
        <consume/>
        <theText/>
</grant>

(any principal can consume the text) and saying

<grant>
        <any principal who is a platinum member/>
        <consume/>
        <theText/>
</grant>

(any platinum member can consume the text).  The status of platinum membership does not fall out of the act of consuming.  Rather, the status of platinum membership is "assigned" to certain principals.  In this case, it is of utmost importance for the clarity of granted rights that the granter cares about how principals get "assigned" the status of platinum membership.  For instance, does the distributor do it?  a trusted third party?  the author?  some guy out of his garage?

&Thomas.

-----Original Message-----
From: DuCharme, Bob (LNG) [mailto:bob.ducharme@lexisnexis.com]
Sent: Tuesday, July 02, 2002 12:26 PM
To: 'rights-examples@lists.oasis-open.org'
Subject: RE: [rights-examples] ln00x use case discussion

(I attempted to quote the last one as concisely as possible to give context
to my comments without making this too long. ">>" starts my original
questions and ">" Thomas's responses.)

>>1. (Use case ln001). If I want to say that all customers of customer
>>class c10012 may have a particular right, what's the best way to do
>>this? The XrML idea of the principal, according to the technical
>>overview, "must be resolved to a single party."

>Actually, you might read that as "single party of 4" or something like
>that.  The singleness of the party is only in that using the
>authentication means of the principal the computer cannot distinguish
>the party from the party.  For instance, if the party is username
>bobducharme@lexisnexis.com, that is a "single party" as far as the
>computer can tell.  If you share your password with three different
>people, that is still one party.  Four people, but one party.  Kinda
>weird, but the only way it works. 

>>Isn't there something more

>(you mean less?)

>>general than Property but less

>(you mean more?)

>>general than coupling possessProperty with something we make up
>>ourselves to express this?

No, I meant more general than Property when I thought that "party" referred
to a specific person and I wanted to assign rights to a class of people. I
wanted something less general than coupling posessProperty with something we
make up ourselves because the ability to make up something on your own and
plug it in is a pretty generalized solution, and I wanted something more
specific.

>Actually, the cool thing about possessProperty is that it works using
>the XrML notion of equality.  What this means is that you can have an
>implementation (that knows nothing about what foo:customerClass=c10012
>means (and might have even been written years before foo:customerClass
>was invented)) still be able to successfully process those licenses by
>using other possessProperty licenses which bind certain principals to
>that class.
>
>Or maybe you are getting at the fact that it is perhaps a pain to
>write and propogate (probably the bigger headache) a schema for each
>person who wants to do something like customer class.  There have been
>several attempts at defining a generic property such as securityLevel
>and group and subscription and etc, but none seem to be truly generic.
>One thing we might try is some sx:class of type xsd:anyURI. 

Or sx:principalClass to represent a class of principals.

>This way
>you can assign people to certain classes using the class element and
>all you have to really do is come up with a URI to indicate your
>class.  ?

e.g. http://www.lexisnexis.com/whatever/c10012, I suppose. I'm actually not
interested in assigning people to classes. When a content provider sends
something to an aggregator (the situation for which we need a DRM language)
specific individual users are not an issue; classes of users are. Perhaps
this ability should shake out as a new requirement for the spec.