W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2009

Use Cases for Policy Interoperability

From: SULLIVAN, BRYAN L (ATTCINW) <BS3131@att.com>
Date: Tue, 3 Nov 2009 08:38:50 -0800
Message-ID: <8080D5B5C113E940BA8A461A91BFFFCD0FA1E9C4@BD01MSXMB015.US.Cingular.Net>
To: "Device APIs and Policy Working Group WG" <public-device-apis@w3.org>
1) A diversity of devices: Typical mobile service providers resell
mobile phones as part of services. In their stores, at one time they can
have about 50 device models from about 15 vendors. Consumers have come
to expect such a diversity of devices, as mobile phones are as much
lifestyle devices as communication tools. In a normal year, a mobile
service provider can introduce as many as 100 new devices for customers,
which means over the lifetime of devices the service provider can easily
be serving users of several hundred device models at one time. On those
devices there can be more than one browser or web runtime environment,
especially in smartphones. This incredible diversity of devices and web
runtime environments means that in order to have a consistent set of
security capabilities across the devices, there must be a consistent
language for policy definition that all the devices can use. This need
is no less significant than the need for a consistent definition of
markup language or any other semantic media that a wide diversity of
devices are expected to use.

2) Users of multiple devices: A user with multiple devices will expect
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, users should be able
to rely upon 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.

3) Typical lifecycle of security experience:
a) A device is developed with a pre-installed WRT with a default policy.
The policy is either defined by the OEM or the device reseller.
b) The device is sold, and the user customizes the security policy using
the WRT UI, upon first use of some pre-installed widgets.
c) As a subscriber to a particular service, the security policy is
further customized by a policy management service supporting seamless
"n-screen/device" user experience. The customization includes the
delivery of signed security policies that are installed by the WRT.
d) The user installs a new widget, and customizes the security policy
(as before) for the new widget. Installation of the widget may be
accompanied by installation of a signed security policy governing
widgets published by the developer (or the developer's organization). As
a result, the organization is given management responsibility for
policies applicable to their widgets.

Best regards,
Bryan Sullivan | AT&T
Received on Tuesday, 3 November 2009 16:39:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:01 GMT