Motivation & Aims of FROST

It has long been recognized that we have entered an era in which the physical and perhaps legal possession of resources has become less important than the ability to access and use them. In the more recent past, data - in particular the so called Big Data - has become another precious resource, named by some as the “new oil” [1] that can fuel future economies. As in the case of physical resources, the value of Big Data also resides in the ability to access it, for example for machine learning and knowledge inference and transfer techniques.

It is less clear, though, how this shift from possession to access will manifest itself in social, commercial, and cultural ways. For example, some argue that people will increasingly seek and get access to “pre-paid experiences” [2]; others may predict that people will stop owning personal cars; and so forth. Such predictions are useful for policy makers, urban planners, and others. But what interests and motivates us here is the widely shared observation that industry verticals and service sectors are increasingly forced or incentivized to create and participate in digital ecosystems that push the established understanding of organizational boundaries. And that these emerging ecosystems will have common technological needs that have to be met regardless of whether particular trend predictions - such as the cessation of personal car ownership - will be correct or not.

Let us identify some forces and developments at play in shaping such shared ecosystems:

  • The digitization of resources and services, and their rich data streams, require a multitude of stakeholders to share access during the life cycles of resources and data.
  • Technological innovations such as blockchain challenge conventional ICT infrastructures that rely on a central authority in their access and service provision.
  • Inadequate ways of data sharing across organizational boundaries~–~the proverbial email attachment of cvs files due to reluctance of exposing database APIs to external parties.
  • Increased user demands on personalized, fine-grained services that make users active participants rather than passive consumers.
  • Changes in both data privacy regulation and privacy perception of users, who seek more control over their data and trust central authorities less.

Businesses can therefore create economic value through innovations that address the above shortcomings and also seize the above opportunities. But they can no longer do this in isolation, given that products and services will be facilitated through economic platforms that are shared by other commercial, potentially competing, players.

For example, the manufacturer of a car may wish to maintain a numerical passport on the vehicle and retain access to such data even when the car changes ownership. Similarly, a potential buyer of a used car may need to gain access to some of that passport information in order to evaluate the purchase prize. Or someone may want to lease the car from a dealer and also allow family members to use the car within some restrictions that she formulates.

It is clear that such a vision requires a supporting layer of technology through which such fine-grained access and delegation of access to resources and data can be securely articulated and enforced. We highlight this central requirement here:

Flexible But Contained Delegation: We need the ability for owners and users of data and resources to delegate basic access rights and to delegate (a) the ability to delegate such rights and (b) the ability to formulate rich access controls - and to do all of that with appropriate controls for such powerful delegation mechanisms.

This technology should also operate at a suitable level of abstraction so that it can easily be integrated with particular data fabrics and communication transport layers. Additionally, it should empower the owners and users of resources and data, rather than exposing them to the potential abuse of access and data by a central party.

Our Access-Control Policy Language FROST

Access Control Framework

The area of Access Control provides models, methods, and tools for controlling which agents - be they humans, mechanical devices or AIs - have access to what resources and under which circumstances. Many modern access-control architectures formulate the intended access control in a policy. One advantage of policy-based access control is that it supports the composition and mobility of controls - making it ideal for open and distributed systems.

Access control is a key security mechanism in enterprise systems, operating systems, physical buildings - to name a few prominent applications. An access-control policy may be somewhat static, e.g., saying which areas in an airport terminal are accessible to passengers who went through a security check already. However, such policies may also be more dynamic and allow for the delegation of access privileges to other agents. In our use case below, e.g., we see how the owner of a vehicle can grant a delivery person access to the trunk of the vehicle under certain conditions - say, within a given time interval. Access to the trunk then creates an obligation, to trigger a notification of the owner that access did indeed occur.

The conceptual architecture of FROST’s access-control framework is shown below. Device or resource owners manage policies in a policy-administration point (PAP). Policies are either stored within a Policy Store on an embedded device or sent as payload in a cybersecurity protocol, depending on constraints such as storage capacity of embedded clients. If needed, a Policy Retrieval Point (PRP) selects the appropriate policy for a submitted access request from the policy store.

The user communicates with the PAP and the resource via a secure channel, where server authentication is separated from user authentication. The user’s knowledge of the resource will be obtained through out-of-band means.

A request to access a resource can, in the abstract, be seen as a tuple

(user, resource, action, context)

where user is the machine, human, computer method or other entity making the request - known as the requester; resource is the object of this request; action is the concrete action requested (e.g. reading data, opening a trunk or editing a policy in a policy store); and context is supplied by the requester, system or environment and contains any contextual information (e.g. sensor readings) pertaining to and informing this request.

Such a request reaches the policy-decision point (PDP) that retrieves the appropriate policy for ruling on this request from the PRP in order to compute a decision and (optionally) a set of obligations; in the simplest form, a sole policy is stored in that store and said policy is evaluated for all issued requests. In addition to context provided by the requester, the PDP may consult policy-information points (PIP) to assist in the evaluation of the policy. The computed decision (notably grant or deny, but maybe logging the request, reporting a conflict or indicating a lack of a decision) and obligations are then communicated to the policy-enforcement point (PEP).

The task of the PEP is to enact that decision and to deal with operational complexities of the request, device interaction or input from the PDP. For example, the device may be unable to enact the requested action or the decision computed by the PDP may express a conflict or lack of knowledge. Our architecture focuses such operational issues and their resolution within the PEP, as these may also be device-specific. This makes the PDP more generic and reusable.

The remaining parts of this architecture illustrate the intended agnostic nature of this approach: the handling of policies in transit and at rest, as well as the administrative aspects such as logs of requests and decisions can be accommodated on a variety of data platforms - including distributed databases, blockchains, and cloud environments.

Supplied information for evaluating a policy is typically organized into attributes. The latter conveniently abstract subjects, resources, and contexts into those properties about them that should inform the decision of a policy made on a given request; see e.g. [3] for such a language designed for open systems. This attribute-based approach brings obvious advantages over conventional approaches such as access-control lists - to name scalability, composability, and intuitive formulation of policies.

It also aligns with privacy needs in identity management, e.g., the use of pseudonyms or support for the attribute “being of legal age” as an abstraction of a concrete identify. An attribute may be application-specific (e.g. the type of cargo in a container) or more universally known (e.g. the age of a user or the current time in UTC). The authentication and integrity checks of attribute values clearly need to be supported, whenever information sources allow for this.

Therefore, we base our approach to user-centric, distributed, and resilient access delegation on an extensible, attribute-based policy language called FROST. Extensibility merely reflects that specific use cases or application domains require domain-specific attributes whose syntax and semantics will then be plugged into our FROST language without affecting its own semantics, structure, and tool chain. The name FROST is an acronym that stands for:

  • F = Flexible, e.g. the freedom in the delegation of access and policy writing, and the agnostic view on back-ends.
  • R = Resilient, e.g. our use of cybersecurity protocols and other hardening mechanisms such as policy authentications.
  • O = Open, e.g. that the entire architecture can host an emerging ecosystem of activity, and that we plan to publish our approach as open-source technology.
  • S = Service-Enabling, e.g. for user-centric abilities to deliver goods, or as a transparent and resilient means of tracking parts in their life-cycle.
  • T = Trusted, e.g. through its combination of cybersecurity technology, validation tools, and support for secure and transparent audits.

Policy Language for FROST

The FROST language we propose may be seen as an instance of the language PBel and we here want to expressly acknowledge and apply the contributions made on PBel in the previously published, scientific, and peer-reviewed papers [4, 5]. A basic form of policy is captured in a rule. We propose two simple types of rules from which more complex policies can be formed:

grant if cond
deny if cond

where cond is a logical expression built from attributes, their values and comparisons, as well as logical operators.

To illustrate, we may specify an access-control rule:

grant if (object == vehicle) && (subject == vehicle.owner.daughter) &&
         (action == driveVehicle) &&
         (owner.daughter.isInsured == true) &&
         (0900 <= localTime) && (localTime <= 2000)

This rule implicitly refers to the request made by the daughter of the owner of the vehicle to drive that car. This rule applies only if the requested resource is that vehicle, the action is to drive that vehicle, and the requester is the daughter of the owner of that vehicle. In those circumstances, access is granted if the daughter is insured and the local time is between 9am and 8pm. The intuition is that this rule does not apply whenever its condition cond evaluates to false, including in cases in which the request is not of that type.

Policy Composition in Distributed Environments In open and distributed systems, rules may not always apply to a request. This suggests that we want support for a third outcome gap which states that the rule or policy has no opinion on the made request, a so called policy gap at which the policy is “undefined”. Semantically, a rule of form grant if cond is therefore really a shorthand for

grant if cond else undef

and a similar shorthand meaning applies to rules of form deny if cond.

The open and distributed nature of a system will often generate situations in which more than one rule may apply; an overall access-control policy may thus have evidence for grant as well as evidence for deny. Such an apparent conflict should be made explicit in the language itself, so that policy compositions can reflect and then appropriately act on it. This suggests a fourth value conflict as policy outcome, to denote such conflict as a result of policy evaluation.

It should be stressed that decisions gap and conflict are not enforceable as such by a PEP. But they are important to have and compute over for at least two reasons:

  • these values can facilitate policy composition, e.g. a policy that returns gap may be ignored within a composition with another policy, and
  • policy analysis can discover requests for which policies may have gaps or conflicts, to aid the verification of the correctness of policies, their refinements, and compositions.

The conceptual grammar for our access-control FROST language is depicted in below. The syntactic category _dec_ranges over all four possible policy decisions grant, deny, gap, and conflict. A term either refers to a constant (the set of constants may subsume keywords such as subject, action, and object}), an entity (a variable), a term indexed by an attribute or the application of an n-ary operator op to n many terms (where n >= 1). The choice of n-ary operators is in part domain-specific but in part also generic (e.g. operators for arithmetic). Note that terms are assumed to be well-typed given their intended meaning, which our implementation does reflect. The index operation allows us to write terms such as vehicle.owner.daughter where our type discipline will rule out conditions such as vehicle.owner.daughter < localTime.

dec     ::= grant | deny | undef | conflict
term    ::= constant | entity | op(term, . . . , term) | term.attribute
cond    ::= (term == term) | (term < term) | (term 6 term) | · · ·
            true | ¬cond | (cond && cond) | (cond || cond)
rule    ::= grant if cond | deny if cond
guard   ::= true | pol eval dec | (guard && guard)
pol     ::= dec | rule | case { [guard : pol] + [true : pol] }

The syntactic clause cond for conditions captures propositional logic with true denoting truth, ¬ negation, && conjunction, and || disjunction; its atomic expressions are obtained by relational operators applied to terms. The set of relational operators will contain generic ones such as those for equality and inequality (say over the integers) but also more domain-specific ones - e.g. a ternary one saying that an entity is the parent of two other entities. The category rule is defined as already discussed. A policy policy is either a constant policy dec, a rule rule or a case-policy.

Further note that the grammar for terms is extensible and may contain clauses that plug in domain-specific aspects. In an advanced digital manufacturing plant, e.g., we may be interested in a ternary operation on terms denoting that two specific robots which carry vehicle chassis on them approach the same team of workers.

For a more in-depth look at the FROST language checkout the yellow paper.


  1. SWINFEN-GREEN, J. Data is the new oil. Online article published in the Business Reporter (distributed with The Daily Telegraph), 27 February 2017. URL:
  2. RIFKIN , J. The Age of Access, first edition ed. Penguin, 31 August 2000.
  3. CRAMPTON, J., AND MORISSET, C. PTaCL: A Language for Attribute-Based Access Control in Open Systems. In Principles of Security and Trust - First International Conference, POST 2012, Held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2012, Tallinn, Estonia, March 24 - April 1, 2012, Proceedings (2012), pp. 390–409
  4. BRUNS, G., AND HUTH, M. Access-Control Policies via Belnap Logic: Effective and Efficient Composition and Analysis. In Proceedings of the 21st IEEE Computer Security Foundations Symposium, CSF 2008, Pittsburgh, Pennsylvania, USA, 23-25 June 2008 (2008), pp. 163–176
  5. BRUNS, G., AND HUTH, M. Access control via belnap logic Intuitive, expressive, and analyzable policy composition. ACM Trans. Inf. Syst. Secur. 14 , 1 (2011), 9:1–9:27