ACTION-69: Policy use cases

Hi,

The notes below are an embryonic input to start off work on this action.

I want also to start on use cases for the contents of the policy itself but
this overlaps with part of the policy requirements document - are we OK to
move that section from the policy reqts document into a separate document
and expand it there?

Thanks - Paddy

------------------
*
Introduction
*
This note aims to define a set of specific use cases to assist in the
definition and validation of a policy framework.

Use cases are discussed in two categories:

   - use cases relating to the definition and management of policy;
   - use cases relating to the interoperability of policy.

A separate set of use cases needs to be defined relating to the contents of
the policy itself.

The use cases are not claimed to be exhaustive, but illustrative.*

Policy management
*
These use cases relate to how a policy is created, configured and
maintained.

Use cases vary according to:

- who the authority for the policy is: either the user, or an external
authority such as an enterprise, or a combination;
- the nature of the initial policy configuration (eg whether it is a
universal default, or is a specific policy determined by the authority to
support a specific objective);
- the nature of the policy maintenance and update.

*Use case PM1: user-controlled configuration
*
In this use-case:

- the user of a device is the sole authority that decides access rights of
applications;
- there is a "universal default" initial policy configuration;
- there is no  external policy authority and hence no externally-triggered
policy update. Policy maintenance occurs only to the extent that the user
modifies configuration settings interactively via a "preferences" facility,
or asks the UA to remember certain responses to prompts.

This use-case is the expected case in most situations where there is no
external policy authority such as a network operator or enterprise.

Although the initial configuration is "empty" (ie it only contains universal
default rules), it is possible for the policy to be extended over time as
the cumulative result of explicit user configuration and persistently
remembered user decisions.

The configured policy, at any given time, may be stored locally on the
device or may be stored remotely and be accessible via a network service, or
both.

*Use case PM2: user-delegated configuration*

In this use-case:

- the user of a device delegates authority for access control policy to an
external service provider;
- the external service provider provides advice on the trustworthiness of
specific applications, and determines an access control policy that embodies
that advice. The advice may be based on a knowledgebase of known trustworthy
and/or malicious applications, or algorithms for detecting malicious
behaviour, or both;
- the policy defined by the external authority is updated regularly in
response to new information on known threats.

The policy configuration provided by the external policy provider may be
supplemented by user control as in PM1.

The configured policy, at any given time, may be stored locally on the
device or may be stored remotely and be accessible via a network service, or
both.

This use-case mirrors current practice with products such as virus scanners
or other malware detectors.

*Use case PM3: external policy authority
*
In this use case:

- an external body has authority over the device and, in particular,
security policy configuration.
- an initial security policy configuration may be provided by the external
authority, together with any other associated device configuration (such as
root certificates). The configured policy may determine acces control policy
without reference to the user, or may refer certain decisions to the user.
- the policy may be updated periodically under the authority of the policy
authority. Policy maintenance may also occur as the cumulative effect of
certain user decisions being remembered.

The external policy authority may configure the policy as part of the
commissioning of the device (eg a network operator's configuration applied
by the manufacturer prior to sale, or an enterprise configuring device
policy using a secured device management interface).

In determining the policy, the policy authority has the opportunity to
define a policy that supports a specific objective - such as to limit access
to APIs to only those web applications that are themselves distributed by
the policy authority (eg to control its exposure to the financial risk of
abuse of device APIs).

*Policy interoperability*

These use cases relate to reading and writing of policy definitions in an
interoperable format.

*Use case PI1: device-independent policy definition
*
In this case case, a single policy authority wishes to define and configure
a security policy for multiple dissimilar devices. A typical network
operator's portfolio many include tens or even hundreds of models, each
based on different platforms, and different UAs. A commonly supported
interoperable format for configuration of a policy dramatically impacts the
practicality of achieving the desired configuration across all devices. This
is relevant to Policy Management use case PM3.

*Use case PI2: portability of user settings*

A user may establish a policy configuration (through explicit configuration
of preferences, and remembered decisions) and there is the option of reusing
this configuration across multiple devices. A user with multiple devices may
wish for their security preferences to be consistent (or to at least have
the option of consistency) across those devices. Rather than have to
manually configure the preferences on each device, it should be possible for
there to be a seamless security experience across devices, e.g. by switching
SIM card between devices and as a result automatically applying a policy
resident on the SIM card or synchronizing with a network-based policy
management system. A specific case is the case where a user wishes to
transfer a configuration from an old device to a new device. This is
relevant to Policy Management use cases PM1, PM2, PM3.

*Use case PI3: policy provisioning as part of service deployment*

Configuration of some parts of access control policy may be part of the
overall configuration required to enable a particular application or
service. This, along with many other configuration parameters, may be
remotely configurable via device management. The configuration required to
enable a service may be provided by the service provider as a policy
fragment, to be added to the overall policy by the policy authority. An
interoperable representation of such policy fragments would enable this to
be done without authoring the configuration updates separately for each
target device, platform, or UA.
*
*