W3C Logo

Next steps on trust and permissions for Web applications

3–4 September 2014, Paris, France

Host

W3C gratefully acknowledges Gemalto, for hosting this meeting.

Gemalto

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

The meeting took place as planned and the draft minutes are now available. These include plans for future work.

Hashtag
#webpermission
What
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.
Who
  • 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.
When
3-4 September 2014
09:00-18:00 each day
Where
Gemalto's offices in Paris
6 rue de la Verrerie
CS 20001
92197 Meudon sur Seine
FRANCE

See also google maps for walking routes.

Getting to Gemalto

The best means of getting to Gemalto depends on where you're coming from. You can plan your journey with www.transilien.com. Here are some options:

Meudon-sur-Seine and Brimborion (Zone 3) are nearby tram stops on Tram line T2 and within easy walking distance. This line runs between Porte de Versaille and La Défense.

Slightly further away, but still walkable, is Gare de Meudon which can be reached from Paris Montparnasse via the SNCF Transilien line N. Note that Meudon is in Zone 3, when it comes to purchasing a ticket.

Another option from central Paris is to take RER line C to either Issy (Zone 2) or Gare de Meudon Val Fleury (Zone 3), and then get a taxi to Gemalto.

Triadvisor provides some helpful info on zones and fares.

Attendees

The following people have indicated their intention to attend the meeting:

  • Dave Raggett, W3C
  • Dom, W3C (remote)
  • Robin Berjon, W3C (webapps etc.)
  • Wendy Seltzer, W3C (security, privacy) 2nd day only
  • Mike O'Neill, Technical Director, Baycloud Systems, Oxford Centre for Innovation
  • Daniel Appelquist, Telefonica (remote)
  • Stefan Håkansson, Ericsson (Co-chair Media Capture TF, WebRTC)
  • Philipp Hoschka, W3C
  • Giridhar Mandyam, Qualcomm
  • Claes Nilsson, Sony Mobile
  • Wonsuk Lee, Samsung
  • Vadim Draluk, GM (automotive)
  • Adrienne Porter Felt, Google
  • Jonathan Jeon, ETRI
  • Steven Woolcock, Apple
  • John Hazen, Microsoft
  • Stephanie Ouillon, Mozilla
  • Woosung Kim, LGE (remote)
  • Kenneth Rohde Christiansen, Intel
  • Olivier Potonniee, Gemalto
  • Renato Iannella, Semantic Identity (remote)

Note that Dom, Daniel, Woosung and Renato expect to attend remotely.

Remote Participation

Olivier Potonniee has booked a "Microsoft Lync" online meeting for remote participants. People can either connect through Lync (by clicking link above) if they have this software installed (Silverlight 4.0), or by a simple phone call, using the closest phone number. The Conference ID is: 77634672.

Agenda

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?

Here is a draft agenda that we can tweak as needed at the start of the meeting:

  1. Introductions
  2. Logistics and agenda tweaking
  3. Review of existing practices for the Open Web Platform (OWP)
  4. Review of approaches used by other platforms (web and native)
  5. What lessons come out of academic studies, e.g. Porter Felt, et al. and Roesener et al.
  6. Discussion of what considerations are important for the OWP
  7. A detailed look at some proposals
  8. Plans for future work - e.g. chartering a CG, Cross WG Task Force, ...

Some further reading:

Note: this is just a sample, and not intended to be authoratative.

Sample discussion topics

Group 1: User Consent

  • What criteria are there for choosing between asking users upfront for permissions, asking at the time of use, asking for forgiveness rather than permission, implicit approval via user actions, or mediated by the platform or trusted 3rd party?
  • 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 is the basis for users to trust these explanations?
  • 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.
    • 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 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.
    • Roesner at al. provide a comprehensive solution for intent based access control based upon Access Control Gadgets (ACGs)
    • What are the implications for app developers when the user has granted some but not all permissions requested by an app? This relates to proposals for returning a promise when testing if permissions have been granted.
  • 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.

Group 2: Delegated Trust

  • What roles are there for trust delegation? This could, for example, be exploited to avoid asking users for permissions for capabilities that are hard to explain. Apps stores may be trusted on the basis of their vetting procedures. Well known websites, that host their own apps, may be trusted on the basis of their brand. Other sites may find it advantageous to have their apps endorsed by a trusted third party. 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.
  • Web apps have the unique ability to embed one another (through e.g. iframe); how does this embedding affect the ability of a Web app to request permission? how does an app with privileges indicates its willingness to be used with privileges once embedded? how does an app prevent an embedded app to request privileges (e.g. with the sandbox attribute of an iframe)?

Group 3: Permission Management

  • When and how does the user know that a Web site has access to a given permission? how to deal with indicators in the browser chrome on mobile screens (with limited screen real estate), or when they app is running full screen?
  • Is there a need to inform apps when the user revokes a permission, e.g. to enable the app to dynamically adapt the user experience to match?
  • How should browsers adapt their permission models to the security environment of the app? How does the use of HTTPS, Content-Security-Policy, script integrity, cross-origin requests affect the permissions an app may be granted?
    • with the emergence of ServiceWorker, a number of Web app will be able to run in the background; how does the operation in background/foreground of an app affects its privileges?
    • some mobile platforms restrict some permissions to certified apps, to which other apps need to delegate the privileged operation; how does that model apply to the Web? How does it relate with proposals around integration of third-party apps such as the late Web intents, or registerProtocollHandler()
  • 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.

Group 4: Miscellaneous Topics

  • 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

At the end of the meeting we would like to have a clear idea for next steps:

  • Areas where we have a rough consensus and need to work on the details?
  • Areas where we are still some way apart and what steps can be taken to close the gap?
  • What can be ruled as out of scope for W3C work on trust and permissions in the open web platform?
  • Whether we want to set up a Community Group, a Cross Working Group Task Force or some other approach?
  • What design rules can we give to allow work to proceed in parallel on APIs and trust & permissions?

Questions? Email Dave Raggett.