[WG-UMA] fyi: W3C - Next steps on trust and permissions for Web applications
Jeff.Hodges at KingsMountain.com
Fri Aug 8 13:07:09 CDT 2014
Of possible interest...
[ see the latter page for many embedded links, eg to "further reading" ]
Next steps on trust and permissions for Web applications
3–4 September 2014, Paris, France (revised dates)
This meeting is an initiative of the System Applications Working Group
<http://www.w3.org/2012/sysapps/>, whose charter
<http://www.w3.org/2012/09/sysapps-wg-charter> expires 1 October 2014. The
goal of the meeting is to discuss next steps for work on standards for trust
and permissions, based upon insights gained from experience with native app
platforms, hybrid and proprietary web platforms.
This meeting is open to participants of the Systems Applications
Working Groupand guests from a small number of other W3C Working Groups,
invited on behalf of the System Applications Working Group Chairs
Due to space limitations, attendance is limited to 1 person per
If you are interested in attending the meeting, please email Dave
Raggett <dsr at w3.org> by 1 August 2014.
3-4 September 2014
09:00-18:00 each day
Gemalto's offices in Paris
6 rue de la Verrerie
92197 Meudon sur Seine
This is not a meeting about the current work of the Systems Applications
Working Group, but rather a 2-day discussion about next steps in this space,
in light of the fact that the group's charter expires 1 October 2014. This
two-day meeting will review the limitations of existing standards, and
discuss insights gained from experience with native app platforms, hybrid
and proprietary web platforms.
As the Open Web Platform expands, new capabilities are likely to require new
ways of managing permissions. Some platforms, e.g. Android, ask users
upfront for permission when an app is installed or first run, whereas others
like iOS ask users for permission when the application is attempting to use
a given capability. Rather than asking the user for permission in advance,
another approach is to invite the user to continue or to cancel an action
after it has occurred, i.e. asking for forgiveness rather than permission --
this is the approach taken in the Fullscreen API, see the explanation by
Chris Pearce. In some cases, the user's actions can be taken as implicitly
granting permission, for a detailed analysis of this approach, see Roesner
et al. A further approach is for users to delegate decisions on permissions
to a trusted 3rd party (if it's okay by them, it's okay by me). What is
needed to arrive at a consensus for a cross vendor solution?
Some further reading:
Information on API Permissions collected by the Web and Mobile Interest
How to Ask For Permission, HotSec'12, Porter Felt, et al.
Installable Webapps: Extend the Sandbox by Boris Smus
Draft white paper on trust and permissions by Dave Raggett
Sample discussion topics:
Is it practical to offer users clear explanations about how
capabilities will be used prior to being asked to make decisions on whether
or not to grant applications permissions for these capabilities?
What criteria are there for choosing between asking users upfront for
permissions, asking at the time of use, asking for forgiveness rather than
permission, or implicit approval via user actions?
What kinds of limits can be imposed for trust delegation? For instance,
limiting delegation to given categories of apps, and excluding apps
featuring in-app payments.
What are the implications that different approaches have for API
design? For instance, the implicit approach could enable APIs only in
execution contexts triggered by user interaction, e.g. a click, tap or
keyboard short cut. This, however, is open to abuse by mislabeling UI
controls to fool users to into initiating actions without their knowledge.
How can developers tailor the user experience, e.g. the presentation of
justifications of the need for a given capability prior to asking the user
for permission? This necessitates a means for apps to discover whether the
user has previously granted permission, has previously declined to grant
permission or has yet to be asked.
Can we reach a consensus on a consistent approach to whether users are
offered the chance to apply their decision for the rest of this session and
subsequent sessions? This should depend on the level of trust in the
application, e.g. whether it was accessed over an encrypted connection,
whether it is from a trusted website, whether it has a high reputation, and
Standards are needed for common capabilities and how these are named in
order to provide developers with good expectations of interoperability, and
to give users a consistent and understandable experience across different
applications and devices.
What level of granularity is appropriate for permissions? Too low a
level will make it hard to explain to users, whilst too high a level will
limit the end user's freedom of choice. Furthermore, the granularity of
permissions will have consequences for developers in how they deal with the
cases where users decline to grant particular permissions.
Some capabilities are very specific to a given platform and as such are
inappropriate for standardization. Conversely, there is pressure to agree on
a standard where many developers are seeking a cross-vendor solution.
Access to some capabilities may be restricted, e.g. consider the case
where an application can only access the engine related API in a car if the
application is signed by the car manufacturer.
How much leeway should be left to individual implementors of the Open
Web Platform? For example, does it make sense for the application manifest
to list the permissions needed by the application, but leave it up to the
platform implementation to determine whether to ask upfront or at the time
It may take some time to arrive at a consensus for a detailed solution,
so can we reach some initial agreements that enable work to proceed in
parallel on standards for APIs for specific capabilities?
This meeting is expected to provide advice to W3C on how to proceed, e.g. as
a Community Group, Interest Group or Working Group.
Questions? Email Dave Raggett. <dsr at w3.org>
More information about the WG-UMA