Title: RE: [rights-examples] ln00x use case discussion
>
<proposed:principalClass>
>
http://www.foo.com/platinumMember
>
</proposed:principalClass>
Does the "proposed" namespace prefix
reference a namespace that I'd have to make
up, or does it already exist, or as I'm
guessing from its name, is it something that you're suggesting may be worth
requesting in the spec to address this issue?
(By the way, this is an issue for the
spec committee: in all the ContentGuard-produced documentation I've seen,
namespaces are referenced all over the place without ever being
declared, with two serious consequences: 1.
none of the examples in a document
like ExampleUseCase.pdf are schema-valid,
and 2. someone new to XrML reading one of the documents has no way of knowing
where the various element type names are coming from. Not showing
the declarations in every example is
one thing, but not showing them anywhere--the string "xmlns" doesn't show up
once in the PDF file--makes everything much harder to follow.)
thanks,
Bob
-----Original Message-----
From: DeMartini, Thomas
[mailto:]
Sent: Thursday, July 11,
2002 9:52 PM
To: 'DuCharme, Bob (LNG)'; DeMartini, Thomas;
''
Subject: RE: [rights-examples]
ln00x use case discussion
[DuCharme, Bob (LNG)] (some deleted)
[TD]
The general concept (other than "pattern" in general) we're
working with here when we talk about "platinum member" is the concept of a
"principal pattern" (note: if you look this up in the spec, look under
PrincipalPatternAbstract as PrincipalPattern also exists but is something quite
different). PrincipalPatternAbstract is pretty abstract, as the name
implies, and almost anything can be put there. Of course the choice you
make will impact how much interoperability you get. The simplest, most
English-readable representation of platinum member could be this:
<forAll varName="x">
<myExt:platinumMemberPattern/>
</forAll>
where myExt:platinumMemberPattern is a substitution of
principalPatternAbstract that indicates all principals who are platinum
members. If all systems (and their components) who you want to encounter
licenses written like this can be expected to understand
myExt:platinumMemberPattern, this is probably sufficient.
However, as some such systems will likely desire to make use of
general-use components (which don't understand myExt:platinumMemberPattern), a
more general solution might be desirable. There is a special principal
pattern called "everyone", which doesn't actually mean *everyone*: it means
*everyone who has a certain property*. This would look as
follows:
<forAll varName="x">
<everyone>
<proposed:principalClass>
http://www.foo.com/platinumMember
</proposed:principalClass>
<trustedIssuer>
...key that must certify
principals in that class...
</trustedIssuer>
</everyone>
</forAll>
In this case, the property is
<proposed:principalClass>
http://www.foo.com/platinumMember
</proposed:principalClass>
Now, the way this works is when someone pays, say, $50 for a
platinum membership for the month of July, they get a reciept or a certificate,
if you will, that looks like this:
<grant>
<personWhoJustPaidMoney/>
<possessProperty/>
<proposed:principalClass>
http://www.foo.com/platinumMember
</proposed:principalClass>
<validityInterval>
<notBefore>2002-07-01T00:00:00</notBefore>
<notAfter>2002-08-01T00:00:00</notAfter>
</validityInterval>
</grant>
-Signed by the key that certifies platinum members.
This way, the <personWhoJustPaidMoney/> will match the
"everyone" pattern and get bound to the "x" variable during the month of July,
thus entitling them to, for instance, see any content appearing in grants with
that everyone pattern. For instance:
<grant>
<forAll
varName="x">
<everyone>
<proposed:principalClass>
http://www.foo.com/platinumMember
</proposed:principalClass>
<trustedIssuer>
...key that must certify
principals in that class...
</trustedIssuer>
</everyone>
</forAll>
<principal varRef="x"/>
<mx:play/>
<TheMatrix/>
</grant>
Thus, during July, <personWhoJustPaidMoney/> will be able
to watch <TheMatrix/> because they are a platinum member.
So, so far we have seen two kinds of principal patterns: a very
more-than-domain-specific one (myExt:platinumMemberPattern) and a very general
one (everyone). There could also be ones that are say x509-specific so
that any principal with certain x509 certs could be grouped. These aren't
as generic as everyone, but they would have a good chance of being widely
accepted as well.
This same concept of platinum membership can be extended to
pretty much all "assigned" principals, including site licenses. However,
site licenses are kinda peculiar in that there have been lots of different
"kinds" of site licenses in the past and more that people are interested in the
future. Certainly one big class of these is exactly that class of
"assigned" principals to which the entire discussion above about "platinum
members" applies. (The only difference might be, for instance, that
instead of the provider giving out platinum member certificates when they get
paid, the domain owner would give out 'site member' certificates to site members
as their site grows and changes. This is just a matter of using a
different key.)
Anyway, the reason I bring this up is there are some additional
noteworthy site license models. One in particular is the model where it
doesn't matter so much as to what site you belong as to the fact that you be
*in* a domain while you use the content. Here, a territory restriction
might be more appropriate using the <domain> part of the territory
condition (and not restricting the principal at all).
Another model is the model where you the site administrator
doesn't want the rights subsystem to have any idea who are members of the site
or even how many (for instance, undercover CIA or something). In this
case, you can do something like I mentioned before with "party of 4" or "party
of n". That is, you have one principal that is the "site principal"
specifically set up for the license and the password or secret to "log in" as
that principal is shared among an entire site.
Another model which is quite popular in software site licenses
is the "5-seat" license or something like that. In that case, you might
couple up one of the "assigned" principal models with a concurrency tracking
module controlled by the licenses writer. Or, if there are privacy
concerns about tracking, you might have the site run its own "seating" server
that takes care of both concurrency and site-membership at the same
time.
Thanks,
Thomas.
