Language-based security approaches to access control and information flow control must at some point rely on a language for expressing policies. However there will in general be several choices for the correct policy language for any given application, and several choices for the implementation of a policy language in a given domain. This article considers an approach to implementing the policy language at the application level, relying on trusted cryptographic libraries whose interface security guarantees are used to verify the correctness of the policy language implementation. using these libraries, they are implicitly enforcing security policies for the data is being exchanged. This policy is often unstated, or only stated informally in program comments. If these security policies are stated in a suitably formal policy language, then adherence to these policies may be verified, often using automatic or semiautomatic techniques.One particular approach, exemplified by language-based security, is to express the policies in a policy language that is incorporated into the type system. Typechecking then provides an avenue for checking the correct manipulation of data according to the security policies expressed in program types. These security policies can then be related to the cryptographic libraries used to secure network communications, via typed APIs for cryptographic operations that express the security guarantees these operations are intended to enforce (e.g., encryption for secrecy, digital signing for integrity).An obvious issue that needs to be addressed is the form of the policy language that is used in the type system to express security policies. The problem is that any policy language will inevitably (and in fact fairly quickly) run into applications for which is it inadequate. For example, the JIF language [26,25,28] incorporates a policy language based on sets of access control lists (ACLs), augmented with a form of delegation of principal rights. An obvious extension to consider for the JIF policy language is some form of role-based access control (RBAC), including some notion of delegation of role-based rights [7]. But even if one just considers the extension with role-based access control, there are many variations on RBAC that could be added. The RT family of languages by Li et al [22,23] is a good candidate for such a policy language, since it appears to be the closest to a "universal" language for distributed RBAC (i.e., with delegation). But there are numerous variations in the RT family, and presumably more variations still to be proposed. Furthermore there are new policy languages being constantly proposed that go beyond RBAC and delegation, such as policy languages where principals share control of access to resources.Rather than committing to a single policy language for all applications, an "endto-end" approach would allow individual applications to define their own policy languages, or to choose from a library of possible policy languages. Rather than committing to a particular policy la...