Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Specification of Usage Control Requirements
Bibek Shrestha
Technische Universität München, Germany
bibek.shrestha@tum.de

A...
inter-operable with existing policy languages, e) inter-operable with other existing languages and f) can be represented i...
that specify mandatory actions that must be executed either unconditionally or
after specific usage has been performed are ...
Indexed Events help to specify restrictions on accumulated usage times over
multiple steps of a trace. An indexed event is...
Operators The operators not, and , or and implies have the same semantics as
their prepositional counterparts ¬ , ∧, ∨ and...
permitonlyevname({play, pause, stop}, {(object, m)})
states that the movie m can only be played, paused or stopped. All ot...
provides an additional formal semantics to previously undone parts. The rational
to define formal semantics for RELs is tha...
While developing Ponder, the authors identified the following requirements
with policy languages [2]: a) Allow declaration ...
Basic Policies A basic policy contains one ore more policy elements. Basic
policies cannot contain other policies. Policy ...
Obligation actions are specified in an obligation action list separated with
concurrency operators indicating whether the a...
Delegation Policies Delegation policies specify which positive or negative authorization policies can be delegated by a su...
subject
target
action

/dept/users/staff ;
/dept/computers/research ;
login ; }

inst oblig loginActions {
subject s = /dep...
a mechanism to perform the mapping. The authors recognize this as a future
work [3].
OSL also does not provide policy orga...
5

Related Work

eXtensible Access Control Markup Language (XACML) XACML is an attributed
based access control policy lang...
it was designed for these environments. Future work [4] on OSL is expected to
make it more feature rich and increase its a...
Upcoming SlideShare
Loading in …5
×

Tum seminar specification of usage control requirements

443 views

Published on

Published in: Education, Technology, Business
  • Be the first to comment

  • Be the first to like this

Tum seminar specification of usage control requirements

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

×