Re: Policies & SIMILE Research Drivers...

Last week I wrote:

> As I noted during our call a few minutes ago, the
> "policy" related sections of the "SIMILE Research
> Drivers" document,
> http://purl.oclc.org/NET/SIMILE_Drivers_0.24, are quite thin.
>
> I can imagine many things to put there...

JSE: As was pointed out by Eric today, there has been *some* work re: "policy
expression" & RDF --- <indecs> and Creative Commons are two excellent
examples. HOWEVER, the level of policy expression that these present is *not*
the level that I am concerned with, or at least is not complete. Although
<indecs> and rights metadata in general present a great set of use cases for
"semantic interoperability," but I am also concerned with what might be called
"enforceable" policy specifications. Policy expression and management within
SIMILE should not be done out-of-band.

POLICY LEVELS: One should always think about policies in terms of multiple
levels; the Ponder group at Imperial College makes a great argument for the
following three-level model:

. High-level "abstract" policies (also referred to as management goals), which
can be business goals, service level agreements, trust relationships or even
natural language statements. High-level abstract policies are not enforceable
and their realisation involves refining them into one of the other two policy
levels, which is outside the scope of this thesis. To some extent, Creative
Commons "policies" live in part at this level, although nothing precludes them
from being closer to "specification" level (below).

. Specification-level policies, sometimes referred to as "network-level" or
"business-level" policies (or even high-level policies by some researchers).
These are the policies specified by a human administrator to provide
abstractions for low-level policies but in a precise format. These policies
relate to specific services, or objects and their interpretation can be
automated.

. "Low-level" policies or configurations such as device configurations,
security mechanism configurations (e.g. access control entries, firewall
rules), directory schema entries and so on. The line separating low-level
policies and device configuration is sometimes not clear, and directly
specifying policies at this level is often a bottleneck to both scalability
and interoperability.

When I am talking about "policies" and "policy enforcement" on calls and in
emails, I mean authorization rules and "obligation" rules on resources.

POLICY PERSISTENCE: We should aspire for SIMILE policies to be persisted in
RDF, in the RDF store that sits under SIMILE. We can argue over whether a
policy should be "born" in RDF (e.g. maybe a policy specification language is
involved), but the results of policy complication should be persisted in RDF.

SCOPE OF POLICIES: A key concept in the world of policy management is the
expression of "domain scope" that policies apply to --- the specification of
the sets of resources that are the Subjects or Targets of policies. (note that
I'm using RDF words like "resource" instead of Ponder words like "Object")

The Ponder team argue for "domains," which provide a means for grouping
resources to which policies apply and can be used to partition the resources
in a large system according arbitrary parameters (geographic boundaries,
resources type, responsibility and authority, and human convenience).

Key reasons for SIMILE to take a domain-based approach are:

-- A policy applying to a domain of resources will propagate to its
sub-domains, thus applying to large numbers of resources and providing
scalability, and

-- By moving a resource from one domain to another, its policies will be
automatically replaced with those applying to the new domain, without the need
to modify the policies or manucally mange the associated between policy and
managed resources.

From the description, we can see that this notion would be useful within
SIMILE, not just for method-based or event-based policies (authorisations vs.
obligations), but for other management activities as well. But we haven't
talked about HOW to express or otherwise define these groupings!

SCOPING DOMAINS: Ponder talks about this a bit; maybe there is something
there. In the following I'll again use RDF words:

-- Membership in a domain is explicit, and not defined in terms of a predicate
on properties of a resource

-- A domain does not encapsulate the resource it contains, but merely holds
references to resource interfaces --- similar to a file system directory, but
may hold references to ANY type of resource, representing ANYTHING, even
policies...

-- A domain that is a member of a domain is a sub-domain (of the parent
domain)

-- A sub-domain is NOT a sub-set of the parent domain; an resource included in
a sub-domain is NOT a direct memeber of the parent domain, but is an indirect
member

-- A resource or a sub-domain may be a member of multiple parent domains

-- Policies propagate to members of sub-domains, so policies applying to
domain /myResources will also apply to /myResources/foo and /myResources/bar

-- Defining domain scope: Domains may be combined to form a set of resources
for applying a policy, using operations like union, intersection, and
difference.

There is prior work in tools for defining and managing domains of objects,
such as the Domain Browser by Tonouchi [see
http://www.doc.ic.ac.uk/~tton/DomainBrowser/poincareindex.html ]

* Ponder used LDAP directories as a basis for defining Domains; you'll see
that this is the basis for the Tonouchi thingy. We should think about a
similar management capability but using triples...

Enough for now...

| John S. Erickson, Ph.D.
| Hewlett-Packard Labs
| Norwich, Vermont USA
| john.erickson@hp.com

Received on Friday, 4 April 2003 13:01:02 UTC