One may think about the security policy associated with a protected resource as a set of operations which a defined set of principals is allowed to perform on the target resource, and optional constraints placed on the granted operations. For example, a system administrator can define the following security policy to govern access to a printer: "Joe Smith and members of Department1 are allowed to print documents Monday through Friday, from 9:00AM to 6:00PM". This policy can be described by an ACL mechanism, where for each resource, a list of valid entities is granted a set of access rights. The same policy can be implemented using a capability mechanism. However, traditional ACL and capability abstractions should be extended to allow conditional restrictions on access rights.
Therefore, in implementing a policy, it should be possible to
define:
1) access identity
2) grantor identity
3) a set of access rights
4) a set of restrictions
Policy language represents a sequence of tokens. Each token consists of:
Defines the type of the token. Tokens of the same type have the same authorization semantics.
It indicates the authority responsible for defining the value within the token type.
The value of the token. Its syntax is determined by the token type. The name space for the value is defined by the Defining Authority field.
The rest of this section describes the user-level representation of the policy language tokens, which can be used to implement both ACLs and capabilities. A more precise syntax is given in the Appendix.