9 Autorisierungspolicies  (Authorization   Policies)   definieren,   was   einem Manager erlaubt (positive) oder verboten (negative) wird. Sie beschränken die  Informationen,  die  dem  Manager  sichtbar  gemacht  werden  und  die Methoden, auf die sie zugreifen können. Verpflichtungspolicies (Obligation Policies)  definieren,  was  ein  Manager zu tun hat (positive) oder unterlassen (negative) muss. Dabei unterscheidet [Sloman] weiter: Einfache  Aktions-basierte  Autorisierungspolicies  (Activity  Based)  be- stehen aus Subjekt, Ziel und Aktion: „John darf die Datei F1 lesen.“ (Positive) „John  darf  die  Datei  F3  weder  lesen,  noch  schreiben  oder  ausführen.“ (Negative) „Jedes Objekt darf die Datei F1 lesen.“ (Positive) „Kein Objekt darf die Datei F3 schreiben.“ (Negative) Die Status-basierte Autorisierungspolicy (State Based) enthält noch eine Aussage  über  den  Objektstatus.  Das  ist  üblich  zum  Beispiel  bei  der Zugriffskontrolle  auf  Datenbanken  oder  bei  der  Sicherheitskontrolle  kriti- scher Systeme: „John darf Personal-Einträge lesen, mit Gehaltsstufe <10“ „Der  Operator darf die  Aktion schließe_Ventil  nicht ausführen,  wenn  Re- aktor.Temp > 100.“ „Manager mit derzeitiger_Standort=Planungsbüro dürfen  die  Expansions- pläne lesen.“ Einfache  Aktions-basierte  Verpflichtungspolicies  (Activity  Based)  ent- halten  Subjekt,  Ziel  und  Aktion,  können  aber  auch  zusätzlich  ein  Event definieren, dass die Aktion auslöst: „Der  Unternehmensleiter  muss  die  Besitztümer  des  Unternehmens  XYZ schützen.“ (Positve) „Wenn error_count > 100, muss der Monitoring Agent eine Warnmeldung an den Operator schicken.“ (Positive, event triggered) „Der Standby-Manager darf keine Kontrolloperationen ausführen.“ (Nega- tive) „Angestellte dürfen keine Presseauskünfte über das Unternehmen geben“ (Negative) Eine  Status-basierte  Verpflichtungspolicy  (State  Based)  enthält  Aussagen über  den  Objektstatus.  Dass  kann  in  einigen  Fällen  benutzt  werden,  die Subjekte oder Zielobjekte auszuwählen, auf die die Policy angewandt wird. „Controller müssen die Kocher-Temperatur so regulieren,  dass  50  <  boi- ler.temp < 100.“ (Positive obligation in terms of target state) „Manager  müssen  Verbindungen  neu  aufbauen,  wenn  error_count  >  50“ (Positive obligation on selected targets based on state) „Manager mit Version < 1.5 dürfen den Diagnose Test A500 nicht ausfüh- ren“ (Negative obligation applying to selected subjects) Die Arbeit Slomans ist sehr abstrakt, und bringt uns der tatsächlichen Aus- führung des Verfeinerungsprozesses nur bedingt näher. Schließlich sieht er gar  keinen  Verfeinerungsprozess,  sondern  die  direkte  Formulierung  der Policy- Spezifikationssprache „Ponder“