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.

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.

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.

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:

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?