W3C Logo

Next steps on trust and permissions for Web applications

3–4 September 2014, Paris, France (revised dates)


W3C gratefully acknowledges Gemalto, for hosting this meeting.


HTMl5Apps Thanks also to support from the European Union through the Seventh Framework Programme (FP7/2013-2015) under grant agreement n° 611327 - HTML5 Apps.

Meeting Essentials

This meeting is an initiative of the System Applications Working Group, whose 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 Group and 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 organization.
  • If you are interested in attending the meeting, please email Dave Raggett by 1 August 2014.
3-4 September 2014
09:00-18:00 each day
Gemalto's offices in Paris
6 rue de la Verrerie
CS 20001
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:

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 so forth.
  • 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 of use?
  • 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?

Expected Outcome

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.