The policy rule language used in DTN is based on the Cassandra [2] policy rule language. The policy rule language is designed to support and use credentials for trust management. A credential is viewed as a constrained predicate, asserted by an entity called an issuer and held by an entity called a holder. In a rule, predicates are tagged with both the holder and issuer. Thus Bob♦OX .p(x ) is a rule that says Bob holds a predicate p(x ) asserted by Oxford, denoted by OX . The holder is postfixed by the symbol “♦” and the issuer by “.”.
Policy rule ::= (Head , Body Pred , Constraint ) Head head ::= E1♦E2.pred
Body Pred P ::= e1♦e2.pred
Credential cred ::= head ← c
Rule rule ::= cred
| head ← P1, . . . , Pn, c
Constraint c ∈ C
The prefix used here for the issuer is similar to the prefix used for roles in [107, 119]. In addition to the issuer prefix, the holder prefix used here is similar to the location prefix used in Cassandra. As in [2], the syntax for policy rules is as follows1:
Definition 6.2.1 (head, body, location, issuer, credential, policy)2 A policy rule is
made up of a prefixed head predicate, a list of prefixed body predicates, and constraints C . The prefixes ehol and eiss of a predicate ehol♦eiss.p(~e) are referred to as the holder and the
issuer of the predicate, respectively. The entity that issues a rule is called the issuer of the rule and the entity that holds the rule is called the holder of the rule. A rule of the form
1Definitions for Entities E , Role Names R and Action Names A are presented in [2]. 2This definition has been modified from [2].
head ← c is called a credential or credential rule. A policy rule that is not a credential rule has identical holder and issuer. Only credentials may have an issuer that differs from the holder: these represent credentials that are issued by foreign parties.
The typing rules for the above policy rule as specified in [2] are as follows:
Γ ` e : entity Γ ` e0: entity Γ ` pred Γ ` e♦e0.pred
Γ ` head Γ ` c Γ ` head ← c
Γ ` head Γ ` P1 · · · Γ ` Pn Γ ` c
Γ ` head ← P1, · · · , Pn, c
The first inference rule represents a rule head, which can be understood as follows: the proposition e♦e0.pred is from the set of propositions for a rule head if e, e0and pred are from
the same set of propositions where e, e0are entities. In simple terms, these rules express type definitions for the prepositions, e.g. e♦e0.pred receives two input variables of type entity and a variable of type pred .
The typing rules of predicates3 (pred ) as used in DTN are presented in Section 6.3.
A rule constraint that is true is often not shown, so also are the issuer and holder of a rule if they refer to the same entity. Similarly, the holder and/or issuer of a rule is not shown if it is identifiable from the context. For example,
D ♦D.p ←D♦D.p1, D ♦E .p2,
can be written as,
D .p ←D .p1, E .p2, E ♦F .p3
or
p ←p1, E .p2, E ♦F .p3
Since D is the holder and issuer of the rule, it is clear from the context that the rule is for D ’s domain and the rule can be found in D ’s policy4. Intuitively, this rule can be interpreted
as this:
D may have a service that can be accessed based on an assertion p. p can be deduced from D ’s policy if: p1 can be deduced from D ’s policy; the credential
asserting p2 issued by E is available, and that a request from E for a credential
asserting p3 issued by F exists.
From definition 6.2.1, p and p1 are assertions in D ’s policy rules since D is the issuer and
holder respectively. p2 is a credential rule assertion, since the issuer and holder are different,
i.e. E and D respectively. p3 is also a credential rule assertion where F is the issuer and E
is the holder.
Authorisation Function Description
assign(e.p(~e), r , p) implies that an entity with a credential asserting p(~e) issued by e is assigned role r that is granted permission p.
can activate(e, r ) implies entity e can activate role r , i.e e has been assigned r or can act with the capability of r .
has activated (e, r ) implies that entity e is currently acting with the capabil- ity of role r .
can invoke(e.p(~e), r ) implies an entity can invoke a trust contract for role r if the entity has a credential asserting p(~e) issued by e. has invoked (e, r ) implies entity e has currently invoked the trust contract
for role r .
can release cred (e1, e2.p(~e), e3) implies a credential asserting p(~e) issued by entity e2can
be released to e1 if e3 has invoked its trust contract with
e2.
Table 6.1: DTN Authorisation Functions (Predicates)