1. Specification of Usage Control Requirements
Bibek Shrestha
Technische Universität München, Germany
bibek.shrestha@tum.de
Abstract. Usage control deals with control of data use as it has been
released from the sender to a receiver. The design of language to specify
usage control requirements poses complex challenges as it needs to have
a rich syntax for expressiveness, a formal semantics to detect correctness and formal verification and a mechanism to check for adherence to
specified policies in the future. We describe the basics of usage control
requirement and take a look at two policy languages: Obligation Specification Language (OSL) and Ponder and describe their purpose, syntax
and explain how each can be used for specification of usage control requirements.
1
Introduction
Data producers are interested to control the number of ways their data are
used by consumers. Doing so in digital environment is even harder and is a
subject of research. Data comes in different forms: personal data like online
shopping, loyalty cards, geo-positioning data or data from business organization
that need to be kept private or intellectual property like music, video and other
artistic works or even sensitive data of the government or military. Usage control
[3] embraces all these areas and as such is an extension of access control that
concerns with who may access the data and how the data may or may not be
used in the future.
A fair amount of diverse projects in the field of mobile and ubiquitous computing have been studied in [5] and a catalog of usage control requirements have
been mentioned. These are typical usage control requirements that occur in many
areas, not just ubiquitous computing. They also list different aspects to a policy
language requirement: support to express data owners and data consumers and
other roles, the type of network where data is passed around, support for different forms of data, support for different forms of restrictions, etc. These aspects
form the basis of usage control specification which in turn shapes usage control
specification language.
Usage control specification languages are specially designed to represent policies and usage control requirements. The features of a usage control specification
language would be a) clearly defined syntax and semantics to specify rules and
policies, b) semantics for specifying and configuring enforcement mechanisms or
for checking the adherence to policies, c) support to detect conflicting rules, d)

2. inter-operable with existing policy languages, e) inter-operable with other existing languages and f) can be represented in easier implementation format like
XML or others.
In this seminar paper, we look into two policy specification languages used for
access control: a) Obligation Specification Language (OSL) [3] and b) Ponder
[2]. OSL is designed specially for obligations while Ponder does not make a
clear distinction between provisions and obligations and can be used to specify
both. We look into the objectives of each of the two languages and see how
they compare against the features we discuss above and identify their features,
advantages and shortcomings.
2
Obligation Specification Language (OSL)
Obligation specification Language (OSL) is a language for expressing requirements from many application areas of usage control. OSL is formalized in Z, a
formal specification language based on typed set theory and first order predicate
logic with equality [3].
OSL is developed with three specific problems in mind [3]: First, although
there exists specific-purpose languages for privacy, there is a lack of general purpose requirement specification languages for usage control that can be expanded
to different areas. Second, many policy languages lack semantics for specifying and configuring enforcement mechanisms or for checking the adherence to
policies. Hence, in many languages it is not clear what sorts of policies can be
enforced. Third, as there is a lack of common semantics, most of the languages
are not inter operable.
OSL overcomes all of the three problems as it is designed to write requirement
specifications for usage control, a formal semantics and a syntax has been defined
for it and translation between OSL and a REL has been shown and implemented
for a subset of two widely used RELs: XrML and ODRL. This helps build a
formal semantics into the RELs themselves.
2.1
Background
When a data provider gives the data to a data consumer, certain conditions
apply. As explained in the Introduction, Provisions apply before the data items
are released to the consumer. Obligations apply to the data consumer once the
item has been released. Main focus of OSL is into obligations as provisions have
been throughly studied in terms of access control.
Obligational formulas [3] are used to define obligations. An obligational formula is a condition defined on the usage of the data. When a data consumer
receives a data and commits to the conditions, it is called activation of the obligational formulas by which the obligational formulas become obligations. The
term obligational formula is referred to as obligation for simplicity.
Obligations can take two different forms. Conditions that prohibit certain
usages under given circumstances are called usage restrictions and conditions
2

3. that specify mandatory actions that must be executed either unconditionally or
after specific usage has been performed are called action requirements.
Conditions specify circumstances under which the usage restrictions or action requirements apply. They can be classified into time conditions, cardinality
conditions, event-driven conditions, purpose conditions and environment conditions. Usage restrictions are of the form “if condition then no usage.” For example,
“software may not be installed on more than one hardware”. Action requirements
are of the form “if condition then action.” Example, “decrease the credit after
the movie has been played”.
Time Conditions specify that a certain action be taken within certain time or
the action be taken only after some amount of time has passed. Example: “User
should be only able to skip the advertisement after 4 second of play.” Cardinality
Conditions specify the number of occurrence of given events. Example: “movie
M may only be played twice.” Event-Driven Conditions specify the situation in
terms of the occurrence of events. Example: “If the publisher decides to remove
a book, it should be deleted from the reader device.” Purpose conditions specify
the purpose of the use. Example: “For educational purposes only.” Environment
Conditions relate to the internal and external environment of the data consumer.
Example: “The DVD media can only be played in North America.” Different
conditions can be combined to describe complex circumstances: “User can watch
the full movie if they watch five advertisements, or purchase the movie, only for
next 7 days.”
2.2
Basics of OSL Formalization
Events and Time Steps An event [3] in OSL is an execution of an action and as
such it is used interchangeably for an action. OSL is defined over discrete time
steps and in each time step a series of events can occur.
Event Classes and Parameters Any event can belong to either of the two event
classes: usage and other. Usage events are those related with direct usage of
the data. Other events stand for non-usage events. Each event has a name and
parameters which specify additional details about the event. For example [7], a
usage event must indicate on which data item it is performed, and a signaling
event-one that is sent from the consumer to the outside-must name the recipient of the message. The parameter is represented as a partial function (→)
from names to values. Each event parameter is described as (name, value) pair.
An example is (play, (object, o)), where play is the name of the event and the
parameter object has the value o.
An event is defined in follows. EventName, ParamName and ParamValue
define the basic types for event names, parameter names and parameter values respectively. In Z, such definitions are made by listing the types in square
brackets. All such basic types are disjoint.
[EventName, ParamName, ParamValue]
EventClass ::= {usage | other }; getclass : EventName → EventClass
Params : ParamName → ParamValue; Event == EventName × Params
3

4. Indexed Events help to specify restrictions on accumulated usage times over
multiple steps of a trace. An indexed event is assumed to exist in each step of
a trace for each usage that is currently being executed. The start of a usage is
represented by an indexed event with the index start and all following indexed
events for that usage is represented by an index ongoing. To express events
that are attempted by user but not necessarily executed, we have the notion of
desired indexed events. We also define traces: mappings from abstract points in
time−represented by the natural numbers− to sets of events. IndEvent defines
indexed events , DesiredIndEvent defines desired indexed events and and Trace
define traces.
IndEvent == Event × {start, ongoing}
DesiredIndEvent ::= TRY IndEvent
Trace : N → P IndEvent
Event Declaration and Refinement Relation Events can be defined in the system
using Event Declarations which contain the event name, the event class and a
partial function that defines the name and possible values of each parameter.
EventDecl == EventName × EventClass × (ParamName → P ParamValue)
For example: (play, usage, {(object, ObjID), (device, DevID)})
Events are ordered with respect to a refinement relation refinesEv [7]. The
rational behind refinement relation is that when specifying usage control requirements for our policy, we do not want to specify the same event under all
possible parameters. For example, if the event (play, {(object, o)}) is prohibited,
then the event (play, {(object, o), (device, d )}) should be prohibited too.
2.3
Syntax
OSL policy consists of a set of event declarations and a set of obligational formulas[3]. Each obligation formula consists of the data consumer’s name and a
logical expression.
OSLPolicy == P EventDecl × P OblFormula
OblFormula == SubjectID × Φ
Where SubjectID is the set of possible subject names of data consumers and
Φ is the set of logical expressions contained in the obligational formulas explained
in more details in [3]:
Efst (e) refers to the first indexed event of e and Eall (e) refers to the ongoing
indexed events of e. The events are specified by virtue of the refinement relation.
Similarly, Tfst stands for the first occurrence of the desired event, and Tall for
any occurrence of the desired event.
4

5. Operators The operators not, and , or and implies have the same semantics as
their prepositional counterparts ¬ , ∧, ∨ and ⇒.
until , after , during and within are temporal operators with intuitive meanings. until operator corresponds to the weak until operator known from LTL.
after takes a natural number n as input and refers to the time after n time
steps. during is used to imply that something must hold constantly during a
given time interval and within can be used to imply something must hold at
least once during a given time interval.
replim, repuntil and repmax are the cardinality operators. The operator
replim specifies a lower and an uppoer bound of time steps within a fixed time
interval in which a certain event occurs. For example,
replim(20, 5, 30, Efst ((playCommercial , {(stream, s})))
states that within the next 20 time steps, a commercial has to be played at least
5 times (and max. 30 times). The operator repuntil takes a natural number and
two expressions. It limits the maximum number of times an event represented
by the former expression may occur until another event represented by later
expression occurs. For example,
repuntil (3,
Efst (play, {(object, m})),
Efst ((pay, {(currency, USD), (amount, 10), (recipient, r )})))
states that a movie m can only be played 3 times until a amount of $10 be paid
to r. The operator repmax limits an event to be at max repeated N times in the
unlimited future. For example,
repmax (5, Eall (play, {(object, s)}))
states that song s must not be played more than 5 time steps. Eall instead of
Efst is used to to specify time steps to limit accumulated usage time.
OSL supports two modalities of specifying policies [3]. The “must” modality
and the “may” modality. The “must” modality is used to explicitly define requirements on the system execution such that all the requirements must be fulfilled.
In contrast, the “may” modality is used to express exclusive rights to execute
given actions under specific conditions. When exclusive rights are specified, it
means that except the given rights, the user does not have permission to other
rights which are generally not specified explicitly. The “must” modality is generally used in expressing explicit privacy prohibitions while “may” modality is
used in DRM area where only few usages are allowed. The “must” modality is
inherited from temporal logic, and the “may” modality has been included via
dedicated permission operators.
The “must” modality is given by OSL’s LTL-like semantics while the “may”
modality is supported by two designated permit operators: permitonlyevname
and permitonlyparam. With permitonlyevname, only those usage events with
given names and having given set of parameters are permitted. For example,
5

6. permitonlyevname({play, pause, stop}, {(object, m)})
states that the movie m can only be played, paused or stopped. All other
usage events are implicitly not allowed. Similarly permitonlyparam allows only
certain values for a given parameter of an event. It prohibits all other values.
For example,
permitonlyparam({s1 , s2 }, recipient, send , {(object, doc)})
specifies that for all send events with doc as a parameter, only those with the
recipient parameter s1 and s2 are allowed.
A policy is satisfied by a trace iff all obligations specified in the policy are
satisfied by the trace.
({
(play, usage, {(object, ObjID), (device, DevID)}),
(backup, usage, {(object, ObjID), (device, DevID)}),
}, {
(Alice, permitonlyevname({play, backup}, {(object, mov )})),
(Alice, repmax (5, Eall ((play, {object, mov })))),
(Alice, permitonlyparam({pl }, device, play, {(object, mov )})),
(Alice, repmax (1, Efst ((backup, {(object, mov )}))))
})
is an example of a complete OSL Policy[3]. The first part contains two event
declarations: play and backup, both on object: ObjID and device: DevID. The
second part contains four obligation formulas with data consumer: Alice. Alice
is allowed to only play and backup the object mov . She can play object mov for
5 times, she can play mov only on device pl and she can backup the mov only
once.
2.4
Translation to and from other languages [3]
Several Rights expression languages (RELs) already exist. Open Digital Rights
Language (ODRL) and eXtensible Rights Markup Language (XrML) being two
widely used among them. Work has been done on translation between OSL and
subsets of ODRL and XrML. The purpose for translation has three primary
reasons.
First, licenses written in RELs already have enforcement mechanisms in
place. With the ability to translate OSL policies into rights objects makes it
possible to re-use such mechanisms to enforce OSL policies. However OSL is
more expressive than RELs as policies other than rights (e.g., privacy polices)
can be expressed with it. Hence, translation from RELs to OSL opens up opportunity to bridge the gap between the areas of privacy and DRM.
Second, RELs can get a formal semantics by providing a translation scheme
between them and OSL as OSL already has a formal semantics. Few parts of
ODRL and XrML have been defined independently, a translation mechanism
6

7. provides an additional formal semantics to previously undone parts. The rational
to define formal semantics for RELs is that it provides a way to perform logical
analysis on their policies, and during runtime, adherence to obligations can be
checked.
Third, different RELs use different languages to express their licenses. For
a broader adoption, RELs need to be inter operable. Currently, there is a lack
of a common standard language for describing licenses. OSL can be used as a
common intermediary language to convert from one REL to another.
Translation from ODRLc to OSL A subset of ODRL: ODRLc (“ODRL compact”) has been chosen which does not include concepts of ODRL that are outside the scope of OSL[3]. ODRLc itself is still powerful enough and resembles
very closely to the REL used by the Open Mobile Alliance (OMA). Translation
of ODRLc to OSL is defined over all ODRLc licenses. Both OSL policies and
ODRL licenses can be represented in tree structured and a translation based on
top-down approach on the ODRLc tree has been used. ODRLc licenses specify
rights which are of “may” modality. For the translation, permitonlyevname expressions are used to prohibit all usages not explicitly permitted in the license.
All requirements in ODRLc must be satisfied at the same time; forming a logical
conjunction. Each of these requirements are converted to separate obligations
in OSL. Inside an OSL policy, obligations are implicitly conjoined and hence
conjunction of the constraints and requirements naturally follows.
Translation from OSL to ODRLc As OSL is more expressive than ODRLc,
not all of the OSL policies can be converted into ODRLc. It is difficult to
identify the subset which can be translated and thus a pragmatic approach
of pattern matching has been employed. For example, all formulas of the form
(subid , repmax (n, Efst (ue))), where subid is a subject ID, n ∈ N and ue is a usage event are translated into a <count>, which expresses cardinality constraint
in ODRLc. However, syntactic pattern matching requires obligations to be in
an implicitly defined canonical form and slight variations will result in a mismatch. The technique has its own limitations. The limitation can be overcomed
by extending it to semantically equivalent representations. This however involves
computationally expensive deductive reasoning.
3
Ponder Policy Specification Language
Ponder [2] is a declarative, strongly-typed, object-oriented language for 1) policy
specification, 2) grouping policies into roles and relationships, 3) defining configurations of roles and relationships as management structures. Being a declarative
language, it focus on what the specified policies are rather than how they will be
actually implemented. Ponder can however, map to various access control implementation mechanisms for firewalls, operating systems, databases, etc. Being an
object oriented language, the language is flexible, supports classes as types, interfaces and instantiation to create a hierarchy through which hierarchal complex
organizational structures as well as grouping of policies can be done effectively.
7

8. While developing Ponder, the authors identified the following requirements
with policy languages [2]: a) Allow declaration of policies that support delegation of access rights temporarily to other agents. b) Support policies relating
to large collections of objects, possibly millions rather than individual ones. c)
Composite policies that allow grouping different policies relating to role, organizational units, etc. d) Allow analyzing conflicts and inconsistencies among
different policies. e) Extensibility so policies that come up in the future can be
easily addressed by features like inheritance. f) Easy but comprehensive language
for policy users. Ponder addresses all of the above requirements as described in
the following sections.
3.1
Policy Concepts Overview [2]
Specifications in Ponder are written in terms of policies. A policy in Ponder
is simply composed of one or many rules. All policies are defined in terms of
methods in an interface definition language. Policies are divided into two primary
categories each having more subcategories. Each subcategory is called a policy
type. For each policy type, Ponder allows to define policy type definitions and
create their instances. This is analogous to defining a class and instantiating an
object instance for that class.
Syntax for Policy Type and Instance:
type ( policyType | groupType | roleType | relType | mstructType | metaType )
typeIdentifier "(" formalParameter ")" "{"
{ policy−parts }
"}"
policyType = authType | obligType | refrainType | delegType
inst (policyType) policyName = typeIdentifier "(" actualParameters ")" ;
A domain groups together objects to which policies can be applied. Every
object needs to be a member of some domain. When not mentioned explicitly,
the default domain root “/” is implied. Domains can have sub domains and as
such they are referred to as /DomainA/SubDomainB/C fashion where “/” being
the delimiter for domain path names. A domain can hold reference to any type
of object, including a person. Policies normally propagate to members of subdomains as well.
Type Definition and Instance Declarations A type definition creates a new
user-defined policy type which can be instantiated to create policy instances. A
instance declaration creates a policy instance either from existing policy type or
inline without specifying a user-defined policy type. The names for Type Definition and Instance Declaration are specified either as an identifier or as a domain
path to indicate the place within the domain structure where the policy instance
will be stored.
The two primary categories of policies are defined in the following section:
8

9. Basic Policies A basic policy contains one ore more policy elements. Basic
policies cannot contain other policies. Policy elements like the subject, the target,
the when-constraint, the import statements, constant definitions and external
specifications are common to all basic policies. Other policy elements are specific
to particular policy type. Policy elements can be specified in any order. Policy
elements are described in detail in [2]. Basic policies are further categorized into
four sub-categories as explained below:
Authorization Policies Authorization policies either permit or forbid members of
subject domain to perform actions on objects of target domain and are respectively called positive authorization policy and negative authorization policies.
They are implemented on the target host using access control component.
Syntax for authorization policy type declaration and instantiation:
type ( auth+ | auth− ) policyType "(" formalParameters ")" "{"
{ authorisation−policy−parts } "}"
inst ( auth+ | auth− ) policyName = policyType"("actualParameters")";
Besides policy elements, an authorization-policy-part contains authorization
actions. Positive authorization polices can be further supplemented by authorization filters.
Actions represent the operations defined in the interface of a target object.
Actions that are permitted or forbidden are listed separated by commas. '*' can
also be used to signify permissions for a subject on all actions visible on target
object interface.
Filters are used for optional transformation of parameters related to an action. They can transform or select subsets of the provided information in the
in and out parameters or also the result of the invocation. An action can have
more than one filters associated it.
type auth+ printAuth(subject S, target T, int maxpages) {
subject /Agroup + /Bgroup;
target PrinterA;
action print(pages, error) if pages > 100
{ in pages = 100; };
}
states that members of Agroup and Bgroup can print with PrinterA. The filter
applies if pages are greater than 100, if so it modifies the number of pages to
100.
Obligation Policies Obligation policies specify actions that must be performed
on a set of target objects. These actions are only performed when events occur
and provide the ability to respond to changing circumstances.
Events can be simple (i.e., an internal timer event or an external event notified
by monitoring service components like a sensor value goes outside of a threshold)
or it could be composite events specified using event composition operators.
Event is specified after the on keyword.
9

10. Obligation actions are specified in an obligation action list separated with
concurrency operators indicating whether the actions are to be performed sequentially or in parallel. Each individual action can be prefixed with the name
of the object on which the action is to be called which can be the subject or
the target. If no prefix is specified, the action is assumed to be internal to the
subject or part of the subject’s interface by default.
Obligation Policy Syntax:
inst oblig policyName "{"
on
event−specification ;
subject [<type>] domain−Scope−Expression ;
[ target [<type>] domain−Scope−Expression ; ]
do
obligation−action−list ;
[ catch
exception−specification ; ]
[ when
constraint−Expression ; ] "}"
The event specification, subject and obligation-action-list are required while
target, exception specification and constrain expression are optional. The catchclause specifies an exception that is executed if the actions fail to execute for
some reason. Since enforcement of policies is done by the subject, obligation
policies are interpreted by subjects.
inst oblig drugsAdmin {
subject
s = /wardA/nurse;
target
t = /sectionD/patient/stevens;
on
[ t .temperature > 37];
do
administer(analgesics ) −> record(t.temperature, t.time);
}
states that when Steven’s temperature exceeds 37 degrees, nurse takes two actions: first she administers analgesics followed by second manually recording his
temperature.
Refrain Policies Refrain policies specify actions that must not be performed
by the subject on target objects. Like obligation policies, they are defined by
the subject. They are similar to negative authorization polices and have similar
syntax, but are enforced by subjects rather than target access controllers. They
are used for situations where negative authorization policies are inappropriate
because the targets are not trusted to enforce the policies.
inst refrain testingRes {
subject
s=/test−engineers ;
target
/analysts + /developers ;
action
discloseTestResults () ;
when
s .testing_sequence = "inprogress" ;
}
states that Test engineers must not disclose test results to analysts or developers
when testing sequence being performed by that subject is still in progress.
10

11. Delegation Policies Delegation policies specify which positive or negative authorization policies can be delegated by a subject, which they themselves possess
to grantees so that the grantees can perform an action on the subject’s behalf.
Delegation of rights must be tightly controlled, specially when the system
allows cascading policy delegation.
Delegation Policy Syntax:
inst deleg+ "(" associated−auth−policy ")" policyName "{"
grantee
[<type>] domain−Scope−Expression ;
[ subject [<type>] domain−Scope−Expression ; ]
[ target
[<type>] domain−Scope−Expression ; ]
[ action
action−list ; ]
[ when
constraint−Expression ; ]
[ valid
constraint−Expression ; ] "}"
From the syntax, it is clear that delegation policy is always associated with
an authorization policy. Also, grantee is a mandatory part while all other parts
are are optional. If unspecified, the values default to that of the authorization
policy. A positive delegation policy can limit the validity of the delegated access
rights as part of the valid-clause. An example is shown below:
inst deleg+ (printAuth) delegPrintAuth {
grantee
/StudentGroup ;
valid
time.between(1200, 1300) ;
}
states that the authorization policy printAuth which was only allowed to Agroup
and Bgroup is now granted to Studentgroup. However they can only print between 1200 and 1300 hours. Also, since subject and target are missing, subject
must be someone from Agroup or Bgroup and target is by default PrinterA
Composite Policies Composite policies group a set of policy specifications
within a syntactic scope with shared declarations in order to simplify the policy
specification task from small to large distributed systems.
Groups Group construct is used to group a set of policies and constraints together such that they have semantic relationship and they should be grouped
together. For example they may reference the same targets, relate to the same
department or apply to the same application.
Group Syntax:
inst group groupName "{"
{ basic−policy−definition }
{ group−definition }
{ meta−policy−definition } "}"
Groups can be defined as type definition to make it reusable.
inst group loginGroup {
inst auth+ staffLoginAuth {
11

12. subject
target
action
/dept/users/staff ;
/dept/computers/research ;
login ; }
inst oblig loginActions {
subject s = /dept/computers/loginAgent ;
on
loginevent (userid , computerid) ;
target
t = computerid ^ {/dept/computers/}
do
s . log (userid , computerid) −>
t .loadenvironemtn (userid); }
inst oblig loginFailure { ... }
}
states that loginGroup allows staff to login, logs login attempts and loads environment on successful login and also deals with login failures
Roles A role is a special type of group construct. It groups policies related to
the duties and rights relating to a position within an organization. Thus inside a
role, all policies have the same subject domain. A role can contain basic policies
and groups of basic policies but not nested roles, relationships or management
structures.
type role Student
declares a new role called Student
Relationships A relationship groups together inter-role policies that defines how
the roles interact with each other. This includes the duties of one role to another,
or policies related to resources shared between the roles.
Management Structures Management Structure allows an organization to generalize common organizational structure so that it can be instantiated later. It
collects policies in the form of roles and relationships and group them together
in order to apply them to more than one structure.
4
Discussion
The approach taken by OSL by describing the semantics and syntax of the language in Z gives OSL significant advantages. Logical analysis can be performed
which accurately describes the meaning of a policy in machine interpretable way.
OSL can also be expressed in XML for interoperability with XML based standards [4]. Translation mechanisms exist so that OSL can be converted into either
ODRLc or XrML subset.
OSL has the limitation that it uses abstract events instead of concrete system
events. Thus there is an extra cost for mapping. For example, an event “store”
on a media object could mean either “store offline” or “store online in the cloud”.
These implementation details would be vendor specific. OSL does not yet define
12

13. a mechanism to perform the mapping. The authors recognize this as a future
work [3].
OSL also does not provide policy organization. In Ponder, the concept of
domain helps to form logical organizations of policies of similar concerns. groups
and roles collect multiple policies inside a single entity. The object-orientedness
of Ponder allows abstraction of core ideas and extend further policy variants
from the core policies. OSL on the other hand has relatedEvents which shows
a hint of generalization among event based on parameters. However, the policy
elements like subjectid or event declaration etc are very elementary, their definition do not contain extra attributes in order to have inter-relationship between
different subjects or different events. In addition, hierarchical grouping of policies in Ponder allows more expressive capability. This feature is also missing in
OSL.
Ponder on the other hand focuses on overall access control specification requirements. There is no clear separation of the requirements into Provisions and
Obligations. Since it is object oriented and all policies are written in methods in
interface definition language, the syntax is much closer to an actual implementation. It supports advanced hierarchical grouping of policies and user roles that
tries to resemble an actual organization structure. The subjects, targets, event
and event parameters are not abstract and can be associated more closely with
the system.
The lack of distinction between access control and usage control shows some
limitation of Ponder, particularly for temporal policies. Ponder has timer library
object which contains functions that can be used to specify time-point events,
repeated events based on duration, and repeated events at specific time-points.
However, it lacks the norm of time-steps to perform cardinal operations. Take
the following example where time is in reference to another event: “Notify the
media store five seconds after a song has played” or another example with only
cardinal operator “One episode can only be viewed 10 times before new payment
is made”. Ponder can interact with external system to store states and thus the
above examples can be specified indirectly. But, it defies logical analysis on such
policies.
It is also worth asking how extensible Ponder and OSL would be. Due to
changing technologies, new paradigms emerge from time to time. During the
time of cassettes and CDs, a presence of physical media was important and
ownership was clearly with who owned the media. We have seen the shift from
physical media to saving media as a file in computers, and recently into payper-view or monthly subscription models. Similarly, policies have changed from
“Anyone who is the owner of the media is allowed to listen to the music but not
make a copy” to “User is only allowed to listen to the song as long as his/her
subscription is valid”. The user now owns only subscriptions and not the media
itself. We can only guess what changes will happen in the future and try to see
how adequate the specification languages are to handle such changes.
13

14. 5
Related Work
eXtensible Access Control Markup Language (XACML) XACML is an attributed
based access control policy language written in XML. It has been ratified by the
OASIS standards organization. The highlight of XACML is that it separates
Policy Decision Point (PDP) and Policy Enforcement Point (PEP). PDP stores
the policies definition and PEP is the point of enforcement. Besides access control policy specification, it also supports obligations specification and it has also
been studied in distributed environment [6], thus making a case for usage control
specification. Although XACML policy language is very flexible for specifying
access policies, its current handling of obligations [8] is very basic, as an obligation is simply defined through attribute assignment; leaving the definitions of
the syntax and semantics of the obligations to the application writers. [1] describes eXtensible Obligation Markup Language (XOML) as an extension on top
of XACML that gives structure to the obligations part. Their work is stalled
however and it does not focus specifically on usage control.
Ponder2 Ponder2 [9] is a significant re-design and re-implementation of Ponder.
Although some of the underlying concepts bear similarity to the basic constructs
of Ponder the entire framework has been re-done. In contrast to the previous
version, which was designed for general network and systems management, Ponder2 has been designed as an entirely extensible framework that can be used at
different levels of scale from small, embedded devices to complex services and
Virtual Organisations. Ponder2 does not depend upon a centralized infrastructure support, centralized provisioning and decision making. An android port of
Ponder called P2Android has been written but it is still in very early stages of
development.
6
Conclusion
In this seminar paper, we discussed usage control, policies that make up the
usage control and how to specify them in two different specification languages:
Obligation specification Language and Ponder. The policies under usage control
are very dynamic. As a language that allows specification of usage control requirements, the challenges lie in being able to express as much different types of
polices as possible as well as be able to put semantics into the policies so that
they can be validated by a machine. Both OSL and Ponder have been designed
with specific requirements in mind and offer comprehensive vocabulary to specify
complex policies.
A lot of work is being done on OSL and Ponder. Ponder being an older
specification was designed with organizational structure and user behavior like
delegation in mind, and it is less concerned with usage control in current distributed environments. Ponder2 was released on February, 2011 as an extensible
framework for distributed environment. Still, with the ever increasing use of mobile devices and adoption of ubiquitous networks, OSL seems like a more fit as
14

15. it was designed for these environments. Future work [4] on OSL is expected to
make it more feature rich and increase its adoption in the industry.
References
1. David Chadwick and Mario Lischka. Obligation standardization. In W3C Workshop
on Access Control Application Scenarios, November 2009.
2. Nicodemos Damianou, Naranker Dulay, Emil Lupu, and Morris Sloman. The ponder
policy specification language. In Policies for Distributed Systems and Networks,
pages 18–38. Springer, 2001.
3. Manuel Hilty, Alexander Pretschner, David Basin, Christian Schaefer, and Thomas
Walter. A policy language for distributed usage control. In Computer Security–
ESORICS 2007, pages 531–546. Springer, 2007.
4. Manuel Hilty, Alexander Pretschner, Christian Schaefer, and Thomas Walter. A
system model and an obligation lanugage for distributed usage control. In Technical
Report I-ST-20, DoCoMo, Euro-Labs, 2006.
5. Manuel Hilty, Alexander Pretschner, Christian Schaefer, and Thomas Walter. Usage control requirements in mobile and ubiquitous computing applications. In Systems and Networks Communications, 2006. ICSNC’06. International Conference
on, pages 27–27. IEEE, 2006.
6. Markus Lorch, Seth Proctor, Rebekah Lepro, Dennis Kafura, and Sumit Shah. First
experiences using xacml for access control in distributed systems. In Proceedings of
the 2003 ACM workshop on XML security, pages 25–37. ACM, 2003.
7. Alexander Pretschner, Florian Schütz, Christian Schaefer, and Thomas Walter. Policy evolution in distributed usage control. Electronic Notes in Theoretical Computer
Science, 244:109–123, 2009.
8. Frank Siebenlist. Obligation related snippets from the xacml-2 core specification,
May 2007.
9. Kevin Twidle. Ponder2project : Ponder wiki, 2011.
15