Various authorisation rules can be used to enforce DTN security policies. These rules are defined as follows:
Rule 1 : An assign-role rule is of the form:
assign(e.p(~e), r , p) ← has invoked (e, r ), p ∈ permissions(r )
where e, r , p are entity, role and permission respectively.
This rule implies that an entity that holds a credential asserting p(~e) issued by e can be assigned role r granted with permission p. This access control rule says that an entity that has invoked role r is allowed permission p. A permission is a set of actions permitted on an object or resource and permissions(r : role) is a mapping function based on RP (role) mapping function described in Section 5.1. This rule can can also be written as:
assign(e2.can activate(e, r2), r , obj (acts)) ←
has invoked (e2, r ),
acts ∈ {act1, ..., actn},
obj (acts) ∈ permissions(r )
where e, e2 are entities, r , r2 are roles and act1, ..., actn are actions associated with object,
obj .
The rule implies that entity e can be assigned role r and granted permission obj (acts), if firstly a credential asserting that e has r2 issued by e2 is made available, secondly if e2 has
already invoked a contract for role r . In a scenario where e2is a local entity and r2is in the
Rule 2 : An entity-role activation rule is of the form:
can activate(e, r ) ← has activated (e, r2).
where e is an entity, and r , r2 are roles.
This rule implies that an entity e can act with the capabilities of role r if the entity has first activated role r2. Often, can activate is used as a predicate in a credential rule asserting a
role is assigned to an entity.
Rule 3 : An entity-role active rule is of the form: has activated (e, r ) ← c
where e, r are entity and role respectively.
This rule is true if entity e has role r active. If true, the rule suggests that e is a mem- ber of role r and has presented a credential asserting r . The rule can also be expressed as has activated (e, r ) ← isActive(e, r ), where isActive(e, r ) is a mapping function that returns true if in r ’s domain, e has role r active. Basically, isActive is a state checker that can be used to check the state of a role. The has activated predicate is often used with can activate(e, r ) predicate to decide if an entity has a role active and if not, whether it is allowed to activate the role assuming no other constraints exist.
Rule 4 : A credential-role invocation rule is of the form: can invoke(e.p(~e), r ) ← c
where e, r, c are an entity, role and constraint respectively.
This rule implies that an entity with a credential asserting p(~e) issued by e can invoke the contract for role r if the constraint c can be deduced to be true. The rule can also be expressed as:
can invoke(e1.can activate(e2, r1), r ) ←
tc(r1) = r
where e1, e2 are entities, r , r1 are roles and tc() is a trust contract mapping function. For
an entity variable.
This rule says e2 can invoke a contract for role r if the credential asserting e2 has received
r1 issued by e1. This rule can be deduced to be true if a trust contract exists that maps r1
to r . tc(credential ) is used as the rule constraint. Rule 5 : An entity has invoked rule is of the form:
has invoked (e, r ) ← c
where e, r, c are an entity, role and constraint respectively.
The rule can also be expressed as has invoked (e, r ) ← inSession(e, r ), where inSession() is a mapping function that returns true if in the current session state, a trust contract for role r has already been invoked by e. This is a rule that can show if a potentially remote entity has been assigned a role based on a trust contract. Like isActive, inSession is a state checker that can be used to check the invocation state of a contract. inSession() is used as the rule constraint.
Rule 6 : An entity can receive credential rule is of the form:
can release cred (e1, e2.p( ~e1), e3) ← e2.p( ~e2), c
where e1, e2, e3 are entities, p( ~e1), p( ~e2) are rule predicates and c a constraint.
The rule says entity e1can delegate a credential that asserts p( ~e1) issued by e2if p( ~e2) and
c can be deduced. The rule can also be expressed as:
can release cred (e1, e2.can activate(e1, r ), e3) ←
e2.has invoked (e3, r ),
e1∈ COT (e2)
This rule says entity e1 can be delegated a credential issued by entity e2 which asserts that
r . COT (e : entity) is a mapping function that returns the set of entities in an entity’s COT. This rule can also be written as:
can release cred (e1, e2.can activate(e1, r ), e3) ←
e2.has activated (e3, r ),
e1∈ COT (e2)
where e1, e2, e3 are entities and r is a role.
This rule is same as the first rule except that in this case, entities e2 and e3 are from the
same local domain, and in some cases e2 and e3 can refer to the same entity. The example
in Section 6.5 makes this distinction clear. However, it should be noted that a foreign entity should not be able to activate a local role, they can only invoke a contract for a local role. Likewise, a local entity should not be able invoke a contract for a local role rather they should activate a local role.
Datalog [166] examples of these rules are listed in Appendix C.