Policy-Governed Information Exchange

Stage 1 — a human writes the policy, in something close to English

Policies are authored in SBVR Structured English, the controlled-English notation of the Object Management Group’s Semantics of Business Vocabulary and Business Rules standard. It is near-natural English with four marked-up token types — term (a noun concept), Name (an individual), verb (part of a fact type), and reserved keywords such as it is obligatory that, every, at most one. A security officer can read it. That is the whole point of choosing it.

To be exact about what is ours and what is not: SBVR is the OMG’s standard, not VIStology’s. We did not write it, we did not contribute to it, and we support a subset of the Structured English notation. We built the translator. Here is an illustration in that notation — our sentence, written to show the shape, not a quotation, because the paper describes the pipeline but never prints an XMPP policy in SBVR SE and we will not manufacture one and attribute it to them:

It is prohibited that a user sends a message that has_classification Secret to a user that has_clearance Confidential.

And the reason it cannot stop there, in the paper’s own words: “SBVR is meant to be a high level language and is not executable, so SBVR is most useful when translated into a lower level executable language like BaseVISor Rule Language (BVR), as we have done.”

Stages 2 and 3 — the sentence is compiled, not re-typed

The translation is a model-to-model transformation, not a hand-written parser that someone has to maintain in step with the vocabulary:

The companion CogSIMA paper names the mechanism outright — “For the automatic translation from SBVR to BaseVISor, we use ATL (Atlas Transformation Language)” — and describes the metamodels behind it: “We have created a metamodel for BaseVISor and modified the SBVR metamodel used in a UML-to-SBVR effort…. We then wrote ATL rules to map from SBVR rules expressed in Structured English to BaseVISor rules.” ATL is the Eclipse community’s transformation language; the metamodel for BVR is ours.

One honest note, because a reviewer will ask. The paper claims the mapping is semantics-preserving. It offers no proof, no test suite and no coverage statement for that claim, and we will not upgrade “preserving its semantics” into “provably correct translation.”

Stage 4 — execution, and the awkward fact that RDF has no “must”

The engine is BaseVISor, ours: “The BaseVISor engine implements OWL 2 RL inference rules in BVR and supports XML Schema Data Types.” But a policy language needs to say may, must and must not, and the engine’s substrate cannot express them:

You cannot write Obligatory(p) in RDF. Modal logic wants operators over propositions; RDF gives you triples and nothing else. The move that resolves it is the most distinctive piece of engineering in this cluster — reify the modality as a class hierarchy over actions, and let a stock OWL 2 RL reasoner do the work: “we treat Actions as a class that can be subdivided into Permissible (may), Omissible (may not), Optional (may and may not), Obligatory (must) and Prohibited (must not) subclasses.”

Obligatory actions are a subclass of Permissible (if you must, you may); Prohibited is a subclass of Omissible (if you must not, it is not the case that you may); Optional is the intersection of Permissible and Omissible. And two disjointness axioms carry the actual logic: Obligatory and Omissible are disjoint, Prohibited and Permissible are disjoint. Which buys the thing you actually want from a formal policy system — a contradiction that announces itself rather than failing silently: “We can infer a contradiction if an action is asserted to be both obligatory and omissible, however.”

Necessity and possibility are handled structurally in the same ontology — necessity as a subclass relation, possibility as the deliberate absence of a disjointness axiom. Which is worth pausing on, because it is the argument for doing any of this in OWL at all: “Ontologies, after all, express constraints on how the world can be.”

The ontologies underneath are not invented from nothing. The Upper Security Policy ontology — “It was derived by starting with the Naval Research Laboratory’s (NRL) Security Ontology…” — has a Policy made of Rules with a SecurityPurpose, governing Operations that are aligned owl:sameAs with UCore-SL Acts, the OWL rendering of the messaging format adopted for information sharing across the defense and intelligence communities. Security markings come from a third party’s ISM ontology of the Intelligence Community’s own IC-ISM markings; what we added were the ordering axioms it lacked, so that a clearance actually dominates the ones below it.

Enforcement: a reasoner in the message path

Because there is nowhere central to put the guard, the guard goes at every server — as a plugin: “we developed an Openfire plugin that intercepts incoming and outgoing XMPP stanzas.” What happens next is worth stating mechanically, because it is the part that makes the thesis operational:

“PolVISor analyzes the stanza and returns to the plugin a decision to allow or deny the stanza. We chose to implement a deny-overrides approach, where if any applicable rule denies the stanza, the stanza is denied.” It is a whitelist: everything not explicitly allowed is denied. And the disposition of a violating message is blunt — “If the stanza is denied, the plugin drops the stanza and the server does not see it.” Dropped, silently, before the server ever processes it. The paper notes the plugin could be changed to log instead. It was not, and we do not claim an audit trail we did not build.

Before XMPP: one policy, one closed world

The machinery that makes multi-policy reasoning possible at all predates the XMPP system by three years, and it is a small, precise piece of engineering that is easy to overstate — so here it is exactly. At IEEE POLICY 2008 we presented an extended BaseVISor: “To use BaseVISor for policy reasoning we extended it with three procedural attachments that implement the log:semantics, log:includes and log:notIncludes elements of N3 rules…”

Those are Berners-Lee’s N3 builtins, implemented as BaseVISor procedural attachments. log:semantics takes a document URI, loads it into its own Rete network, runs it to closure, and hands the resulting graph back bound to a rule variable; log:includes and log:notIncludes then test containment between whole graphs. The consequence:

One policy is one closed world. “The closed world defined by a set of facts can be thought of as a ‘context’ in which reasoning is to occur” — and reconciling policies means reasoning across several closed worlds at once, which is precisely what the three builtins make possible.

Now the fence around that paper, because it is a trap and we would rather trip it ourselves than have a reviewer do it. It is a three-page demonstration abstract, written in the future tense — “This demonstration will show the practical application of a formal reasoning engine for both policy invocation and policy reconciliation.” Will show. The paper never reports that the demonstration ran. So: the engineering is past tense and citable — we extended the engine, and the source policies “have been translated… via a Python script” (MIT’s REIN policies; the Ismene policies were translated by hand, because they are not Horn clauses). The work was presented at IEEE POLICY 2008. It was not proven there. Three further facts a reader deserves: the extension is not deontic logic (the words deontic, obligation, permission and prohibition appear zero times in it); the paper contains no conflict detection — the word conflict never occurs; and the policy ontology it uses is MIT’s REIN, which we adopted and extended, along with two demonstration scenarios borrowed from other people’s papers. What is ours in it is the engine, the three attachments, the ontology extensions and the translations.

And the limit, which the authors state better than we could

Formal reasoning does not tell you whether a report is true. It tells you what follows from what you have, under rules you can read. The one rule the paper writes down is a structural fraud check — a user who forges the provenance of a retweet is downgraded to E: Unreliable — and even that is introduced hypothetically: “A rule can be asserted, in a semantic web rule language such as BaseVISor rule language…” Can be asserted. So we say sketched, not “implemented a rule base.”

The rest of the fence, in one breath. The work is a position paper — its title starts with “Toward” and the authors honor that: “We illustrated our approach with example tweets about a tragic incident in Libya.” The illustration is 20 hand-picked messages. There is no evaluation, no ground truth, no baseline, no accuracy figure. The paper names no sponsor and we claim none for it. And the pieces it stands on — the tweet-to-RDF conversion service, the centrality metric, the text-similarity measure — are other people’s work, reused with credit. What is ours is the mapping of a computable metric onto a doctrinal ladder, the rule pipeline that applies it, and the critique of the doctrine.