# $Date: 2007-07-26 18:05:42 -0400 (Thu, 26 Jul 2007) $
# $Revision: 3591 $
# $Author: lkagal $

ReiPlus Specifications
----------------------

1. Policy: A policy includes a list of deontic rules and a context
used to define the policy domain. The context is a set of conditions
over attributes of entities, resources, and the environment in the
domain. Only when the context is active (conditions are satisfied) can
the deontic rules be applied.

E.g. a policy for verizon employees

VPrivacyPolicy a policy:Policy;
    policy:context { ACTOR a v:VerizonEmployee };
    policy:grants AccessToDataPolicy;
                    UseOfDataPolicy.

Also, associated with policy is  

defaultBehavior: this defines whether everything allowed/prohibited is
specified or assumed. 

E.g. Everything that is not explicitly permitted is prohibited

VPrivacyPolicy policy:defaultBehavior metapolicy:ExplicitPermImplicitProh.

defaultModality: specifies the modality (positive or negative) that
holds precedence in case of conflict.

E.g. In case of conflict, rules of negative modality (Prohibitions and
Dispensations) have priority over rules of positive modality

VPrivacyPolicy policy:defaultModality metapolicy:NegativeModalityPrecedence

rulePriority: is used to set priorities between potentially
conflicting rules

grants: A granting associates a set of constraints with a deontic
object to form a policy rule. This allows reuse of deontic objects
from different policies with different constraints and actors.

E.g. adding a granting to the above policy using an additional constraint

VPrivacyPolicy: a policy:Policy;
    policy:context { ACTOR is v:VerizonEmployee };
    policy:grants [ a policy:Granting; policy:deontic SomePolicy; policy:to ACTOR; policy:requirement { ACTOR a CustomerServiceAgent; DATA a CustomerData }].


3. DeonticObject: is used to create permissions, prohibitions,
obligations and dispensations that govern the behavior of entities in
the policy domain. It includes constructs for describing what action
(or set of actions) the deontic is described over, who the potential
actor (or set of actors) of the action is and under what conditions is
the deontic object is applicable.

E.g. Access to databases containing customer information is limited to
employees who need it to perform their jobs

AccessToDataPolicy a deontic:Permission;
      deontic:actor ACTOR;
      deontic:action ACTION;
      deontic:constraint {ACTOR v:responsiblity ACTION. ACTION v:data DATA. DATA v:in CustomerDB}.

attributes
sanction
provision

4. Action: is the basic construct of Rei policies. 

QueryDB a action:Action;
    action:actor JoeSmith;
    action:target DB123;
    action:precondition { what must be true before the action can be performed };
    action:effect { what is the state of the world after the action is performed }.


Modeling E2ESA Policies
-----------------------

In order to model the E2ESA privacy policies using ReiPlus

- develop a detailed action ontology. Purposes are high level
"actions", and associated with each action is a purpose, its super
class

E.g.    DataAction
        - law-enforcement
                - criminal-law-enforcement
                        - ct-criminal-law-enforcement
                - civil-law-enforcement
        - intelligence
        - counter-intelligence
        - counter-terrorism
                - ct-criminal-law-enforcement

- Policies must distinguish between access of data and use of data

    - If policy is only about data being used, then use is modeled by
    the condition associated with the action

    - If policy is about data being accessed, the future_use is
    asserted as a future permission/prohibition after data is accessed

   - We define two high level actions: AccessDataAction and
   UseDataAction

E.g. You can only use data in a SOR according to your
responsibilities, and the purpose and routine uses of the SOR. This
does not restrict you from ACCESSING the data, only talks about how it
can be USED.

AccessToDataPolicy a deontic:Permission
      deontic:actor ACTOR;
      deontic:action ACTION;
      deontic:constraint { ACTOR a GovEmployee. ACTION a DataAccessAction. ACTIO data DATA. DATA sor SOR. };
      future-use UseOfDataPolicy.

UseOfDataPolicy a deontic:Permission
      deontic:actor ACTOR;
      deontic:action ACTION;
      deontic:constraint { ACTOR a GovEmployee. ACTION data DATA. [] a AppropriateUse; actor ACTOR; data DATA }.

{ ACTION data DATA.
  DATA CollectedFor PURPOSE.
  ACTION is PURPOSE. (or has PURPOSE depending on how the action hierarchy is define)
   ACTOR Responsibility RESP,
   PURPOSE is RESP
} => { [] a AppropriateUse; actor ACTOR; data DATA }.

Also, possible to have just usage policies without being linked to
access policies.

E.g. HIPAA Disclosure I: A covered entity may not disclose or use
protected health information without the authorization of the person
who is the subject of the information or the person's representative.

UseOrDiscloseHealthInfoPolicy a deontic:Permission
      deontic:actor ACTOR;
      deontic:action ACTION;
      deontic:constraint { ACTOR a CoveredEntity. ACTION data [ a HeathInfo; patient PATIENT ]. PATIENT permitted [ ACTOR use DATA ] }.

Look at Annotated Logics as an approach to semi formalize this work.