OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

rights-examples message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


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

[BD]

(First, in response to another message you sent)

>Another interesting thing people have proposed (that you might be
>interested in) is the use of "resource classes".  In this instance,
>each resource indicates which resource class they are in.  Licenses
>are then written for "any resource" in a specific class.  In essence,
>the licenseId approach is an example of a resource class approach
>where the resource classes are defined by a particular license id.
>You can expand this, though, to make a generic resource class id with
>the advantage being that you can later issue new licenses refering to
>that generic resource class without having to go find each resource
>and update it to include the new license id.  The way you would do
>this is similar to the example above but with a couple words after
>mySystem changed.

Yes, this sounds like a good fit for some of the scenarios I have in mind. Where can I find out more?

[TD]

Well, the way I hinted at above would look something like this:

<grant>
        <forAll varName="content">
                <mySystem:contentOfClass method="contentHeader" class="http://www.lexisnexis.com/whatever/blues"/>
        </forAll>
        <dcx:play/>
        <resource varRef="content"/>
        <sx:territory>
                <sx:location>
                        <sx:country>US</sx:country>
                </sx:location>
                <sx:location>
                        <sx:country>CA</sx:country>
                </sx:location>
                <sx:location>
                        <sx:country>MX</sx:country>
                </sx:location>
        </sx:territory>
</grant>

If, however, you prefer the condition style of class expression, the following grant expresses the same thing:

<grant>
        <forAll varName="content"/>
        <dcx:play/>
        <resource varRef="content"/>
        <allConditions>
                <mySystem:contentClass method="contentHeader">
                        <resource varRef="content"/>
                        <class>http://www.lexisnexis.com/whatever/blues</class>
                </mySystem:contentClass>
                <sx:territory>
                        <sx:location>
                                <sx:country>US</sx:country>
                        </sx:location>
                        <sx:location>
                                <sx:country>CA</sx:country>
                        </sx:location>
                        <sx:location>
                                <sx:country>MX</sx:country>
                        </sx:location>
                </sx:territory>
        </allConditions>
</grant>

MPEG has a variation of this that it uses, but instead of using a content header to store the classification information, it stores it in the Digital Item Declaration (which you can think of as a header of sorts, but it isn't strictly a header).  Anyway, if you were using that, it'd look something like this:

<grant>
        <forAll varName="content"/>
        <mx:play/>
        <diReference varRef="content"/>
        <allConditions>
                <mx:diCriteria>
                        <mx:diReference varRef="content"/>
                        <xmlExpression>
                                didl:Descriptor/
                                didl:Statement/
                                myMetadataScheme:genre = "blues"
                        </xmlExpression>
                </mx:diCriteria>
                <sx:territory>
                        <sx:location>
                                <sx:country>US</sx:country>
                        </sx:location>
                        <sx:location>
                                <sx:country>CA</sx:country>
                        </sx:location>
                        <sx:location>
                                <sx:country>MX</sx:country>
                        </sx:location>
                </sx:territory>
        </allConditions>
</grant>

In the above grant, you look at the digital item declaration of the digital item in question and run the XPath over that declaration to see if you have a match or not.  In this case, we are checking if the digital item has a descriptor containing a myMetadataScheme metadata with a genre element and if that genre element is "blues".  An example of a declaration for a digital item you could play with the above grant is this:

<DIDL>
        <Item>
                <Descriptor>
                        <Statement>
                                <myMetadataScheme:genre>blues</myMetadataScheme:genre>
                        </Statement>
                </Descriptor>
                <Component>
                        ...
                </Component>
        </Item>
</DIDL>

You can also do the same thing with non-genre classes.  For instance, premium content, video vs audio content, etc. -- essentially, anything you have a metadata scheme to describe.

NB: More typically, your digital item declarations would contain full metadata statement descriptors in a particular metadata scheme.  This wouldn't change much except the XPath you use in the licenses will be a little longer to select the thing you want, but you also have the ability to chose based on a lot richer metadata.

[BD]

(In response to what you wrote below)

Your concept of assignment definitely comes closer to what I had in mind than your concept of role. "Platinum member" is a good example, to represent "any customer who has paid for a particular plan." (As with DirectTV--my family has access to the Boomerang channel because we pay for the Premium Plus plan; when we were on the Premium plan, we didn't, and couldn't watch Droopy Dog, Huckleberry Hound, etc.)

In addition to "all customers who paid for a certain plan," customer class "c10012" could also represent "all customers accessing our system from a particular domain." A corporate client such as a law firm may have worked out a site license deal, and we know that all customers coming from a specified domain do have access to products A, B, and C but not to D or E.

So, that being the case, what would be the best XrML 2.1 way to express the following element from your example?

>  <any principal who is a platinum member/>

thanks,

Bob

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC