eXtensible rights Markup Language (XrML) Standard Extension 2.1 Specification

Abstract

This specification defines the eXtensible rights Markup Language (XrML) Standard Extension, a set of commonly useful extensions to the XrML Core.

Status of this Document

Feedback and suggestions are welcome. Please report errors and provide comments on this document to the current editor at http://www.xrml.org/xrml_comments.asp.

Table of Contents

Introduction

Scope

This document builds upon the XrML Core 2.1 Specification. It defines a set of concepts that are generally and broadly useful and applicable to XrML2 usage scenarios, but which aren't necessarily at the heart of XrML2 semantics.

These concepts are broadly classified, according to the purpose that they serve, into conditions, payment notions, properties, and revocation extensions.

Keyword Conventions

This document follows the same keyword conventions as the XrML Core 2.1 Specification.

Schema Conventions

This document follows the same schema conventions as the XrML Core 2.1 Specification.

Condition Extensions

The standard extension schema defines several extensions of the type Condition. Of these, six extensions require a notion of state. To facilitate the definition of these extensions, a type StatefulCondition is defined as well. Condition extensions are constructed either by extending the type StatefulCondition or by directly extending the type Condition. What it means for a Condition extension to be satisfied is left to its description.

StatefulCondition

Some Conditions may be tied to a notion of state. For example, the number of times some content may be rendered can be bounded by some value. To cover such usages, standard extension defines a type called StatefulCondition. The type is an extension of the type Condition defined in the core. It includes a child element serviceReference, which indicates a service to be used to manage state. The details of this interaction is necessarily service-specific and so is not discussed here.

StateReferenceValuePattern

A pattern that identifies a set of ServiceReferences using pattern matching by dereferencing their values.

A StateReferenceValuePattern p matches a ServiceReference if and only if it can be determined that the present state of the service can be represented by the children of p. The means for determining this is necessarily service-specific and so is not discussed here.

The element stateReferenceValuePattern is typically used with the obtain element. When the Right to obtain a grant with a StatefulCondition is issued, then (to give the user exercising the obtain Right an idea about the initial state a certain serviceReference will happen to have) a stateReferenceValuePattern is created to make such an indication. This ensures that only serviceReferences in the proper state will appear in the obtained grant.

The ExerciseLimit Condition

Indicates a limit on the number of times that certain exercises may occur.

An ExerciseLimit is satisfied if the current exercise is one of n allowed exercises, where these allowed exercises (and hence the number n) are managed by the specified serviceReference.

The SeekApproval Condition

Indicates that the specified service must give its approval for this Condition to be satisfied.

A SeekApproval is satisfied if the specified serviceReference allows it to be.

The TrackReport Condition

Indicates that exercises must be tracked with a designated tracking service.

A TrackReport c is satisfied while either

• the exercise is considered tracked with the designated serviceReference or
• both of the following are true
  • c/communicationFailurePolicy is "lax" and
  • there is a state of communication failure with the tracking service.

The TrackQuery Condition

Represents a Condition based on some stateful integral value.

A TrackQuery is satisfied if the stateful integral value managed by the specified serviceReference is within the range as specified by the two child elements notMoreThan and notLessThan.

TrackQuery is commonly used to predicate the possibility of one exercise on the occurrence (or non-occurrence) of other exercises. In particular, a trackReport applied to one exercise might cause the value of a trackQuery applied to another exercise to increase by one, thus possibly changing the satisfaction of the trackQuery.

The ValidityIntervalFloating Condition

Represents an interval of allowed exercising that begins with the first exercise.

A ValidityIntervalFloating is satisfied during the interval of allowed exercising, where that interval (and hence both its start and duration) are managed by the specified serviceReference.

Other Forms of Validity Intervals

A ValidityIntervalFloating Condition is useful to express floating intervals that become fixed on first use. Often times (either for business model reasons or to minimize the amount of state keeping done by a compact device) it is also useful to be able to express floating intervals that get fixed during some License issuance step. For this reason, the standard extension defines two types for use in conjunction with ValidityInterval (from the core) to accomplish this goal. The ValidityIntervalDurationPattern pattern and ValidityIntervalStartsNow Condition are useful in this respect when placed on a Grant to Issue.

The ValidityIntervalDurationPattern Pattern

A ValidityInterval v matches a ValidityIntervalDurationPattern d if the duration of time represented by v is equal to d/duration.

The ValidityIntervalStartsNow Condition

A ValidityIntervalStartsNow Condition c is said to be satisfied at time t if all of the following hold:

• If c/backwardTolerance is present, then c/validityInterval/notBefore is present and greater than or equal to the result of t set backwards by the value c/backwardTolerance.
• If c/forwardTolerance is present, then c/validityInterval/notBefore is either
  • absent or
  • present and less than or equal to the result of t set forward by the value c/forwardTolerance.

The ValidityTimeMetered Condition

Represents a constraint on the cumulative exercise time over all exercises.

Unlike ValidityIntervalFloating, ValidityTimeMetered deals with a length of time that is not necessarily contiguous. A ValidityTimeMetered is satisfied at time t if t lies within the intervals of time that make up the cumulative time duration, where those intervals are managed by the specified serviceReference. If the quantum child of a ValidityTimeMetered is specified, it specifies the minimum length that one can expect each such interval to have.

The ValidityTimePeriodic Condition

Indicates a validity time window that recurs periodically. For example, this condition can be used to express time windows such as "every weekend" or "the second week of every month".

ValidityTimePeriodic/start

A locally defined element of type xsd:dateTime. Indicates the start of the time, typically date, from which the periods designated in this right become meaningful.

ValidityTimePeriodic/period

A locally defined element of type xsd:duration. This indicates the frequency with which the exercise time window recurs.

ValidityTimePeriodic/phase

A locally defined element of type xsd:duration. This is used to indicate a period of latency before beginning each time window. When this value is positive then it directly specifies the duration of latency. When this value is negative, then the duration of latency is equal to the length of period minus the absolute value specified herein.

ValidityTimePeriodic/duration

A locally defined element of type xsd:duration. This indicates the actual length of the time window.

ValidityTimePeriodic/periodCount

A locally defined element of type xsd:integer. Indicates a bound on the number of time windows. This element is optional.

Satisfaction of the ValidityTimePeriodic Condition

Suppose c is a ValidityTimePeriodic Condition and let

• s be c/start,
• p be c/period,
• h be c/phase,
• d be c/duration, and
• n be c/periodCount

then c is satisfied at time t if s + i*p + h <= t <= s + i*p + h + d for some i satisfying all of the following:

• if h is positive, then i >= 0,
• if h is negative, then i >= 1,
• if h is positive and n is not absent, then i <= n - 1, and
• if h is negative and n is not absent, then i <= n.

The Fee Condition

Indicates that there is a fee for the exercise.

Fee/paymentAbstract

This element of type paymentAbstract is abstract. It is meant to be substitutable. For more details and examples of extensions see paymentAbstract.

Fee/min

This locally defined optional element contains a paymentAbstract element. It specifies the minimum amount due. If the total amount paid is less than the value of this element, a new payment in the amount of the difference is due.

Fee/max

This locally defined optional element contains a paymentAbstract element. It specifies the maximum amount due. If the total amount paid is greater than the value of this element, a new credit in the amount of the difference is due. If the total amount paid is equal to the value of this element all other payments resulting from this Fee are void until the value of max increases.

Fee/to

This locally defined element is of type AccountPayable. It indicates the party to whom, and the means by which, payment is to be made. To allow for the rare cases where this is discovered from context, this element is left optional.

AccountPayable

AccountPayable is used to identify a party to whom one can transfer a sum of money, along with an identification of the means by which such a transfer is to take place. While there are undoubtedly many ways this can be done, two ways are explicitly defined. The type AccountPayable is defined as a choice between three options. The first, a paymentService, identifies the party to whom the payment is made. The second option, aba, identifies a bank in the US banking system. As a provision to support other forms of banking mechanisms, an option is made for specifying other banking means as well. This is realized by the xsd:any particle.

AccountPayable/paymentService

The locally defined element paymentService contains a serviceReference. This identifies the party to whom the payment is to be made, and the interface to the service indicates the necessary payment mechanism.

AccountPayable/aba

The locally defined element identifies an account within a US banking institution by means of conventions established by the American Banking Association. It defines two child elements, institution and account. The banking institution is identified by its nine-digit banking routing number using the institution. The account within that institution is identified with account.

Using the fee condition

A Grant can predicate an exercise on a Fee. Typically Fees involve a payment and a designation of the party the payment is made to. Options about what form the payment should take (such as periodic or one-time or usage-based or metered) are reflected by the paymentAbstract element. A child element to of type AccountPayable is used to characterize both the payment mechanism and the payee.

There are two other optional elements. The optional min price specification indicates the minimum price to be paid if the right is exercised at all. The optional max price specification refers to the maximum price to be paid. When both max and min price specifications are given, the max price specification dominates.

Suppose that the Fees in paymentAbstract, min, and max independently amount to p, min, and max respectively due for the exercise as defined by their respective paymentAbstract extensions. Then, let x be

• min, if p <= min < max;
• p, if min < p < max;
• max, if max <= p or max <= min.

Then the Fee Condition is satisfied if and only if the amount x is paid to the entity identified by to for this purpose.

Not all forms of paymentAbstract extensions are directly comparable. For the Fee Condition to be sensibly evaluated, it is necessary that the extensions of the paymentAbstract elements in paymentAbstract, min, and max are comparable. In the standard extension, the paymentAbstract extensions either contain serviceReferences or they do not. Those that do are considered stateful. Stateful paymentAbstract extensions are not comparable with stateless ones, so it is required that the paymentAbstract extensions in paymentAbstract, min, and max are either all stateful or all stateless. The corresponding Fee Conditions are respectively termed as stateful and stateless.

The Territory Condition

Indicates a constraint on the geographic or virtual space where the exercised may occur.

Territory/location

This element defines inline the optional elements region, country, state, city, postalCode and street that designate a physical location.

Territory/location/region

This element designates an ISO 3166 country subdivision.

Territory/location/country

This element designates an ISO 3166 country.

Territory/location/state

This element is a two-letter code for US states.

Territory/location/city

This element designates a city.

Territory/location/postalCode

This element designates a postal code (e.g. a zip code).

Territory/location/street

This element designates a street.

Territory/domain

This element defines inline an element uri to designate a digital location.

Territory/domain/uri

This element, has type xsd:anyUri and can be any URI that designates a digital location.

Satisfaction of the Territory Condition

Since it may be desirable to have an exercise occur in more than one location, physical or digital, the content model for Territory allows for an unbounded number of children.

A Territory is satisfied if the exercise can be shown to be occurring in at least one of the locations or domains.

PaymentAbstract and its Extensions

PaymentAbstract

The notion of payment is abstracted in the Standard Extension. The element paymentAbstract has type PaymentAbstract. Both are conceptually abstract.

In place of PaymentAbstract, more concrete forms of payment (PaymentFlat, BestPriceUnder, CallForPrice, Markup, etc.) are to be used. The standard extension defines seven different kinds of payments. Each of these defines its own notion of when a payment has been made that works toward a Fee Condition being satisfied, as described in the section on Fee.

Cash

An amount of money in a designated currency (using ISO 4217).

PaymentFlat

Specifies a payment due upon exercising. The contained serviceReference is used to determine if the fee has already been paid and to keep record of payment. The contained rate specifies the Cash value of the payment to be made.

PaymentMetered

Specifies a payment due for each time interval during which an exercise occurs. The contained rate and per elements together specify the charge per period. The contained by element indicates the quantum by which time is measured for the computation of the amount. The contained phase element is used for rounding purposes; it indicates what portion of time may elapse before somone is billed for the whole duration defined with by.

The element phase is used for rounding the units of time that are smaller than the duration described by the by element: a value of zero would have the effect of rounding up while a value equal to the value of by would have the effect of rounding down.

Formally, after normalilzing all of the duration values to seconds, suppose the rate is r, per in seconds is p, by in seconds is b, and phase in seconds is h. Then, if the interval of exercise of the right is t seconds, then the payment due is given by the expression r * (p/b) * ( floor( t/b ) + round ) where round is 1 if t%b is greater than h and is 0 otherwise.

PaymentPerInterval

Specifies a payment due for each time interval during which the ability to exercise is desired. The enclosed serviceReference is used to keep track of the time through which payment has been made. The contained rate and per elements together specify the charge per period.

PaymentPerUse

Specifies a payment due each time a right is exercised. The contained rate and initialNumberOfUses elements together specify the charge per package of uses. If initialNumberOfUses is absent, it defaults to 1. The serviceReference is used to keep track of the number of prepaid uses remaining.

BestPriceUnder

Specifies the maximum price that ultimately must be paid without specifying the ultimate price exactly. The ultimate price is determined through a later, unspecified settlement mechanism. While max overrides min if max is less than min, min overrides BestPriceUnder if BestPriceUnder is less than min. If an implementation cannot determine the ultimate price exactly, it is free to voluntarily take the payment contained herein as the ultimate price.

CallForPrice

Identifies an entity with whom a price must be negotiated before exercising. Any one of the specified serviceReferences can be used to negotiate a price. Unlike BestPriceUnder, price determination is required for CallForPrice.

Markup

Specifies a fee due each time some other fees are due. The rate element indicates the fractional rate at which markup is calculated.

Let m be a Markup. Then m requires the payment of any m/fees and m/feeForResources which may be present therein. In addition, for each such payment, an additional payment equal to the product of that payment and the value m/rate is due.

The presence of a feeForResource implies a context in which multiple resources are being used simultaneously. The total price for using the specified m/feeForResource/resource t is calculated (and such amount is paid, as defined by any Licenses for that t). The price is then marked up by the m/rate, and the markup is paid as specified by the containing Fee element. If t is not used in conjunction with this exercise, then m is not fulfilled and the containing Fee is not satisfied.

Name Extensions

Name

A property indicating a name from some name space.

Name is an extension of the type PropertyAbstract, and, as such, can be used along with the PossessProperty Right to associate a Name with a Principal. (This is useful for modeling the X.509 certificate-like binding of names to principals). Such associations allow (other) Grants to be made to, colloquially speaking, Principals described by their Names.

Both the element name and type Name are conceptually abstract.

EmailName

An Internet email address (per rfc822/rfc2822) associated with the entity.

DnsName

A name in the DNS name space, with trailing period omitted. For example, "xyz.com"

CommonName

A name by which an entity is colloquially known. Intended to be used as the CN name part from X400.

X509SubjectName

The subject name of some X509 certificate associated with the entity. Intended to address legacy interoperability issues involving X509 certificates.

X509SubjectNamePattern

A pattern that identifies a set of X509 subject names using pattern matching.

X509SubjectNamePattern is not a derivation of the type Name. Rather, it is a derivation of the type ResourcePatternAbstract. It matches any X509SubjectName for which it is the root of the X509SubjectName tree. This element can be used to enforce constraints similar to the X509 specification.

Revocation Extensions

Revocable

Identifies a dsig:SignatureValue that can be Revoked. The dsig:SignatureValue can be identified literally or by reference. In the latter case, the result of dereferencing the reference must be of type dsig:SignatureType; the dsig:SignatureValue able to be Revoked is the one dsig:SignatureValue therein.

A Revocable is a Resource for use with the Revoke Right.

XrML Standard Extension Schema

xrml21-xrml2sx.xsd (normative)

References

eXtensible rights Markup Language (XrML) Core 2.1 Specification.

ContentGuard, Inc. May 20, 2002.

http://www.xrml.org/.

ISO 3166: Codes for the representation of names of countries and their subdivisions.

http://www.iso.org/.

ISO 4217: Codes for the representation of currencies and funds.

http://www.iso.org/.