1. Specification of Usage Control
Requirements
Bibek Shrestha
bibek.shrestha@tum.de

2. Table of Contents
1.
2.
3.
4.
5.
6.
7.
Usage Control?
Obligation Specification Language (OSL)
Brief introduction to another Policy Language : Ponder.
Comparison between OSL and Ponder.
Analysis: compare OSL to other security languages
Conclusion.
Questions.

3. Concerns for data distribution
Once data is distributed, control is limited.
Concerns for Data Providers:
Privacy,
Intellectual Property,
Data Security,
Data Sender and Receiver need to agree to conditions.

4. Conditions for data distribution
Data distribution on two grounds
Conditions that should already satisfy before data is given to a
receiver : Provisions
and
Conditions on future use of data : Obligations
Usage Control deals with Obligations

5. What is Usage Control?
Usage Control deals with
who and how,
must or must not,
allowed or not allowed,
to use the data after distribution.
Encompasses
Specification of conditions and control enforcement
mechanisms

6. Usage control requirements
Existing literature on notions of
Usage Control.
But,
Separately studied,
Closed source implementations,
Not defined precisely,
Lack of holistic system model for Usage Control.

7. Focus
Specification of conditions
Not into: control enforcement mechanisms
Languages Reviewed
Usage Control Specific:
Obligation Specification Language (OSL)
Another Policy Language
Policy

8. Obligation Specification Language does:
Analysis of policies
If set of mechanisms enforces a given policy?
Is a policy free of contradiction?
General purpose specification language for Usage Control
Combine "must" and "may" modality
Example: Allows DRM mechanisms for enforcing privacy policies
Interoperability between different DRM Mechanisms
and give a formal semantics to these languages

9. Obligation Specification Language
First order linear temporal logic
Formalized in 'Z'

10. OSL : Time Steps and Traces
Policies act upon a long period of time, which is divided into
discrete time portions called time steps.
A trace is the combination of these time steps as a whole. At
each time step of a trace, multiple events can happen.

11. OSL : Events
EventDecl Example:
{
(play, usage, {(object, ObjID), (device, DevID)}),
(backup, usage, {(object, ObjID), (device, DevID)}),
}
● Used interchangeably with action.
● Has (name, type {parameter set})
● Event type can be either usage (usage of data) or other
(signalling or messaging or similar events)
● Parameters specify extra details about the event (Eg: data
item the event is performed on, etc)

12. OSL : Indexed Events
An event can be as long as one or more TimeSteps.
Efst - Indexed event with index start
Eall - All indexed events
with index ongoing
Eall
1st
ongoing
ongoing
ongoing
ongoing
start Efst
...

13. OSL : Time Steps and Traces
(Alice, repmax(5, Efst((play, {(object, mov)}))))
mov can be played for 5 times at max
(Alice, repmax(5, Eall((play, {(object, mov)}))))
mov must not be played more than 5 time steps
Note the difference with the first example

14. OSL : Obligation formula
{
(Alice, permitonlyevname({play, backup}, {(object, mov)})),
(Alice, repmax(5, Eall((play, {(object, mov)})))),
(Alice, repmax(1, Efst((backup, {(object, mov)})))),
}
Each line is an obligation formula ( SubjectID x Φ )
Obligation formula are of two different forms:
1. Action Requirements (Mandatory Actions)
2. Usage Restrictions (Prohibiting Conditions)

15. OSL : Conditions in obligation formula
Circumstances under which the usage restrictions or action
requirements apply.

16. OSL : Operators (Informal Description)
Logical Operators: not(x), and(x,y), or(x,y), implies(x,y)
Eg: (Alice, not( Efst( (play, {Object, song.mp3}) ) ))
Temporal Operators: until(x,y), after(n,x), during(n,x), within(n,x)
Eg: (Alice, after( 5, Efst(...) ) )
Cardinality Operators: replim(i,m,n,x), repuntil(n,x,y), repmax(n,x)
Eg: (Alice, replim(20, 5, 30, Efst ((playCommercial , {(stream, s)}))) )
Permit Operators: permitonlyevname(es,ps), permitonlyparam(pv,pn,es,ps)
Eg: (Alice, permitonlyevname({play, backup}, {(object, mov)}))

17. OSL : Syntax and Example
OSLPolicy = {EventDecl} x {OblFormula}
OblFormula = SubjectID x Φ
Example OSLPolicy
({
(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, repmax(1, Efst((backup, {(object, mov)})))),
}

18. OSL : Translation from OSL to RELs
● OSL supports must and may modalities.
● OSL more expressive than other RELs like XrML and ODRL
● Translation from OSL to ODRL and viceversa done.
Why? Three main reasons:
1. Give semantics to XrML, ODRL or any other RELs.
2. Intermediate translation language between RELs.
3. Utilize enforcement mechanisms existing for RELs.

19. OSL : Translation ODRLc to OSL
● A subset of Open Digital Rights Language (ODRL) called
ODRLcompact (ODRLc) chosen that does not include
concepts outside the scope of OSL.
● ODRLc specify rights which are of may modality.
● All ODRLc licenses can be expressed in OSL.

20. OSL : Translation OSL to ODRLc
● Not all OSL expressions can be expressed in OSL.
● Difficult to identify which subset can be translated.
● Pragmatic approach : Pattern matching used
(subid, repmax(n, Efst(ue))) to <count> expressions.
● Syntactic pattern matching requires obligations to be in an
implicitly defined canonical form. Slight variations will result
in a mismatch.
● Difficult and needs improvement.

21. Ponder
October 2000
Strongly typed, Object Oriented Language.
Used for Policy Specification.
Policies does not clearly focus on Provisions and Obligations
Strong focus on Policy Expression, Management and
Organization with Roles and Relationships.
Declarative language, leaves implementation for other
programming languages.

22. Problems addressed by Ponder
1. Declare delegatable policies.
2. Support policies relating to large collection of objects,
possibly millions.
3. Composite policies that group basic policies according to
roles, organizational units, etc.
4. Analyze conflicting policies.
5. Simple extension of policies with Inheritance.

23. Ponder : Policy definition
● A policy is collection of one or many rules.
● Policy is defined as methods in interface definition language.
Example:

24. Ponder : Policy type and instance
● Policy type is a template.
● A policy instance is derived from a Policy type, also can be
defined directly.
● Instance defines the real policy.
● Policy Type and Policy Instance are analogous to Class and
Object Instance in Object oriented languages.

25. Ponder : Policy Categorization
● Basic Policies
Contains only policy elements, no children policies.
○ Authorization Policies
○ Obligation Policies
○ Refrain Policies
○ Delegation Policies
● Composite Policies
Contains children policies. Main idea is organization.
○ Group, Roles, Relationships, Management Structures

26. Ponder : Obligation Policies
Specify actions that must be performed on a set of target objects
when an event occur.
Example
states that when Steven’s temperature exceeds 37 degrees,
nurse takes two actions: first she administers analgesics
followed by second manually recording his temperature.

27. Ponder : Composite Policies
● Simplify specification and organization of policies from small to
large distributed systems.
● Provide a syntactic scope for child policies who share common
declarations.
Types
● Groups
● Roles
● Relationships
● Management Structures

28. Discussion
Comparison of dedicated Usage Control Specification Language
(OSL) to a general Policy Language (Ponder) in terms of:
● Syntax and semantics consideration
● Implementation
● Policy organization
● Ability to describe temporal conditions

29. Discussion : Syntax and Semantics
OSL
Formalized in Z, well defined syntax and semantics. XML
representation available. Easy to understand.
Ponder
Well defined Syntax and Semantics. Not described on a Formal
Language. Object oriented and declarative in nature, supports
inheritance for re-use.

30. Discussion : Implementation
OSL
Representation on abstract level. Event names, Parameters have
to be mapped to actual implementation. Pro - provide
generalization, con - Extra effort for mapping.
Ponder
Although being declarative, it models the actual system more
closely.

31. Discussion : Organization
OSL
Less concerned about organization and management. Focus is
on expression of requirements than administration of policies.
Main focus - Usage Control.
Ponder
Contains a lot of policy and resource management tasks in its
specifications.

32. Discussion : Work with Temporal Conditions
OSL
Temporal conditions are one of the primary concerns as the
norm of time steps as well as temporal operators: until, after,
during along with other operators allow expressing complex
time based conditions.
Ponder
Contains Timer library that allows to specify time-point events,
repeated events based on duration and repeated events at
specific time-points. Lacks the norm of time-steps to perform
cardinal operations, eg: Movie can be viewed only 10 times.

33. Conclusion
● Main challenge : Usage control covers huge scope, develop a
general purpose language that allows to express
requirements of this huge scope.
● Different approaches found in the languages under study.
● Different factors affect language adoption : ease of
expression, ease of implementation, generalization and
ability to adapt to changes.
● OSL looks to be highly focussed in Usage Control and future
developments should make it more feature rich, means
wider adoption by the industry.

34. Questions?

35. More challenges
Take care of
● Data roles : Owners, Carriers, Consumers
● Network and Medium of data flow
● Data types : Physical Object, Digital Object, etc
● Restriction Types : Permission, Restrictions
● Restriction Mechanisms : Preventive control mechanisms vs
Observation mechanisms
● etc

36. Examples

37. ODRL formalization
http://arxiv.org/pdf/cs.LO/0601085.pdf
ODRL and MPEG-21 Translation
http://odrl.net/workshop2004/paper/odrl-polo-paper.pdf