- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Thu, 22 May 2014 17:25:03 +0200
- To: Dave Raggett <dsr@w3.org>, public-sysapps@w3.org
On 2014-05-22 17:00, Dave Raggett wrote: There is actually a huge and documented interest in Security Element APIs: https://fidoalliance.org/assets/downloads/Microsoft_Joins_FIDO_Alliance_Board.pdf http://fidoalliance.org/assets/downloads/Samsung_joins_FIDO_Alliance_BoD__FINAL__04_22_14.pdf http://fidoalliance.org/assets/downloads/ARM_FIDO_Board_04_22_2014_FINAL.pdf http://fidoalliance.org/news/item/the-fido-alliance-welcomes-visa-to-the-board-of-directors https://fidoalliance.org/news/item/the-fido-alliance-welcomes-global-financial-leader-bank-of-america-to-board Regarding the use of signatures for hosted web applications, I agree that the traditional use of signed code doesn't bring much value to the table. However, there are *other* trusted and hosted web application schemes for which signatures will be mandatory. These are like FIDO/U2F developed in other forums. Anders > First of all, sorry for the delay with the details of the proposed > meeting on the trust/permissions for web applications and work items for > a rechartered SysApps working group. > > Given the delays Wonsuk Lee and I are now looking at the beginning of > September, either 2nd or 3rd, or 3rd and 4th, as Wonsuk is on vacation > the following week. Would these work for you? Wonsuk would prefer the > meeting to take place in Europe since this is where most of the current > SysApps participants are located. We are now looking for a host for a > venue within easy reach of a major airport. > > As a reminder, the focus of the meeting would be on discussing the > trust/permissions model for access to extended capabilities for the Open > Web Platform, and to discuss proposals for work items for the rechartering. > > Many thanks for responding to the questionnaire. There was strong > support for each of the following: > > a) web apps need access to more advanced capabilities and features > than they currently have > b) users should have control over the capabilities available to > apps, along with the means to revoke these rights > c) asking the user for permission at the time of use is promising, > although not appropriate for all capabilities > d) asking the user for consent up front when the app is "installed" > or first run is also of value > e) app manifests should be one of the preconditions for apps to gain > access to richer capabilities > > There was weak interest in the potential for digital signatures as part > of attestation for hosted apps on the Open Web Platform. We didn't get > many suggestions on ideas for future work other than for Bluetooth > profiles support, and for continued work on the trust/permissions model > as an extension of existing practice on the Open Web Platform. > > Here are the numbers for which APIs people have plans to implement, and > which APIs people would like to see widely deployed. The third number is > the sum of the previous two and gives a broader feel for the level of > interest: > > App URI 4 5 9 > TCP UDP Sockets 4 4 8 > Task Scheduler 2 5 7 > Bluetooth 3 4 7 > Media Storage 3 4 7 > Network Interface 4 3 7 > App Lifecycle 3 3 6 > > Contacts 2 3 5 > Data Store 2 2 4 > Device Capabilities 2 2 4 > Idle 2 2 4 > Secure Elements 2 1 3 > > Calendar 1 1 2 > System Settings 1 1 2 > Messaging 1 - 1 > Telephony 1 - 1 > > We would be likely to drop the bottom group of specifications as they > wouldn't be able to satisfy W3C's criteria for exiting the Candidate > Recommendation phase. The middle group are at risk, but the top group > have strong support. The general idea is to identify capabilities that > would have broad appeal to web developers as part of the Open Web > Platform. In principle, there could be new capabilities beyond those > listed above and these could come from new participants to the working > group, however, rechartering with a modest scope would seem like a good > plan. > > Many thanks for your help, and please get in touch if you would be > interested in hosting the meeting. >
Received on Thursday, 22 May 2014 15:25:42 UTC