RE: [rights-examples] ln00x use case discussion

rights-examples message

>                <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.)

-----Original Message-----
From: DeMartini, Thomas [mailto:Thomas.DeMartini@CONTENTGUARD.COM]
Sent: Thursday, July 11, 2002 9:52 PM
To: 'DuCharme, Bob (LNG)'; DeMartini, Thomas; 'rights-examples@lists.oasis-open.org'
Subject: RE: [rights-examples] ln00x use case discussion

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:

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>

                <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.