[WG-UMA] fyi: W3C - Next steps on trust and permissions for Web applications

=JeffH 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" ]

plaintest rendering...

Next steps on trust and permissions for Web applications

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

Meeting Essentials

     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
     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:

     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 
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. <dsr at w3.org>

More information about the WG-UMA mailing list